Optimierung noch weiter möglich ohne Genauigkeitsverlust?
-
Hi,
ich hab eben diesen Code gefunden:
http://xarent.hollosite.com/schnippel.php?id=2Klingt ja sehr vielversprechend und ist auch schneller als eine Division! Aber der Verlust von genauigkeit muss doch irgendwie noch weiter minimiert werden können.
Vielleicht mit SSE? (code?) Oder einer anderen Berechnung?
-
sqrt() benutzen und dafür weniger Wurzeln berechnen.
Bye, TGGC (Reden wie die Großen)
-
Was hat das mit Wurzeln zu tun? Es geht doch um Divisionen?
-
Ist #7.
Bye, TGGC (Reden wie die Großen)
-
Und du regst dich auf, wenn jemand am Thema vorbei redet. Klasse! Es geht um Divisionen und nicht um Wurzeln! Wobei ich diese Lookupdinger auch interessant finde.
-
Ich reg mich nicht auf, ich bleib ganz ruhig. Ist besser für das Herz.
Bye, TGGC (Reden wie die Großen)
-
ein _controlfp( _PC_24, _MCW_PC) kann wunder wirken.
einzelne fp-operatoren mit inline assembler zu implementieren führt in der regel sowieso nicht zu guten ergebnissen in komplexen ausdrücken. da gilt nach wie vor alles oder nichts
-
Also weitere Optimierung ist nicht mehr? hm mist
-
Also weitere Optimierung ist nicht mehr? hm mist
das hab ich nicht gesagt, nur mit diesem ansatz kommt man nicht viel weiter...
im übrigen kann man sich den letzten assembler befehl sparen, wenn auch noch das return statement entfernt wird. ausserdem soll es in der funktion sicher #ifdef heissen...
-
Was gibt es denn sonst noch für schnelle Lösungsansetze? evtl. andere Algos? Code?
-
Keine Ideen?
-
die behauptung, dass fdiv 20mal langsamer als mul ist ist absolut unhaltbar: hier mal die latenzzeiten wichtiger befehle für athlon 64 (athlon xp dürfte ähnlich sein):
FADD 4
FDIV 16/20/22 - je nach genauigkeit - siehe _controlfp(... )
FMUL 4
FSQRT 35
FLD 2+2 bei speicheroperanden
und für P4 Northwood(Prescott):
FADD 5(6)
FDIV 23/38/43(30/40/44)
FMUL 7(8)
FSQRT 23/38/43(30/40/44)bei float-genauigkeit ist fdiv also höchstens viermal langsamer als fmul - das macht diese fdiv funktion völlig wertlos - durch den funktionsoverhead und die speicheroperanden ist es definitiv wesentlich langsamer als eine normale division mit geringer genauigkeit. entscheidend ist dabei nicht die größe der operanden, sondern die vorher eingestellte genauigkeit der fpu. für sqrt dürfte das ergebnis ähnlich aussehen. was sonstige optimierungen angeht - wie ich bereits anmerkte: wenn inline assembler, dann den gesamten ausdruck (bzw. die gesamte schleife), der nat. bereits vorher geeignet mathematisch aufbereitet werden sollte. andernfalls wird der entstehende overhead durch funktionscalls den zeitgewinn in aller regel übersteigen.
