Profitiert double von der 32bit FPU?

Soweit ich weiss bringt sie dann nichts... Kann mich aber irren

Nein, die FPU müßte von sich aus schon double unterstützen.
Auf der anderen Seite ist double auf M3/M4 Prozessoren schon sehr 
schnell, sodaß es keinen Grund gibt, auf double zu verzichten, wenn man 
es braucht.

Altes Beispiel mit F407: 
Beitrag "Re: Controller mit FPU"

P. S. schrieb:
> Falls möglich, werden vom Compiler auch beim Rechnen mit Doubles
> Instructions für eine Single FPU erzeugt.

Dann zeige mal ein einziges Beispiel. Ich bin gespannt ;-)

Float und Double ist auf µC meist keine Sinnvolle Lösung.

Der Vorteil liegt bei extrem Großer Dynamik
was bei unbekannten Signalen oder unbekannten Operationen hilfreich ist.

aber 12 Bit Analog oder 16Bit über CAN oder Zähler ist keine große 
Dynamik
Auch weiß man i.f.R genau was zu rechnen ist.

Festkomma ist fast immer die beste Lösung.

Fließkomma  oder Skalierung mit 10, 100 , 1000
ist immer ein guter Hinweis das der Entwickler die Sache nicht durch 
gerechnet hat.
Sich mit Themen wie Auflösung, Toleranzen, Rundungen, Genauigkeit, 
Fehlerrechnung, Überläufe...
nie Beschäftigt hat.

Und das fällt einem irgendwann schmerzhaft auf die Füße.

Sebastian S. schrieb:
> Es ist aber nicht ausgeschlossen

Warum melden sich hier andauernd Leute, die noch nie mit einer FPU 
gearbeitet haben?

Ich arbeite seit einigen Monaten an einem privaten Audio-DSP Projekt. 
Hardware STM32F407. Also mit FPU.

Ich rechne Filter, Reverb-Algorithmen und Modelle in einer 96kHz 
(10.4µs) Task und beobachte die Rechenzeiten der einzelnen Blöcke immer 
mit.

Zuerst habe ich wie ich es bisher kannte mit Festkommaoperation 
gearbeitet, bin dann aber auf float umgestiegen. Das war ein 
Geschwindigkeitsvorteil, weil float oft genauso schnell berechnet wurde 
wie int. Aber ich habe auf einige Skalierungen verzichten können.

Aber wehe ich haben irgendwo ein y= x * 3.14159265359; stehen. Das 
fehlende f für float führt dazu, dass double verwendet wird. Dann geht 
die Rechenzeit eines Filters schnell mal um Faktor 10 nach oben.

Volle schrieb:
> Float und Double ist auf µC meist keine Sinnvolle Lösung.

Das gilt vielleicht für einen 8-Bitter.
Stefanus redet von einem 32-Bitter mit FPU.

ich hab mich auf 32bit bezogen   (8 Bit Rechner hab ich 1992 
ausgemustert)

Thema Auflösung und Rundung
da meinen viele irrtümlich das sei bei Fließkomma besser
und kümmern sich nicht darum.

Die STMs können doubels problemlos auf der FPU berechnen. Wenn man 
Atollic o.ä. benutzt wird auch automatisch die entsprechende Bibliothek 
benutzt. Es gibt von ST einen Appnote dazu was wieviele Takte braucht. 
Ich meine Double braucht genau ddoopelt so lange wie singel. Wobei 
Addition Subtraktion Multiplikation und Cast einen bzw dann 2 Takte 
brauchen. Und Wurzel und dividieren 8 bzw. 16. Wenn es mehr Performance 
braucht geh zum H7 der hat eine DP FPU.

Wie ihr an der Frage korrekt erkannt habe, habe ich 
Fließkomma-Operationen auf Mikrocontrollern praktisch keine Erfahrung.

Auf 8bit µC habe ich gelernt, weitgehend mit Integer Datentypen 
auszukommen.

Nun habe ich aber inzwischen auch einige STM32F303 Board in der 
Bastelkiste. Die haben eine FPU und deswegen ist das Thema 
"Fließkomma-Arithmetik" wieder hoch gekommen. Float ist allerdings 
manhcmal zu ungenau, daher meine Frage. Wenn der Unterschied zu Double 
gering wäre, würde ich einfach immer double nehmen - so handhabe ich das 
im Job (Server Backend).

auf µC gilt Datentypen so klein wie möglich und so groß wie nötig

aus Bequemlichkeit pauschal double zu verwenden geht nicht lange gut.

Autofahren nur mit dem 5. Gang macht innerorts keinen Spass.


Und damit komme ich wieder zum Thema das man genau wissen sollte was 
sman macht bezüglich Aufösung Genauigkeit...

Stefanus F. schrieb:

> Wie ihr an der Frage korrekt erkannt habe, habe ich
> Fließkomma-Operationen auf Mikrocontrollern praktisch keine Erfahrung.

Dass du keine Ahnung hast brauchst du nicht ständig betonen. Weiß hier 
jeder.

Boris schrieb:
> Dass du keine Ahnung hast brauchst du nicht ständig betonen. Weiß hier
> jeder.

Danke fürs Nachtreten. Das war sehr weise und hilfreich.

Stefanus F. schrieb:
> Auf 8bit µC habe ich gelernt, weitgehend mit Integer Datentypen
> auszukommen.

Das sind die alten Vorurteile aus den 70/80ern. Aber selbst der PET hat 
schon mit 40 Bit Fließkommazahlen gearbeitet.
Seit AVR habe ich gelernt, wenn ich float brauche nehme ich float. Und 
wenn ich dort double brauche, dann nehme ich auch double. Was soll der 
Geiz?

> Float ist allerdings
> manchmal zu ungenau, daher meine Frage. Wenn der Unterschied zu Double
> gering wäre, würde ich einfach immer double nehmen - so handhabe ich das
> im Job (Server Backend).

Nimm double, wenn Du double brauchst. Ausführungszeiten habe ich Dir ja 
oben verlinkt. Und wenn es doch noch schneller gehen soll und float 
ausreicht, aktiviere die FPU und rechne damit. Bezahlt ist das Teil ja 
schon ;-)

Und wie oben auch erwähnt, gibt es die H7xx, die die Grundrechenarten 
beider Typen per Hardware rechnen. Klein und günstig STM32H730/750, wenn 
man nicht dem Flash-Wahn erlegen ist.

Philipp Klaus K. schrieb:
> da könnte man die ersten Schritte
> mit float rechnen, auch wenn man später ein double-Ergebnis will.
>
> Inwiefern das tatsächlich gemacht wird, weiß ich allerdings nicht.

Wer so programmiert, hat einen an der Waffel!
Ein Programm soll ein Problem lösen und nicht neue Fallstricke schaffen.

Wenn sich hier Leute melden, deren Programm angeblich zu langsam läuft, 
dann liegt das nicht an den verwendeten Datentypen, sondern an 
ungeschickter Programmierung oder noch schlimmer, an Funktionen wie 
delay_ms(100).

m.n. schrieb:

> Philipp Klaus K. schrieb:
>> da könnte man die ersten Schritte mit float rechnen,
>> auch wenn man später ein double-Ergebnis will.
>>
>> Inwiefern das tatsächlich gemacht wird, weiß ich
>> allerdings nicht.
>
> Wer so programmiert, hat einen an der Waffel!

Nein: Der hat Ahnung von Numerik.

Aber sei unbesorgt: Das trifft auf die allermeisten
Programmierer nicht zu. Keine Gefahr.

Philipp Klaus K. schrieb:

> Inwiefern das tatsächlich gemacht wird, weiß ich
> allerdings nicht.

Es gab mindestens einen Signalprozessor, der das
unterstützt hat. Typ weiss ich nicht. Dort gab es eine
schnelle "ungefähre" Division und einen Extrabefehl,
um mittels Fixpunktiteration die restlichen Stellen
zu beschaffen.

Egon D. schrieb:
> Es gab mindestens einen Signalprozessor, der das
> unterstützt hat. Typ weiss ich nicht. Dort gab es eine
> schnelle "ungefähre" Division und einen Extrabefehl,
> um mittels Fixpunktiteration die restlichen Stellen
> zu beschaffen.

mindestens, weiss ich nicht, ungefähr, ...

Na das ist ja alles sehr konkret.
Ein Spezialfall soll nun die Standardlösung für jede numerische 
Berechnung sein? Und das, wo viele F7xx und alle H7xx µCs von Hause aus 
schon double Berechnungen per Hardware bieten? Und es gibt nach andere 
Anbieter ...
Ich sag nur: Bahlsen!

m.n. schrieb:
> Ein Spezialfall soll nun die Standardlösung für jede numerische
> Berechnung sein?

Hat doch keiner gesagt. Im Rahmen meiner fand ich diese Idee durchaus 
für passend, obwohl mir klar war, dass es nur ein Spezialfall ist.

Mw E. schrieb:
> Das ist ja nicht wie bei einem fixkomma add mit 64bit wo es reicht ein
> normales add und danach ein add with carry auszuführen.
> Selbst ein 64bit MUL geht mit 3 32Bit MULs und einer Abfrage.

Das war mein Gedanke dahinter. Wenn man große Integer Operationen in 
kleine zerlegen kann, dann vermutlich auch mit Fließkommazahlen. Nur war 
mir halt nicht klar, ob sich dann die Nutzung der kleinen FPU überhaupt 
noch lohnt.

Stefanus F. schrieb:
> Im Rahmen meiner fand ich diese Idee durchaus
> für passend, obwohl mir klar war, dass es nur ein Spezialfall ist.

Dann sag doch, was genau Du rechnen willst.
Deine Frage war allgemeiner Natur und nichts Spezielles und erst recht 
nichts Zeitkritisches.

m.n. schrieb:
> Dann sag doch, was genau Du rechnen willst.

Kann ich leider nicht. In diesem Thread geht es mir nicht um eine Lösung 
für ein konkretes Problem, sondern darum, den Sachverhalt zu verstehen.

Bisher bin ich immer mit Integer ausgekommen. Doch in Zukunft, wenn 
float oder double "billig" ist, werde ich mir wohl einige Klimmzüge zur 
Nutzung von Integer sparen.

Für mich ist die eigentliche Frage eher: Nehme ich dann float oder 
double?

Da ich nun verstehe, dass double nicht von der kleinen FPU profitiert, 
kommt also wohl nur float in Frage. Wo das nicht genügt würde ich dann 
doch wieder lange Integer verwenden.

> Deine Frage war allgemeiner Natur und nichts Spezielles
> und erst recht nichts Zeitkritisches.

Ja stimmt. Die Idee, sich per Float an einen Wert anzunähern und dann 
erst genauer weiter zu rechnen ist für mich aber auch interessant. Denn 
einen Annäherungs-Algorithmus hatte ich mal auf einem ATmega16 
gebraucht.

In diesem Fall ging es darum, einen fahrenden Roboter sanft zu bremsen, 
wofür ich fortlaufend den verbleibenden Bremsweg schätzen musste. Da war 
die sqrt() Funktion zu schwergewichtig. Mit FPU würde ich jedoch nochmal 
sqrt() versuchen, weil es einfacher wäre.

Deswegen interessiert mich der Aspekt schon, den Egon da ansprach.

Stefanus F. schrieb:
> Da ich nun verstehe, dass double nicht von der kleinen FPU profitiert,
> kommt also wohl nur float in Frage. Wo das nicht genügt würde ich dann
> doch wieder lange Integer verwenden.

Gut, dann bleib bei Deinen Vorurteilen, daß Fließkommaverarbeitung 
langsam und damit böse ist. Es ist ja nichts Neues, daß u.a. 
float/double bei vielen µC Anwendern Einnässen auslöst.

Stefanus F. schrieb:
> Da ich nun verstehe, dass double nicht von der kleinen FPU profitiert,
> kommt also wohl nur float in Frage.

m.n. schrieb:
> Gut, dann bleib bei Deinen Vorurteilen, daß
> Fließkommaverarbeitung langsam und damit böse ist.

Ich habe kein Vorurteil. Wie kommst du überhaupt auf den Schluss, dass 
"kommt wohl nur float in Frage" für mich bedeutet, dass 
"Fließkommaverarbeitung langsam und damit böse" sei?

Ich habe doch gerade erst angekündigt, float benutzen zu wollen!

Tschuldigung, aber dein Schluss entbehrt jeder Logik.

13.10.2019 11:34 - 12.10.2019 10:57 = 1 Tag und 37 Minuten.

In 5 Minuten hast Du das doch selbst ausprobiert. Einmal mit, einmal 
ohne FPU kompiliert.

Für mich ist ein Programm optimal wenn es gut zu verstehen ist und damit 
wartbar ist, das ist mir um Längen wichtiger als kürzest mögliche 
Ausführungszeit. Also erstmal einfach und verständlich programmiert, 
dann wenn nötig optimieren und nicht gleich alles dem Performancegott 
opfern.
Fehler kann man mit jedem Datentypen machen, alle haben ihre Tücken. Wer 
mir sagt das er als Anfänger da nie drauf reingefallen ist dem glaube 
ich nicht. Bei Integer kann man auch ruck zuck Überläufe erzeugen, z.B. 
eine lange Berechnung und das Zwischenergebnis wird zu groß. In C/C++ 
wird sowas nicht abgefangen und ein vermeintlich funktionierendes 
Programm macht irgendwann Blödsinn.
Float skaliert sich durch die Normierung automatisch, aber bei Addition 
kleiner Werte auf Große muss man genauso aufpassen. Schönes Beispiel ist 
die Berechnung der Standardabweichung wo durch Addition der Quadrate 
schnell große Summen entstehen.
Trotzdem reichen floats in vielen Berechnungen die man mit µC macht. 
Hier war mal PID Berechnung das Thema, ich habe es auf dem STM32F407 
gemessen und die float Rechnung brauchte 0,54 µs. Da lohnt es sich wohl 
kaum das mit Integer und Klimmzügen optimieren zu wollen.
Nur bei den M0 muss man gut aufpassen, eine Mul wie

1

x *= 10.0;

 erzeugt sofort vielmehr Code wenn double ins Spiel kommen. Bei der 
Umsetzung von AVR-Arduino Libs läuft man da schnell rein weil die AVR 
Programmierer den Unterschied nicht beachten mussten.

Audio Phil schrieb:
> In 5 Minuten hast Du das doch selbst ausprobiert. Einmal mit, einmal
> ohne FPU kompiliert.

Da hast du wohl Recht. Ich hätte es auch ausprobieren können. Allerdings 
neige ich dazu, das Testergebnis für allgemein gültig zu halten. Solche 
Diskussionen hier helfen mir, das Thema differenzierter zu betrachten.

Wieso schreibt Ihr nicht einfach einen Benchmark und stellt den hier 
rein?

chris schrieb:
> Wieso schreibt Ihr nicht einfach einen Benchmark und stellt den
> hier rein?

Habe ich doch gerade erst erklärt:

Stefanus F. schrieb:
> neige ich dazu, das Testergebnis für allgemein gültig zu halten. Solche
> Diskussionen hier helfen mir, das Thema differenzierter zu betrachten.

Womit wir wieder bei der Aussage von Boris wären.

Schnauze schrieb:
> Womit wir wieder bei der Aussage von Boris wären.

Gib mal etwas intelligentes oder wenigstens hilfreiches von Dir!

Eine single precision FPU nützt für double precision leider nichts. 
Berechnungen mit double erzeugen trotzdem Aufrufe in die EABI und werden 
durch die CPU emuliert. Je nachdem was man tun möchte kann man aber mehr 
Präzision aus einer single precision FPU herausholen, indem man mehrere 
Variablen nutzt.

Als Beispiel für Addition das Kahan/Neumeier Verfahren:
https://en.wikipedia.org/wiki/Kahan_summation_algorithm

Mit ähnlichen Tricks kann man sich double oft sparen. Im Vergleich zur 
Software Emulation von double bietet die FPU Nutzung dann erhebliche 
Geschwindigkeitsvorteile.