Fixpoint - library bzw. sinnvolles Vorgehen

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Warf
Beiträge: 1445
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: MacOS | Win 10 | Linux
CPU-Target: x86_64
Wohnort: Aachen

Re: Fixpoint - library bzw. sinnvolles Vorgehen

Beitrag von Warf »

Winni hat geschrieben:Hintergrund ist, dass die 32 Bit Processoren mit extended als 80 Biter umgehen können, die 64 Bit Procs von AMD und Intel aber nicht.
Für Details frag bitte die Assembler Fraktion - dazu gehöre ich nicht.

Winni


Die Story dahinter ist sogar recht interessant. Die 80-Bit Floats wurden eingeführt von Intel als kompromiss zwischen den Anfragen von Entwicklern nach genauerer Fließpunktarithmetik und der Maximalen größe des Multiplikationswerks was Intel damals in die ALU bauen konnte (die haben praktisch ihre Ingeneure gefragt, und die haben gesagt das mehr als 64 bit Mantisse nicht möglich ist). Damit war Intel aber ursprünglich nicht zufrieden und wollte dann nach ein paar CPU Generationen auf upgraden (z.b. auf 128-bit), für die selben OP-Codes, und hat daher angegeben man solle die Größe nicht annehmen um kompatibilitiätsproblemen vorzubeugen. Daran haben sich die entwickler allerdings nicht gehalten, weshalb das upgrade nie möglich war und intel damit auf den 80 bit rumsaß obwohl sie selbst damit extrem unglücklich sind.

Daher kein wunder das sie mit 64-Bit den kram rausgeschmissen haben. Warum sie keinen neuen Extended Float eingebaut haben (z.b. Quadrupel) weiß ich aber auch nicht. Vielleicht haben sie gedacht das die CPU und GPU leistung mittlerweile so gut ist, das für die Fälle in denen man das braucht auf Software Floats (z.b. GMP) zrückgreifen kann, und das für die meisten Anwendungsfälle ausreichend ist

Warf
Beiträge: 1445
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: MacOS | Win 10 | Linux
CPU-Target: x86_64
Wohnort: Aachen

Re: Fixpoint - library bzw. sinnvolles Vorgehen

Beitrag von Warf »

Ich habe mal eben auch eine eigene fixpunkt implementierung relativ naiv gemacht und das ganze mal gegen currency gebenchmarkt (projekt im anhang), hier die ergebnisse:

Code: Alles auswählen

64 bit
Currency From Integer: 78 ms
Fixpoint From Integer: 78 ms
Currency From Double: 578 ms
Fixpoint From Double: 578 ms
Currency Add: 63 ms
Result:  6.003516491620000000E+08
Fixpoint Add: 219 ms
Result: 600351649.1620
Currency Mul: 468 ms
Result:  4.842908424700000000E+06
Fixpoint Mul: 485 ms
Result: 4842908.4247
32 bit
Currency From Integer: 78 ms
Fixpoint From Integer: 125 ms
Currency From Double: 250 ms
Fixpoint From Double: 797 ms
Currency Add: 532 ms
Result:  6.003516491620000000E+08
Fixpoint Add: 375 ms
Result: 600351649.1620
Currency Mul: 953 ms
Result:  4.842908468400000000E+06
Fixpoint Mul: 1531 ms
Result: 4842908.4247
 



Für x86_64 (also 64 bit) ist lediglich die Addition deutlich langsamer (was mich wundert, da das ja nur die Integer addition ist) der rest scheint performancemäßig identisch zu sein.
Auf i386 ist das aber ne ganz andere Geschichte, hier ist meine Fixpunkt implementierung viel langsamer in allen belangen, außer der Addition (was wieder mal seltsam ist), und außerdem scheint sich das rundungsverhalten von Currency mit der Architektur zu ändern.

Das mit dem runden ist äußerst interresant, da wüsste ich gerne woran das liegt, und was bei 32 bit intern gemacht wird. Aber zumindest auf 64 bit kann man eindeutig sagen das ich gar nicht so falsch lag, letztenendes macht Currency anscheinen vergleichbares zu meinem Naiven ansatz, und ist bei der Addition sogar schneller
Dateianhänge
Fixpunkt.zip
(2.85 KiB) 23-mal heruntergeladen

Antworten