Oki, hier die EXE meines Assemblercodes als FPU-Lösung aus Post #6 als Consolenanwendung in 1536 Bytes....Der identische Assemblercode, also auch knapp 1kByte in eine AutoIt-EXE kompiliert, ist knapp 1,15MB groß, also ca. 1000 (tausend! ) mal größer
Die in der CMD angegebene Zeit ist natürlich die reine Laufzeit des Codes (ohne das Laden der Exe zu berücksichtigen, das ist imho auch nonsens)
Pi_calc_Andy.zip
Bei mir hat Avira angefangen, irgendwelche Trojaner zu entdecken, als ich in den ASM-Code die Zeile
NUMBER dq 0.0
eingefügt hatte...damit wird nichts weiter gemacht, als 8 Bytes mit Nullen zu füllen
Wer will, kann die Datei einfach in FASMW laden und F9 drücken...
Ich probiere morgen mal das ein oder andere hiervon aus und schaue mal, ob das noch was bringt.
Ich werde bei der SSE/SIMD-Version Loop-Unrolling testen, und dann auch nicht die Zeit messen, sondern die benötigten Prozessortakte per RDTSC. Da lässt sich dann wesentlich besser optimieren, wenn man bspw. aus 10 Durchläufen den schnellsten nimmt.
//EDIT Loop unrolling und umsortieren bzw. "parallelisieren" (reorder/pairing) in der Instruction-Pipeline bringt zumindest bei meinem Prozessor nichts...
Ich habe aktuell 5.22 Prozessortakte pro Schleifendurchlauf. Da der sub ecx,1 und das anschließende jnz _loop zusammen 0,77 Takte benötigen, bleiben für die 4 SSE-Befehle 4.5 Prozessortakte.
Jetzt wird es interessant, denn das DIVPD benötigt allein 6.2 Takte!!! Durch die verschiedenen parallel arbeitenden Pipelines werden die Prozessorbefehle nicht "nacheinander" sondern wenn möglich gleichzeitig abgearbeitet. Man kann mehrere Zeilen völlig unnötiger Befehle in die Schleife einfügen, an der Laufzeit ändert sich...nichts!!!
Daher ist es sinnvoll beim Optimieren, wenn man sich die die sog. Serialisierung vornimmt und ausrechnet, welcher Befehl am besten wo in der Reihenfolge steht...um die "teueren" Abhängigkeiten (dependencies) aufzulösen!
http://www.agner.org/optimize/optimizing_cpp.pdf
http://www.agner.org/optimize/optimizing_assembly.pdf
http://www.agner.org/optimize/microarchitecture.pdf <-- DAS ist richtig klasse! Ich gehe davon aus, dass Compilerbauer dieses Dokument unter dem Kopfkissen liegen haben
@Mars, natürlich habe ich deine EXE laufen lassen und auch versucht zu disassemblieren, daher auch die Info, dass die Datei eine 64-Bit-Code-EXE ist und auch SSE-Befehle nutzt!
@Alle interessierten, und vor allem die, welche meinen, ein Compiler würde "automatisch" den besten Code erzeugen, ein (ihr kennt mich ja) ernst gemeinter Hinweis bzw. auch mal ein Grund, "nachzudenken".
Mal angenommen, ein "cleverer" Compiler merkt bei der Analyse des Codes, dass sich eine bestimmte Variable immer weiter an PI annähert.
Mit dem FPU-Befehl FLDPI, der aus 2 Bytes besteht und eine "Laufzeit" von 2-3 Prozessortakten hat, wäre PI auf 80bit genau bestimmt, und man könnte sich den Algorithmus sparen...
Mal weiter angenommen, im Code wäre dieses PI "zu genau" für weitere Berechnungen, dürfte dann der Compiler die ungenaue "Berechnung" von PI mit einem "besseren" PI ersetzen um im Endeffekt ein wesentlich schnelleres und genaueres Ergebnis auszugeben?
Was aber, wenn ich genau diese "ungenauen" Ergebnisse aber benötige, sollte ich als Programmierer dann die Wahl haben, "meinen" und genau diesen MEINEN Code generiert zu bekommen, oder doch den "optimierten" Code des Compilers?