Assemblercode - Noch optimierbar?

**chesstiger**

Hi allerseits,

bevor ich jetzt mit der Tür ins Haus falle, will ich eben mal die Rahmengeschichte zum Besten geben. Ich habe dieses Jahr mein Informatik-Studium begonnen. Im Modul OOP haben wir neulich im Praktikum einen einfachen Algorithmus zum Berechnen von Pi behandelt (die Leibniz-Reihe). Ein paar anderen erfahreneren Kommilitonen und mir war die reine Implementierung in Java ein bisschen zu fad, daher kamen noch ein paar andere Sprachen hinzu. Irgendwann wurde dann aus der reinen Implementierung ein kleiner Wettkampf um Performance/Geschwindigkeit. Gut, die Implementierungen in PHP oder JavaScript waren dann nicht mehr wirklich konkurrenzfähig. Auch Lua und Python waren nicht die besten Kandidaten. Tatsächlich war die Java-Variante zunächst die schnellste - bis mein C-Programm fertig war. Das war dann dezent schneller. Ein Kommilitone konnte das nicht auf sich sitzen lassen und hat eine eher unbekannte, ungewöhnliche Sprache verwendet: Pony. Auf meinem Netbook (Intel Celeron) braucht die Pony-Variante bei 10.000.000 Schleifendurchläufen mitsamt Ergebnisausgabe knapp 230 ms. Knapp doppelt so schnell wie mein C-Code...
Also musste jetzt das letzte Register gezogen werden (haha, Register...): Assembler.

Ich bin bei weitem kein Assembler-Profi. Ich kann zwar damit programmieren, aber die meisten Tricks kenne ich vermutlich nicht. Da das drumherum um den Algorithmus relativ kurz ist, habe ich direkt alles in Assembler geschrieben. Für knappe 20 ms schneller hat es auch gereicht, auf meinem Rechner also ~210 ms im Schnitt. Ich glaube nicht, dass das noch jemand schlägt. Aber ich bin mir fast sicher, dass es da noch Optimierungsmöglichkeiten gibt. Da sich hier auch einige Leute schon ausführlich mit Assembler auseinandergesetzt haben, dachte ich, ich frage mal, ob jemandem noch etwas einfällt. Kompiliert wurde das Ganze bei mir mit nasm, gelinkt mit gcc unter Debian 8. Die Zeiten wurden einfach im Terminal mit time gemessen.

Code

global main
extern printf


section .data
    stepc: dd 0
    pi: dq 0.0
    sign: dd 0
    store: dd 1
    four: dq 4.0
    msg: db "Pi: %f",10,0


section .text
    main:
    xor edx, edx


    loop:
    fld qword [pi]


    ;Bruch 4/... berechnen
    fld qword [four]
    fild dword [store]
    fdiv

    ;Vorzeichenwechsel und Addition
    cmp dword [sign], 0
    jnz sub
    fadd
    jmp afteradd
    sub:
    fsub


    ;Speichern Variable
    afteradd:
    not dword [sign] ;Flag für VZW
    fstp qword [pi]


    ;Schleifenkopf
    add dword [store], 2
    inc edx
    cmp edx, 10000000
    jnz loop


    ;Ausgabe (printf)
    push dword [pi+4]
    push dword [pi]
    push dword msg
    call printf
    add esp, 12
    mov eax, 0
    ret

Alles anzeigen

Ich denke mal, so ein paar ASM-Kniffe zu kennen, schadet keinem. Hat auf jeden Fall das Potential, sich zu einer spannenden Diskussion zu entwickeln.

Grüße!

**Mars**

Was mir direkt auffällt ist folgendes:
(1.) Du benutzt kaum Prozessorregister, aber dafür umsomehr RAM-Speicherplätze. Versuch mal das Programm so umzubasteln, dass du möglichst wenige Ram-Zugriffe hast. Im "Notfall" (falls kein Platz mehr ist) pop und push benutzen (ist schneller als ein RAM Zugriff).
(2.) (ab hier reine Spekulation) Ich kann mich irren, aber mit dem Schleifenzähler müsste es möglich sein rückwärts zu laufen (bei 10 Mio starten), und dann aus dem "dec ecx; cmp ecx, 0; jnz loop" das cmp rauszunehmen und zu "dec ecx; ja loop" zu machen. Ggf (muss man testen) ist auch sub ecx, 1 schneller als dec ecx (je nach Prozessor).
Edit1: (2.1) (habs jetzt nachgelesen). Schleifenvariable in ecx stecken (nicht edx, das ist doch nicht schön :D). Anschließend kann man entweder wie in (2.) verfahren, oder mit dem "loop loop1" (müsstest deinen loop ggf umbenennen sonst ist man verwirrt^^) gleichzeitig "dec ecx" und "ja loop1" ausführen. (hier muss man auch mit der Stopuhr schauen was von den beiden Varianten schneller ist)
(3.) Andy wird bestimmt noch irgendwas zum SSE sagen, was hier fehlt

Edit2: Spalte die Leibniz Summe auf.
Du hast in jedem Schleifendurchlauf ein not [sign], und eine Sprungstelle an der du entscheidest ob du addierst oder subtrahierst. Spalte die Summe in 2 Summen auf:
(1.) Summe von 0 bis N/2 [1/(4k+1)] -> Das sind alle positiven Werte bis N
(2.) Summe von 1 bis N/2 [1/(4k-1)] -> Das sind alle negativen Werte bis N
Jetzt kannst du die beiden Werte voneinander abziehen und hast damit kein wechselndes Vorzeichen und kein unnötiges If in der Schleife. (so wie du das mit dem [store] gelöst hast (das muss ein ein Register! Da wird doch andauernd was addiert :D), kann man das hier auch machen. Nur mit [store] += 4)

lg
M

**Andy**

Hi,

Zitat von chesstiger

Ich glaube nicht, dass das noch jemand schlägt. Aber ich bin mir fast sicher, dass es da noch Optimierungsmöglichkeiten gibt. Da sich hier auch einige Leute schon ausführlich mit Assembler auseinandergesetzt haben, dachte ich, ich frage mal, ob jemandem noch etwas einfällt.

Ich glaube schon, dass das noch jemand schlägt
Optimierungsmöglichkeiten: Neben den von Mars angesprochenen Möglichkeiten fällt mir sofort auf, dass du den Stack der FPU nicht nutzt! Dies sind 8 "Speicherstellen" in Registerform! Mal davon abgesehen, dass die FPU-Befehle schon "schnarchlangsam" sind (dazu später mehr ), speicherst du bspw. per fstp qword [pi], nur um es im Schleifenkopf kurz darauf wieder zu laden...mit [store]übrigens genauso...
Clever wird der FPU-Stack eingesetzt, indem "Konstanten", bspw. [four], permanent im Stack liegen und die weiteren Berechnungen ausschliesslich mit den registern durchgeführt werden, ohne permanent in den Speicher zu schreiben bzw. zu laden.
Das fld qword [pi] gehört vor den Loop (zusammen mit den anderen benutzten Variablen), und das fstp qword [pi] hinter den Loop. Du ersparst dir damit alleine 2*10E6 Speicherzugriffe/Takte!

Zitat von Mars

(3.) Andy wird bestimmt noch irgendwas zum SSE sagen, was hier fehlt

Und wie er das wird!
Die SEE-Befehle ADD/SUB/DIV werden in einem Takt abgewatscht, die schreien geradezu nach Benutzung! Und werden von jedem Prozessor, der in diesem Jahrtausend gefertigt wurde, unterstützt.
Auch ggf. erforderliche Vergleichsbefehle gibt es in SSE.
Ich werde dazu später mal ein Beispiel machen...
Inwieweit man SIMD (Single instruction, multiple data) einsetzt, ist zu testen, da Algorithmusabhängig. Wenn man 2 Berechnungsschritte gleichzeitig in einem Register abwickelt, braucht man nur noch die Hälfte der Schleifendurchläufe/Berechnungen!

**UEZ**

Mit FreeBasic komme ich auf 1136.025325860828 ms für 10.000.000 Iterationen -> Intel i5-4300U @ 2594 MHz

Der generierte Assembler Code:

Code

.globl _LEIBNIZ_PI@4
_LEIBNIZ_PI@4:
push ebp
mov ebp, esp
sub esp, 24
mov dword ptr [ebp-8], 0
mov dword ptr [ebp-4], 0
.Lt_0004:
mov dword ptr [ebp-12], 0
movlpd xmm7, [_Lt_000B]
movlpd [ebp-20], xmm7
mov dword ptr [ebp-12], 0
mov eax, dword ptr [ebp+8]
add eax, 4294967295
mov dword ptr [ebp-24], eax
jmp .Lt_0007
.Lt_000A:
mov eax, dword ptr [ebp-12]
and eax, 0xFFFF
cvtsi2sd xmm6, eax
mov eax, dword ptr [ebp-12]
shr eax, 16
cvtsi2sd xmm7, eax
mulsd xmm7, qword ptr [_Lt_000E]
addsd xmm6, xmm7
sub esp, 8
movlpd [esp], xmm6
push dword ptr [_Lt_000C+4]
push dword ptr [_Lt_000C]
call _pow
add esp, 16
mov eax, dword ptr [ebp-12]
shl eax, 1
inc eax
mov ecx, eax
and ecx, 0xFFFF
cvtsi2sd xmm6, ecx
mov ecx, eax
shr ecx, 16
cvtsi2sd xmm7, ecx
mulsd xmm7, qword ptr [_Lt_000E]
addsd xmm6, xmm7
sub esp, 8
fstp qword ptr [esp]
movlpd xmm0, qword ptr [esp]
add esp, 8
divsd xmm0, xmm6
addsd xmm0, qword ptr [ebp-20]
movlpd [ebp-20], xmm0
.Lt_0008:
inc dword ptr [ebp-12]
.Lt_0007:
mov eax, dword ptr [ebp-24]
cmp dword ptr [ebp-12], eax
jbe .Lt_000A
.Lt_0009:
movlpd xmm0, [_Lt_000D]
mulsd xmm0, qword ptr [ebp-20]
movlpd [ebp-8], xmm0
.Lt_0005:
fld qword ptr [ebp-8]
mov esp, ebp
pop ebp
ret 4
.balign 16

Alles anzeigen

FB Code:

Code

Function Leibniz_PI(n As UInteger) As Double
	Dim As Double fPI = 0.0
	For k As UInteger = 0 To n - 1
		fPI += (-1)^k / (2 * k + 1)
	Next
	Return 4 * fPI
End Function


Dim As UInteger iterations = 10000000
Dim As Double fTimer = Timer
Print Leibniz_PI(iterations), 1000 * (Timer - fTimer) & " ms for " & iterations & " iterations."


Sleep

Alles anzeigen

**Mars**

Habs auch mal in Go geschrieben (natürlich auch unoptimiert, sonst macht das ja keinen Spaß :D)

C

package main


import (
	"fmt"
	"time"
)


func main() {
	var runden int = 10
	var pi float64
	t1 := time.Now()
	for i := 0; i < runden; i++ {
		pi = Leibnitz_PI(10000000)
	}
	t2 := time.Now()
	fmt.Println("Benötigte Zeit [ms]: ", t2.Sub(t1).Nanoseconds()/int64(runden)/1000000)
	fmt.Println("                 PI: ", pi)
}


func Leibnitz_PI(n uint32) (pi float64) {
	var sign float64 = -1
	for n > 0 {
		n--
		pi += sign / float64(2 * n + 1)
		sign = - sign
	}
	return 4 * pi
}

Alles anzeigen

PS: Leibnitz.

Edit1: Ich komme mit Go auf 175ms. Allerdings weiß ich nicht wie die anderen hier geposteten Programme vergleichsweise auf meinem Rechner abschneiden, hab hier ausschließlich AutoIt und Go am Start. Die .exe aus der Konsole heraus ausführen (sonst geht das Fenster direkt wieder zu und man kann das Ergebnis nicht lesen).

**Andy**

Hier mal meine unoptimierte FPU-Version.
Unoptimiert deswegen, weil allein das FDIV schon (je nach Prozessor) 40 (!!!) Takte benötigt....aber egal, eine schöne Fleißübung
Allerdings habe ich es mir nicht nehmen lassen, KEINE einzige Speicherzelle zu verwenden Selbst die Rückgabe an AutoIt erfolgt über das ST0-Register, wenn als Rückgabetyp "double" verwendet wird.
Ca. 100ms auf meinem Laptop AMD A6-3400M APU, da sollte bei euren INTEL noch einiges gehen!

Spoiler anzeigen

AutoIt

;aligncomment=40
;#include <assembleit2_64.au3>


#AutoIt3Wrapper_UseX64=n




#cs Pi_Leibnitz
    Use32                                ;32Bit!


    finit                                ;FPU initialisieren


    mov ecx,[esp+4]                      ;n
    shr ecx,1                            ;n/2 es werden pro schleifendurchgang das positive und negative aufsummiert


    ;FPU-stack aufbauen
    fld1                                 ;st0=1
    fld1                                 ;st0=1 st1=1
    fadd st0,st1                         ;st0=2 st1=1
    fmul st0,st0                         ;st0=4 st1=1
    fld1                                 ;st0=1 st1=4 ;st2=1
    fld st1                              ;st0=4 st1=1 st2=4 st3=1
    fsub st0,st1                         ;st0=3 st1=1 st2=4 st3=1
    fchs                                 ;st0=-3 st1=1 st2=4 st3=1
    fldz                                 ;st0=0 st1=-3 st2=1 st3=4 st4=1


    _loop:                               ;so lange, bis ecx=0


    ;der stack muss am Anfang des loop so aussehen st0=PI/4 st1=negative st2=positive st3=4 st4=1
    ;in st0 wird PI gespeichert, st1 wird immer um 4 erniedrigt, st2 um 4 erhöht,
    ;st3 ist die schrittweite von 4 und st4 wird fürs reziprok 1/x benutzt


    fld st4                              ;st0=1 st1=0 st2=-3 st3=1 st4=4 st5=1
    fld st2                              ;st0=-3 st1=1 st2=0 st3=-3 st4=1 st5=4 st6=1
    fdivp st1,st0                        ;st0=1/-3 st1=0 st2=-3 st3=1 st4=4 st5=1
    ;pi speichern
    faddp st1,st0                        ;st0=-1/3=PI/4 st1=-3 st2=1 st3=4 st4=1
    fld st4                              ;st0=1 st1=PI/4 st2=-3 st3=1 st4=4 st5=1
    fld st3                              ;st0=1 st1=1 st2=PI/4 st3=-3 st4=1 st5=4 st6=1
    fdivp st1,st0                        ;st0=1/1 st1=PI/4 st2=-3 st3=1 st4=4 st5=1
    ;pi speichern
    faddp st1,st0                        ;st0=PI/4 st1=-3 st2=1 st3=4 st4=1
    ;4 zu st2 addieren und von st1 subtrahieren
    fld st3                              ;st0=4 st1=PI/4 st2=-3 st3=1 st4=4 st5=1
    fadd st3,st0                         ;st0=4 st1=PI/4 st2=-3 st3=5 st4=4 st5=1
    fsubp st2,st0                        ;st0=PI/4 st1=-3 st2=5 st3=4 st4=1


    sub ecx,1                            ;n=n-1
    jnz _loop                            ;wenn ecx<>0 dann _loop


    fld st3                              ;st0=4 st1=PI/4 st2=-3 st3=5 st4=4 st5=1
    fmul st0,st1                         ;st0=PI


    ;_asmdbg_()


    ;rückgabe bei double ist ST0
    ret


#ce




$n = 10000000




;Entweder der Einzeiler:
;$pi = _AssembleIt2("double", "Pi_Leibnitz", "uint", $n)




;oder für das dllcalladdress
;~ $binarycode = _AssembleIt2("retbinary", "Pi_Leibnitz")     ;gibt nur den assemblierten code zurück
;nur für dllcalladdress() benötigt, den binarycode braucht man nur ein mal erstellen




$binarycode = "0x9BDBE38B4C2404D1E9D9E8D9E8D8C1D8C8D9E8D9C1D8E1D9E0D9EED9C4D9C2DEF9DEC1D9C4D9C3DEF9DEC1D9C3DCC3DEEA83E90175E5D9C3D8C9C3"
$tCodeBuffer = DllStructCreate("byte[" & StringLen($binarycode) / 2 - 1 & "]") ;reserve Memory for opcodes
DllStructSetData($tCodeBuffer, 1, $binarycode)




$t = TimerInit()
$pi = DllCallAddress("double:cdecl", DllStructGetPtr($tCodeBuffer), "uint", $n)
$m = TimerDiff($t)
ConsoleWrite(@CRLF & ": $pi Leibnitz = " & $pi[0] & @CRLF & ": Time [ms] = " & $m & @CRLF & @CRLF)

Alles anzeigen

Damit mal richtig Spass aufkommt, werde ich auch die SSE/SIMD-Variante in Angriff nehmen, ich vermute Zeiten um die 20-30ms, also Faktor 3-4 zum FPU-Code!
Da werde ich auch "optimieren", d.h. nach Möglichkeit die Pipelines versuchen parallel zu füttern und auch "natürlich" keinerlei Speicherzugriffe . Auf einen C(++)-Code mit einem "schnellen" Ergebnis bin ich schon mal gespannt, es soll ja Leute geben, die meinen, ein Compiler macht das automatisch...

Und um dann komplett hardcoremäßig abzurocken könnte man mal versuchen, ob sich der Algorithmus so weit parallelisieren lässt, um per OpenCL auf einer Grafikkarte zu laufen.
Aber da wird schon "Double" das Problem sein , das ist ca. 20x langsamer als "Float".
Für OpenCL würde ich auf einer 50€-Grafikkarte bzw auf meiner integrierten APU realistisch 3-4 Millisekunden anpeilen. Und dabei gehen noch 80% der Zeit für den Daten-Transfer von und zur Grafikkarte flöten

**Mars**

Die ASM Version von Andy läuft bei mir in ca. 160ms. Damit ist sie knapp schneller als die Go variante.
(Hab hier einen Intel Q6600 Prozessor mit 2,4ghz, daher die miese Geschwindigkeit :D)

**Xorianator**

Zitat von Mars

Leibnitz

Wer?

**Mars**

Leibnitz mit TZ wie "Tür zu" [Plenk] !

**Xorianator**

Von wem redest du bitte?
Der Herr heißt Leibniz ohne t. Das ist höchstens ein UGS siehe Wikipedia. Und das auch eher noch wegen seines Vaters.

**Andy**

Zitat von Mars

Die ASM Version von Andy läuft bei mir in ca. 160ms. Damit ist sie knapp schneller als die Go variante.

Hmmm, die GO-Variante ist 64-Bit und nutzt schon fleißig SSE-Befehle
Kannst du 32-Bit-Code erzwingen und den dann mal bereitstellen? Ich gehe davon aus, dass der compilierte 32-Bit-Code kein Stück langsamer ist!

Zitat von Mars

Hab hier einen Intel Q6600 Prozessor mit 2,4ghz

ggf sollten wir mal eine Suite zusammenstellen mit den einzelnen Programmen, dann könnte man auch vergleichen, welche Befehle auf dem einen oder anderen Prozessor schneller oder langsamer ausgeführt werden! So wie ich die "alten" Prozessoren kenne, hat AMD da klare Vorteile bei der FPU gegenüber INTEL gehabt. Aber ich denke die "neueren" INTEL´s werden da noch einiges schneller laufen!

**UEZ**

Komisch, dass ich mit FB so bescheiden abschneide.

Mit VS2015 bekomme ich immerhin 328ms.

Ich habe absolut keinen Plan, wie ich den C++ Code optimieren kann geschweige denn, wie ich VS optimal einstellen kann.

Hier der C++ Code:

C

// Leibniz-PI.cpp : Defines the entry point for the console application.
//


#include "stdafx.h"
#include <iostream>
#include <limits>
#include <ctime>


using namespace std;
typedef std::numeric_limits< double > dbl;


double Leibniz_PI(int n)
{
	double fPI;
	int k;
	fPI = 0.0;
	for (k = 0; k < n; k++) {
		fPI += (pow(-1, k)) / (2 * k + 1);
	}
    return 4 * fPI;
}


void main()
{
	clock_t begin = clock();
	double fResult = Leibniz_PI(10000000);
	clock_t end = clock();
	double elapsed_msecs = double(end - begin) / CLOCKS_PER_SEC * 1000.0;


	cout.precision(dbl::max_digits10);
	cout << "Pi: " << fResult << '\t' << elapsed_msecs << " ms" << endl;


	cin.get();
}

Alles anzeigen

Keine Ahnung, wie ich die Zeit als x64 messen kann...

Wenn interesse besteht, kann ich die kompilierte EXE hochladen.

@Andy: auf meinem Schleppi -> Intel i5 @2,5 GHz

Code

: $pi Leibnitz = 3.14159255358979
: Time [ms] = 71.4103606789976

**Mars**

Einen Grund kann ich dir sagen: das pow(-1, k) frisst. Selbst wenn das intern effektiv gehandelt wird hast du damit mehr Rechenaufwand als wenn du eine Vorzeichenvariable einführst.

**UEZ**

Zitat von Mars

Einen Grund kann ich dir sagen: das pow(-1, k) frisst. Selbst wenn das intern effektiv gehandelt wird hast du damit mehr Rechenaufwand als wenn du eine Vorzeichenvariable einführst.

Stimmt!
Bezgl. FB: hätte nicht gedacht, dass die Laufzeit von 1136ms auf 136ms sinkt, wenn ich das so mache wie du es gemacht hast.

Edit: mit VS2015 habe ich 56ms hinbekommen.

C

// Leibniz-PI.cpp : Defines the entry point for the console application.
//


#include "stdafx.h"
#include <iostream>
#include <limits>
#include <chrono>


using namespace std;
typedef std::numeric_limits< double > dbl;


void main()
{


	auto start = std::chrono::high_resolution_clock::now();




	unsigned int k, n = 10000000;
	double fPI = 0.0, fSign = 1.0;
	for (k = 0; k < n; k++) {
		fPI += fSign / ((k << 1) + 1);
		fSign = -fSign;
	}
	fPI *= 4.0;




	auto end = std::chrono::high_resolution_clock::now();


	std::chrono::duration<double> elapsed = end - start;


	cout.precision(dbl::max_digits10);
	cout << "Pi: " << fPI << '\t' << elapsed.count() * 1000 << " ms for " << n << " iterations." << endl;


	cin.get();
}

Alles anzeigen

**Andy**

Ich werfe mal SSE/SIMD in die Runde...
Auf meinem AMD-Laptop 37ms bei 1.4Ghz, die Intels müssten da weit davonziehen, da das DIV dort massiv optimiert wurde

AutoIt

;aligncomment=40
;~ #include <assembleit2_64.au3>


#AutoIt3Wrapper_UseX64=n




#cs Pi_Leibnitz
    Use32                                ;32Bit!


    mov ecx,[esp+4]                      ;n
    shr ecx,1                            ;n/2 es werden pro schleifendurchgang das positive und negative aufsummiert


    xorpd xmm4,xmm4                      ;0.0 _ 0.0 die summe dieser beiden wird PI/4


    mov eax,1
    movd xmm0,eax
    pshufd xmm0, xmm0, 0xE0              ;1   _ 1
    CVTDQ2PD xmm0, xmm0                  ;1.0 _ 1.0


    mov eax,-4
    movd xmm1,eax
    CVTDQ2PD xmm1, xmm1                  ;0.0 _ -4.0


    neg eax                              ;4
    movd xmm2,eax
    CVTDQ2PD xmm2, xmm2                  ;0.0 _ -4.0
    PSLLDQ xmm2, 8                       ;4.0 _ 0.0
    paddq xmm1,xmm2                      ;4.0 _ -4.0


    mov eax,-3
    movd xmm3,eax
    CVTDQ2PD xmm3, xmm3                  ;0.0 _ -3.0
    movdqa xmm2,xmm0
    PSLLDQ xmm2, 8                       ;1.0 _ 0
    paddq xmm2,xmm3                      ;1.0 _ -3.0


    _loop:                               ;so lange, bis ecx=0
    movdqa xmm3,xmm0                     ;1.0 _ 1.0
    divpd xmm3,xmm2                      ;1/1 _ 1/-3
    addpd xmm4,xmm3                      ;links positive rechts negative, die summe ist PI/4
    addpd xmm2,xmm1                      ;positive um 4 erhöhen, negative 4 subtrahieren
    sub ecx,1                            ;n=n-1
    jnz _loop                            ;wenn ecx<>0 dann _loop


    pshufd xmm5, xmm4, 0x4E
    addpd xmm4,xmm5                      ;PI/4 _ -PI/4
    mulpd xmm4,xmm1                      ;PI _ -PI


    movhpd qword[esp+8],xmm4             ;PI


    fld qword[esp+8]                     ;st0=PI
    ;~     _asmdbg_()


    ret


#ce




$n = 10000000




;Entweder der Einzeiler:
;~ $ret = _AssembleIt2("double", "Pi_Leibnitz", "uint", $n, "double", $pi)




;oder für das dllcalladdress
;~ $binarycode = _AssembleIt2("retbinary", "Pi_Leibnitz") ;gibt nur den assemblierten code zurück
;nur für dllcalladdress() benötigt, den binarycode braucht man nur ein mal erstellen




$binarycode = "0x8B4C2404D1E9660F57E4B801000000660F6EC0660F70C0E0F30FE6C0B8FCFFFFFF660F6EC8F30FE6C9F7D8660F6ED0F30FE6D2660F73FA08660FD4CAB8FDFFFFFF660F6ED8F30FE6DB660F6FD0660F73FA08660FD4D3660F6FD8660F5EDA660F58E3660F58D183E90175EB660F70EC4E660F58E5660F59E1660F17642408DD442408C3"
$tCodeBuffer = DllStructCreate("byte[" & StringLen($binarycode) / 2 - 1 & "]") ;reserve Memory for opcodes
DllStructSetData($tCodeBuffer, 1, $binarycode)


$pi = 0.0
$t = TimerInit()
$ret = DllCallAddress("double:cdecl", DllStructGetPtr($tCodeBuffer), "uint", $n, "double", $pi)
$m = TimerDiff($t)


ConsoleWrite(@CRLF & ": $pi Leibnitz = " & $ret[0] & @CRLF & ": Time [ms] = " & $m & @CRLF & @CRLF)

Alles anzeigen

Die 128Bit breiten XMM-Register werden in 2x64Bit (je ein double) aufgeteilt.
In den linken 64Bit werden die positiven Teiler summiert, im rechten Registerteil die negativen Teiler.
Die gesamte Schleife besteht AUS NUR 4 ASM-Befehlen!
Nach der Schleife die beiden Registerhälften addieren zu PI/4 und mit 4 multiplizieren ergibt PI.

Da die FPU intern mit 80 Bit Genauigkeit rechnet, aber bei SSE/SIMD nur 64 Bit zur Verfügung stehen, ergeben sich die "Unterschiede" in den letzten 3 Nachkommastellen.
Geht da noch mehr?

**UEZ**

Top

Code

: $pi Leibnitz = 3.14159255358581
: Time [ms] = 28.442786194246

Hier die kompilierten Versionen von VS2015 C++ und FreeBasic als Anhang.

[Blockierte Grafik: http://www.hannover.de/var/storage/images/media/01-data-neu/bilder/redaktion-hannover.de/2016/2016_04/leibniz-butterkeks/13439944-1-ger-DE/Leibniz-Butterkeks_image_full.jpg]

gem

hey leute
super interessant das thema und spannend wie hier an allen ecken und kanten optimiert wird

hier mal meine testergebnisse.

Andy:

ASM:
: $pi Leibnitz = 3.14159255358581
: Time [ms] = 19.2128344097284

UEZ:
VS2015_C++_Leibniz-PI_x64
Pi: 3.1415925535897915 38.149658000000002 ms.
VS2015_C++_Leibniz-PI_x86:
Pi: 3.1415925535897915 38.162696000000004 ms.
FB_Leibniz-PI_x86
PI: 3.141592553589792 88.51868021884002 ms for 10000000 iterations.

mein pc:
intel core i3-4170 3.7ghz
win10x64
8 gb ram

**Mars**

Meins wird gernicht mit verglichen, hat niemand Go, oder traut sich niemand eine fremde .exe zu starten?
(Ich bin schon eine Weile hier im Forum, ich stecke keine Viren in Exen, die ist wirklich so groß nachdem der Kompiler sie ausspuckt)

**UEZ**

Test System (CPU): Intel(R) Core(TM) i5-4300U @2,5 GHz

Mars:

Code

Benötigte Zeit [ms]:  86
                 PI:  3.1415925535897933

Andy:

Code

: $pi Leibnitz = 3.14159255358581
: Time [ms] = 28.442786194246

UEZ:

Code

1) VS2015_C++_Leibniz-PI_x64
Pi: 3.1415925535897915  53.861474000000001 ms for 10000000 iterations.
2) VS2015_C++_Leibniz-PI_x86
Pi: 3.1415925535897915  54.446914999999997 ms for 10000000 iterations.
3) FB_Leibniz-PI_x86
PI: 3.141592553589792       127.8968800324947 ms for 10000000 iterations.

**chesstiger**

Ach du je, da habe ich ja was losgetreten.
Ich kann auch mal eine kompilierte Variante anhängen - allerdings nur als ELF. Ich habe zur Zeit keine Windows-Installation mehr.

Manche von den anfangs genannten Optimierungstipps hatte ich auch schon mal festgestellt - aber keinen Geschwindigkeitsvorteil erreicht. Daher habe ich sie zwecks Lesbarkeit wieder rückgängig gemacht. Als separat kompilierte Assembler-Datei ist der erste Vorschlag von Andy auf meinem System bspw. genau so schnell wie mein Assembler-Code aus dem ersten Post. Da kommt natürlich das Laden der Binärdatei noch hinzu (5.7 KB), Linux' time misst die Laufzeit einer Binärdatei inkl. Ladevorgang.

Ich probiere morgen mal das ein oder andere hiervon aus und schaue mal, ob das noch was bringt.