DevPandi schrieb:
Ach, wird es das? Nun, dafür gibt es den Standard
IEEE 754-2008 und fast alle heutigen CPUs laufen mit diesem Standard. Da wird alles vom Datenformat bishin zu den notwendigen Rundungen bei der Berechnung definiert.
Blöde nur, dass Contractions wie FMA das wieder kaputt machen, und die sind bei IEEE und C erlaubt. Das Ergebnis von a+b*c ist dann abhängig davon, welche Instruktionen der Compiler dafür generiert, und wenn er z.B. auf ARM Contractions benutzt und auf x86 nicht, dann ist das Ergebnis mitunter unterschiedlich. Und da reden wir noch nicht einmal von Compiler-Bugs und unzulässigen Optimierungen (hallo icc!).
DevPandi schrieb:
Auch hier gilt im übrigen bereits erneut: Es gibt genug Bibliotheken und auch Frameworks, die sich genau um solche Sachen kümmern, damit das eigene Programm protabel bleibt.
Womit wir wieder bei der Ausgangsfrage sind: Wenn man FP-Code reproduzierbar und portabel haben will, dann muss man das schon von vorne herein eine entsprechende Bibliothek abstrahieren. Die Spring RTS-Engine etwa verwendet streflop dafür. Einfach nur den Code auf verschiedenen Plattformen zum Laufen bringen reicht nicht - das führt zu desync zwischen verschiedenen Spielteilnehmern, weil die Simulationen dann beginnen, auseinanderzulaufen. (Bei Multiplayer-RTS hat jedes teilnehmende System typischerweise eine Simulation der gesamten Spielwelt und es werden nur die Eingabebefehle ausgetauscht.) Wenn man nur seinen x86-Code für ARM kompiliert, dann kann das gut gehen, muss aber nicht, selbst ohne x86-spezifische Instruktionen im Code.
Hier gibt es einen sehr guten Blog-Eintrag zum Nachlesen, was bei der Portierung von FP-Code zwischen verschiedenen Betriebssystemen und Prozessorarchitekturen schiefgehen kann:
https://yosefk.com/blog/consistency-how-to-defeat-the-purpose-of-ieee-floating-point.html
DevPandi schrieb:
Aber alleine das Zahlenformat bedingt schon, dass man hier mit gewissen Ungenaugikeiten leben muss und entsprechend gibt es auch Empfehlungen, dass man mit Deltas arbeiten soll, die den Grad der Ungenauigkeit definiere soll, mit der man leben kann.
Wenn du aber zu den gehörst, die bei Gleitkommaberechnungen erwarten, dass a == b ist, wirst du in der Regel selbst auf der selben Plattform enttäuscht werden. Ich hab es schon oft genug erlebt - auch auf IA32 - dass eine ansich gleiche Berechnung am Ende minmal sich unterschieden hat, weil die Zahl zwar als reelle Zahl gleich waren - Anzeige - aber intern ein minimaler Unterschied herrschte. 0.1 ist eben nicht 0.1 bei Gleitkommazahlen.
Es geht mir nicht um Genauigkeit, sondern um Reproduzierbarkeit. Bezieht sich "ansich gleiche Berechnung" auf den gleichen Quellcode oder den gleichen Binärcode? Oder nur etwas oberflächlich ähnliches?
DevPandi schrieb:
Ja und Nein. Office hat als Dateiformat früher keine art Speicherdump verwendet, sondern ein binäres Format.
Binär war es bis zu OOXML sowieso, aber in den frühen Tagen von Office war es zudem im Wesentlichen ein Speicherdump. Um das Laden und Speichern zu beschleunigen, wurden direkt C-Datenstrukturen 1:1 in die Datei kopiert.
https://www.joelonsoftware.com/2008...-formats-so-complicated-and-some-workarounds/
DevPandi schrieb:
Da aber x86, RISC-V und ARM mit Little-Endian arbeiten, sind die Probleme ohnehin eher theoretischer Natur und für die meisten Entwickler irrelevant.
Alignment ist bei ARM64 anders als bei x86 (und x86_64) und das hat nichts mit Endianness zu tun.
DevPandi schrieb:
Auf der einen Seite trivalisierst du Probleme der Umwandlung, auf der anderen Seite werde dramatisierst du diese Probleme und versuchst Probleme herbeizureden, die so nicht existieren oder die allgemein - also kein µArch-Problem - ein Problem sind, weil sie mit dem Datenformat zusammenhängt.
Wo dramatisiere ich? Ich versuche nur zu erklären, warum es nicht unbedingt reicht, sein Programm zum laufen zu bringen, und welchen Umständen Probleme erwartet werden können. Und ich denke Microsoft hätte sich für ein paar poplige Plugins ihrer Kunden nicht die Mühe mit ARM64EC gemacht.
