Gibt es irgendwo eine Library, die float16_t für AVRs unterstützt? Mich würde ein Benchmark für MAC Operationen im float16_t Format interessieren. Reference: https://www.khronos.org/opengl/wiki/Small_Float_Formats
Nie gesehen, sorry. Ich kann mir auch kaum vorstellen, daß es für irgendwas sinnvoll ist mit nicht mal dreieinhalb Stellen Genauigkeit und einem Wertebereich, den man auch leicht mit ganzen Zahlen erreicht. Das soll wohl gelegentlich im Grafikbereich verwendet werden, aber da kommt man mit einem AVR auch nicht weit. Sicher, daß Festkommazahlen nicht interessanter sind?
Zu float16_t kann ich nichts schreiben. Für entsprechende Anwendungen verwende ich auf den AVRs Fixed-Points. Auszug:
1 | #include <avr/io.h> |
2 | #include <math.h> |
3 | #include <stdint-gcc.h> |
4 | #include <stdfix.h> |
5 | |
6 | ... |
7 | |
8 | #define samples 64 |
9 | |
10 | ... |
11 | |
12 | _Fract v[samples]; |
13 | |
14 | ... |
Klaus W. schrieb: > Ich kann mir auch kaum vorstellen, daß es für irgendwas sinnvoll ist mit > nicht mal dreieinhalb Stellen Genauigkeit und einem Wertebereich, den > man auch leicht mit ganzen Zahlen erreicht. Der TO interessiert sich ja auch nur dafür. Von irgend einer sinnvollen Anwendung stand da nichts. Abgesehen davon: Float-Formate aller Art haben in Verbindung mit dem Wunsch nach einer Art MAC-Operation eigentlich nur einen Sinn, wenn sie in Hardware und dabei effektiv nur in einem Takt berechenbar sind. So etwas ist definitiv bei einem AVR nicht der Fall. W.S.
Klaus W. schrieb: > Ich kann mir auch kaum vorstellen, daß es für irgendwas sinnvoll ist mit > nicht mal dreieinhalb Stellen Genauigkeit und einem Wertebereich, den > man auch leicht mit ganzen Zahlen erreicht. Bei float hast du immer die gleiche Anzahl gültiger Stellen, bei ganzen Zahlen nicht. Für Rechenoperationen mit Multiplikationen daher sehr gut vorstellbar.
Wolfgang schrieb: > Bei float hast du immer die gleiche Anzahl gültiger Stellen, bei ganzen > Zahlen nicht. Für Rechenoperationen mit Multiplikationen daher sehr gut > vorstellbar. Das ist mir schon klar. In der Theorie ein echter Vorteil. Bei float16_t ist aber (wenn ich mich nicht täusche) der Exponent 5 Bits lang. Dann kommt man von Zehntausendstel bis gerade mal um die 65000 als Wertebereich. Das kann man mit Festkomma auch leicht haben, und hat viel weniger Rechenaufwand, gerade bei einem AVR sucht man eher keine Rechenzeitfresser. Gleitkomma lohnt doch erst, wenn man wirklich einen größeren Bereich braucht und sich dabei nur eine begrenzte Anzahl Stellen für die Genauigkeit gönnen will. W.S. schrieb: > Der TO interessiert sich ja auch nur dafür. Von irgend einer sinnvollen > Anwendung stand da nichts. Stimmt, Spielen reicht als Motivation. Dagegen sage ich nichts. Wollte nur erwähnen, daß der praktische Nutzen wahrscheinlich limitiert ist.
Der Tradeoff liegt zwischen Anzahl Stellen, und Wertebereich. Nehmen wird 2 Stellen, sind das 7 bit mantisse plus vorzeichen, also 8 bit. Dann waeren 8 Bit uebrig fuer den Exponenten, auch 7 bit plus Vorzeichen. Also bis 128 nach links oder rechts schieben. Das ist doch sehr ueppig. Weniger Werteberich waere auch passend. Nehmen wir 30 Shifts nach rechts und links, da wuerden 5 bits Exponent reichen, und wuerden 10 Bit Mantisse lassen. Das waeren dann 3 Stellen.
Wenn Du es Dir einfach, aber dafür nicht ganz so schnell machen willst: Nimm bfloat16, das ist der normale float mit verkürzter Mantisse. Du speicherst einfach die unteren zwei Byte der Mantisse nicht. Beim laden "bläst" Du das auf und nimmst dann die float-Operationen .
Da float auf dem AVR ziemlich langsam läuft, wollte ich den Geschwindigkeitsgewinn von float16_t ausprobieren.
Dann kannst Du dir wahrscheinlich aus der float32 impementierung relativ schnell eine bf16 bauen. Würden sicherlich auch andere nutzen
Hier sind welche erwähnt: https://stackoverflow.com/questions/5766882/why-is-there-no-2-byte-float-and-does-an-implementation-already-exist Vielleicht ein Startpunkt?
Klaus W. >Hier sind welche erwähnt: >https://stackoverflow.com/questions/5766882/why-is-there-no-2-byte-float-and-does-an-implementation-already-exist >Vielleicht ein Startpunkt? Danke für den interessanten Link. Erstaunlich, wie aufwendig die Multiplikation und die Addition realisiert ist (ganz am Schluss im Code). Schnell sieht das nicht aus. float16_t nennt sich wohl auch "half precision float": https://en.wikipedia.org/wiki/Half-precision_floating-point_format#IEEE_754_half-precision_binary_floating-point_format:_binary16 Das Format findet sich vielfach in der CMSIS-DSP: https://www.keil.com/pack/doc/CMSIS/DSP/html/group__FIR.html#ga9b5e4d748609deea033ce74fade70f78 Ich nehme mal an, es gibt einige ARMs, die das Format in ihren Recheneinheiten unterstützen.
chris_ schrieb: > Ich nehme mal an, es gibt einige ARMs, die das Format in ihren > Recheneinheiten unterstützen. Ich erinnere mich daran gelesen zu haben, dass dem nicht so und dass der Nutzen von half precision float deswegen sehr begrenzt sei. Ich kenne die Quelle nicht mehr. Wahrscheinlich war es eines der Bücher von Joseph Yiu.
Klaus W. schrieb: > Dann kommt man von Zehntausendstel bis gerade mal um die 65000 als > Wertebereich. Das kann man mit Festkomma auch leicht haben, Allerdings nicht mit nur 16 Bit. > und hat viel weniger Rechenaufwand, gerade bei einem AVR sucht man eher > keine Rechenzeitfresser. Man sucht aber auch keine Speicherfresser.
Klaus W. schrieb: > Wollte nur erwähnen, daß der praktische Nutzen wahrscheinlich limitiert > ist. Wie schon gesagt wurde, Bildverarbeitung z.B. auf einem FPGA. Ansonsten ist das Quatsch, insbesondere auf einem AVR.
Peter D. schrieb: > Klaus W. schrieb: >> Wollte nur erwähnen, daß der praktische Nutzen wahrscheinlich limitiert >> ist. > > Wie schon gesagt wurde, Bildverarbeitung z.B. auf einem FPGA. Ansonsten > ist das Quatsch, insbesondere auf einem AVR. Es wird wohl hauptsächlich für neuronale Netze eingesetzt. Direkte Hardwareunterstützung gibts es meines Wissens nur in neueren GPUs, dort dann aber mit bis zu 400 TFlop/s (NVidia A100), und einigen FPGAs (z.B. Intel Arria 10). X86 können nicht direkt damit rechnen aber es gibt Assemblerbefehle um Half-Floats als Speicherformat zu verwenden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.