Das Rad wurde auch nicht dafür erfunden, um mit 200Km/h über die Autobahn zu brettern, sondern um mit Esel-Geschwindigkeit über den Acker zu gondeln...
Genau das meinte ich mit anpassen.
"der kurze Bippes"!!!
Das Rad wurde auch nicht dafür erfunden, um mit 200Km/h über die Autobahn zu brettern, sondern um mit Esel-Geschwindigkeit über den Acker zu gondeln...
Genau das meinte ich mit anpassen.
"der kurze Bippes"!!!
Ich bin ehrlich gesagt erstaunt dass hier einige mal schnell einen Compiler von den Devs fordern als wärs das simpelste auf der Welt.
Wieviel dynamisch typisierende Sprachen kennt ihr für die es Compiler gibt?
Mir fällt da auf Anhieb nur Common Lisp ein.
Selbst bei Python wo milliardenschwere Unternehmen ein Interesse an der Weiterentwicklung haben gibt es keinen derartigen vollumfänglichen Compiler. Auch dort muss man seinen Code extra statisch typisieren und derartige Späße veranstalten.
Jetzt verlangt (!!) ihr einfach so mal von den kleinen AutoIt-Devs was auf die Beine zu stellen was viel größere auch noch nicht hinbekommen haben.
Auch wäre es fraglich ob allein durch eine Kompilierung eine Performance wie z.B. bei FreeBasic erreicht werden kann. Schon allein durch den Variant-Typ ist derart viel Overhead in den Code einzubringen dass dort eine Menge Performance auf der Strecke liegen bleibt.
Und andererseits: Es wird von den Devs gefordert. Die Sprache ist euch doch aber auch bekannt. Wenn die Devs von ihrer Entscheidungsfreiheit Gebrauch machen und die Sache ähnlich sehen wie ich dann schreibt doch einfach selbst einen Compiler.
Wobei - müsst ihr nichtmal. Wenn ihr LLVM als Unterbau verwendet braucht ihr im Grunde nur ein Tool welches den AutoIt-Code in die LLVM-IR-Sprache übersetzt. Den klasse Compiler habt ihr dann schon daliegen.
Ich behaupte aber dennoch: Schon dieses Unterfangen wird scheitern - man muss einfach viel zu viele Verrenkungen einbauen um das Verhalten von AutoIt compilerfähig zu bekommen.
Wird wohl der Grund sein warum die meisten anderen derartigen Sprachen eher ByteCode-Interpreter verwenden. Also den eigentlichen Code in eine vereinfachte Zwischensprache wandeln welche für den Interpreter leichter zu parsen ist (mit der Möglichkeit dabei auch gleich den Code noch zu optimieren). Vielleicht wäre das der eher zweckmäßige Weg als sich auf das Wagnis AutoIt-Compiler einzulassen. Am Ende reicht es aber dennoch nicht das nur viele fordern sondern das einer auch mal aufsteht und loslegt.
Ich bin ehrlich gesagt erstaunt dass hier einige mal schnell einen Compiler von den Devs fordern als wärs das simpelste auf der Welt.
Einen Compiler braucht AutoIt wirklich nicht, es arbeitet flott genug und soll für intensive Rechnungen und Bearbeitungen schließlich nicht genutzt werden. Kleine Scripte die bei Hochsprachen wesentlich komplexer zu schreiben sind ist das Ziel von AutoIt und solange man einen effizienten Interpreter hat wird das hier sicherlich niemanden stören.
Auch wäre es fraglich ob allein durch eine Kompilierung eine Performance wie z.B. bei FreeBasic erreicht werden kann. Schon allein durch den Variant-Typ ist derart viel Overhead in den Code einzubringen dass dort eine Menge Performance auf der Strecke liegen bleibt.
Den Overhead kann man sicherlich reduzieren indem man beim Compilen Optionen anbietet die das deklarieren der Variablen erfordern und somit auf wenige Typen begrenzen - aber wie gesagt -
das ist nicht Sinn und Zweck von AutoIt.
Ich bin ehrlich gesagt erstaunt dass hier einige mal schnell einen Compiler von den Devs fordern als wärs das simpelste auf der Welt.
Ich bin hingegen garnicht erstaunt, daß der imho schon von einer Entwicklerin vor Jahren wenigstens als Prototyp lauffähige Compiler (ja, und das war schon zu Valiks Zeiten Thema!) in ihrer Schublade liegt.
Und "gefordert" wird von mir nichts!
Mal von sämtlichen technischen Hintergründen abgesehen ist es aber die eine Sache, unisono "gibt es nicht, und wird es nie geben..." von Entwicklerseite zu hören oder ein "...muss niemand Arbeit investieren, wir haben etwas am köcheln, dauert ggf. noch einige Jahre, gibt höhere Prioritäten!".
Es stellt sich nicht die Frage des Könnens (oder doch?!) sondern die des Wollens. Oder will man nicht weil man nicht kann? Dann steht wieder die Frage im Raum wieso man nicht jemanden die Arbeit machen lässt, der es kann....
Am Ende reicht es aber dennoch nicht das nur viele fordern sondern das einer auch mal aufsteht und loslegt.
Ich spinne jetzt mal bissl rum und offenbare, dass du morgen einen AutoIt-Compiler, und wenn auch nur als "Krücke", released. Spätestens übermorgen werden im "blauen" Forum HUNDERTE neuer Threads erstellt werden, und ich verwette meinen rechten Arm, JEDER davon wird abgeschmettert mit dem Hinweis "..ist nicht von uns, haben wir nix mit zu tun, wende dich an den Entwickler hier gibts keine Unterstützung..."
Ich bin immer noch davon überzeugt, dass AutoIt für 99% aller Aufgaben gut geeignet und schnell genug ist. Leider zieht das eine Prozent aus o.g. Gründen gute Leute ab. Mal schnell "quick´n´dirty" mit einer Handvoll "Basic-ähnlicher" Zeilen eine Lösung ausarbeiten, dabei ist AutoIt imho ungeschlagen. Im professionellen Umfeld nutze ich dazu die 3.3.8.1 , da weiß ich was ich habe und alles was ich will funktioniert auch.
Leider gibt es keinen Lead Coder mehr und dadurch ist die Entwicklung stehengeblieben . Es werden i.d.R. nur Bugs gefixt, aber sonst passiert leider nichts mehr und wie es aussieht, wird auch nicht mehr viel passieren.
Jon hat andere Interessen und die Community "dümpelt" vor sich hin.
Wer mit grafischen Spielereien zu tun hat, wird schnell feststellen, dass die Grenzen von AutoIt sehr schnell erreicht werden können. Das impliziert, ja sogar schreit förmlich, nach Methoden, um die Rechenoperation zu beschleunigen.
Eine Variante ist Inline ASM, eine andere zeitkritische Berechnungen in eine DLL auszulagern. Da Frage ich mich, warum ich nicht gleich komplett umsteigen soll, z.B. die "brotlose Kunst" gleich in FB zu schreiben.
Je mehr ich mit FB arbeite, desto mehr gefällt es mir, denn FB hat mehr oder weniger alles, was man benötigt. Man kann auch andere Kompiler einbinden, z.B. wie bereits oben erwähnt wurde LLVM-IR.
Ich werde wohl den grafischen Schnick-Schnack nur noch in FB coden, denn außer GDI / GDI+ sind auch andere Schnittstellen, wie OpenGL implementiert + Inline ASM.
die "brotlose Kunst" gleich in FB zu schreiben
So treten wir nie auf der Revision auf
So treten wir nie auf der Revision auf
Ich hab ein echt heißes Eisen im Feuer, da werden wir die Revision mal richtig aufmischen
Das einzige, was AutoIt damit zu tun haben wird ist der Aufdruck auf meinem T-Shirt . Das werde ich wohl aus Pietätsgründen tragen und wg. der "guten alten Zeiten".
Den Overhead kann man sicherlich reduzieren indem man beim Compilen Optionen anbietet die das deklarieren der Variablen erfordern und somit auf wenige Typen begrenzen
Dann ist es ja wie gesagt kein AutoIt mehr sondern eine Abwandlung.
Eine Eigenschaft der Sprache AutoIt ist ja eine dynamische Typisierung.
Durchaus eine Lösung aber dann bewegen wir uns schon fort von den Wünschen (und Vorstellungen) die manche hier an einen AutoIt-Compiler stellen.
Automatische Typenerkennung zur Compilezeit wird auch nicht 100% funktionieren. Gerade wenn man mit externen Datenquellen hantiert.
Ich spinne jetzt mal bissl rum und offenbare, dass du morgen einen AutoIt-Compiler, und wenn auch nur als "Krücke", released. Spätestens übermorgen werden im "blauen" Forum HUNDERTE neuer Threads erstellt werden, und ich verwette meinen rechten Arm, JEDER davon wird abgeschmettert mit dem Hinweis "..ist nicht von uns, haben wir nix mit zu tun, wende dich an den Entwickler hier gibts keine Unterstützung..."
Das wäre doch auch vollkommen richtig.
Die Sprache hat mit der Implementierung erst einmal nichts zu tun.
Wenn ein unabhängiger eine andere Implementierung erstellt haben die AutoIt-Devs schlicht nichts mehr damit zu tun. Warum auch?
Man muss bei Problemen dann nämlich zwischen Fragen zur Sprache und Fragen zur Implementierung unterscheiden. Und ob die Sprache wirklich komplett unangetastet bei einem Compiler bleiben kann ist dann auch nochmal die nächste Frage.
Kleine Scripte die bei Hochsprachen wesentlich komplexer zu schreiben sind ist das Ziel von AutoIt
AutoIt ist eine Hochsprache
Ich verstehe ja die Diskussion durchaus.
Die Performance ist bei anderen Sprachen einfach in deren Implementierung deutlich schneller.
Aber alles kann halt auch keine Sprache liefern. Einfachheit vs. Performance bedingt immer irgendwo eine Nivellierung.
Eine einfache Sprache wie z.B. Python kann in ihrer Standardimplementierung CPython ebenfalls kein Threading. Dafür kann man schnell gute Ergebnisse produzieren. Bei den C-Sprachen kriegt man hingegen ne Macke bei den ganzen Typumwandlungen bei welchen man sich bei z.B. AutoIt keine Gedanken machen braucht. Die Diskussionen gibt es in jeder Sprache nicht nur bei AutoIt. Und man wird irgendwann zum Schluss kommen das man eben das Werkzeug passend zur Aufgabe wählt auch wenn das heißt das man nicht alles mit seiner Lieblingssprache abhandeln kann.
AutoIt ist eine Hochsprache
Du weißt ganz genau das das in Relation zu C/C++ gesetzt war
Ich hab ein echt heißes Eisen im Feuer, da werden wir die Revision mal richtig aufmischen
Ich bin gespannt!
Du weißt ganz genau das das in Relation zu C/C++ gesetzt war
Dann bleibt AutoIt nach wie vor eine Hochsprache, sogar eine noch höhere
Hehe - klar. Aber man wird doch wohl noch krümelkacken dürfen...
Wenn ein unabhängiger eine andere Implementierung erstellt haben die AutoIt-Devs schlicht nichts mehr damit zu tun. Warum auch?
Das stimmt, wenn allerdings ein Mitglied des "inner circle" solch ein Projekt in der Schublade hat, dann wird es spannend!
Wenn man als Projektleiter/Manager merkt, dass jemand im Team in bestimmten Bereichen überragende Fähigkeiten besitzt, dann gehört dieser Jemand zum Wohle des Projekts gefördert und nicht abgesägt/gebremst! Wenn im Laufe der Zeit mehrere Leute mit überragenden Fähigkeiten das Team verlassen, dann hat das Gründe. "Es darf keine anderen Götter neben mir geben.." ist einer davon!
BTT, wann kommt der 2. Teil von "AutoIt vs FreeBasic"
BTT, wann kommt der 2. Teil von "AutoIt vs FreeBasic"
Ich muss mal sehen, was in AutoIt so einigermaßen läuft. Dieses Beispiel mit 1000 Pixel bei 15 FPS ist recht ordentlich für AutoIt Verhältnisse, wobei der Effekt erst ab 5000 Pixel zur Geltung kommt.
Wer ist der Gewinner von Runde 1?
Wer ist der Gewinner von Runde 1?
Wir alle, weil wir was dazu gelernt haben.
BTT, wann kommt der 2. Teil von "AutoIt vs FreeBasic"
Bitte sehr.
Wen wundert's - keine Überraschung.
Hi,
kein Wunder, da genau der "langsame" DllStructSetData() in einem ewig langen Loop wieder verwendet wurde.
Übrigens ist es bei mir so, dass beim FB-Programm der Fensterinhalt schwarz wird, sobald ich das Fenster nur zu einem kleinen Teil über den Bildschirmrand schiebe...
Könntest du die Funktion Mandeliter() solo in eine Dll packen bzw den gesamten For $iY = 0 To $iH - 1For $iX = 0 To $iW - 1-loop.
Ich würde da gerne mal mit dem Disassembler drübergucken, FB produziert imho einen "schönen" Code....
Auch im Hinblick auf auf weitere "Battles" hätte ich gerne Anwendungen gesehen, welche von den bei FB und AutoIt gleich schnell ausgeführten API-Funktionen (ist das so?) abhängig sind.
BugFix hatte mich mal vor Jahren auf "schnelle(re)" Arrayfunktionen angesetzt, ich habe damals ein Script geschrieben, welches bestehenden AutoIt-"Array"-Code komplett auf DllStruct-Code umschrieb. Der Geschwindigkeitsvorteil war nicht sonderlich groß, wobei wir wieder beim Thema DllStructSet/GetData wären...
Logischerweise macht das nur Sinn, wenn auch die Datentypen "gleich" und schön zu verarbeiten sind.
In FB sollten imho auch Arrayfunktionen (Arraysort bspw) wesentlich schneller arbeiten.
Hat jemand noch weitere Beispiele für "langsamen" AutoItcode? Also so langsam, dass das Script/Anwendung unbenutzbar wird? Mich interessieren Anwendungen aus der Praxis, die aufgrund der Geschwindigkeit von AutoIt dessen Verwendung ausschließen.
kein Wunder, da genau der "langsame" DllStructSetData() in einem ewig langen Loop wieder verwendet wurde.
Ich habe es nicht getestet, aber eine schnellere Methode als diese um direkt Pixels in die Bitmap zu schreiben gibt es nicht. Jeder API Aufruf dürfte mehr Zeit kosten.
Übrigens ist es bei mir so, dass beim FB-Programm der Fensterinhalt schwarz wird, sobald ich das Fenster nur zu einem kleinen Teil über den Bildschirmrand schiebe...
Sollte doch so ähnlich auch in AutoIt sein, dass der Gfx Handle überschrieben wird. Ich müsste ein WM Funktion einbauen, dass beim Löschen die Bitmap wieder in die GUI blittet.
Ich würde da gerne mal mit dem Disassembler drübergucken, FB produziert imho einen "schönen" Code....
Function mandelIter:
.intel_syntax noprefix
.section .text
.balign 16
.globl _MANDELITER@12
_MANDELITER@12:
push ebp
mov ebp, esp
sub esp, 28
push ebx
mov dword ptr [ebp-4], 0
.Lt_0004:
movss xmm7, [_Lt_0008]
movss [ebp-8], xmm7
mov dword ptr [ebp-12], 0
mov dword ptr [ebp-16], 0
mov dword ptr [ebp-20], 0
mov dword ptr [ebp-24], 0
mov eax, dword ptr [ebp+16]
mov dword ptr [ebp-28], eax
.Lt_0006:
movss xmm6, [ebp-20]
addss xmm6, dword ptr [ebp-16]
comiss xmm6, dword ptr [_Lt_0009]
setbe al
shr eax, 1
sbb eax, eax
mov ebx, dword ptr [ebp-28]
test ebx, ebx
setg bl
shr ebx, 1
sbb ebx, ebx
and eax, ebx
je .Lt_0007
movss xmm6, [ebp-12]
mulss xmm6, dword ptr [ebp-8]
movss [ebp-24], xmm6
movss xmm6, [ebp-8]
mulss xmm6, dword ptr [ebp-8]
movss [ebp-16], xmm6
movss xmm6, [ebp-12]
mulss xmm6, dword ptr [ebp-12]
movss [ebp-20], xmm6
movss xmm6, [ebp-16]
subss xmm6, dword ptr [ebp-20]
addss xmm6, dword ptr [ebp+8]
movss [ebp-8], xmm6
movss xmm6, [ebp-24]
unpcklps xmm6, xmm6
pshufd xmm7, xmm6, 0x01
addss xmm6, xmm7
addss xmm6, dword ptr [ebp+12]
movss [ebp-12], xmm6
dec dword ptr [ebp-28]
jmp .Lt_0006
.Lt_0007:
mov ebx, dword ptr [ebp+16]
sub ebx, dword ptr [ebp-28]
mov dword ptr [ebp-4], ebx
.Lt_0005:
mov eax, dword ptr [ebp-4]
pop ebx
mov esp, ebp
pop ebp
ret 12
.balign 16
.globl _main
_main:
push ebp
mov ebp, esp
and esp, 0xFFFFFFF0
sub esp, 4
mov dword ptr [ebp-4], 0
call ___main
push 0
push dword ptr [ebp+12]
push dword ptr [ebp+8]
call _fb_Init@12
.Lt_0002:
.Lt_0003:
push 0
call _fb_End@4
mov eax, dword ptr [ebp-4]
mov esp, ebp
pop ebp
ret
.section .data
.balign 4
_Lt_0008: .long 0x00000000
.balign 4
_Lt_0009: .long 0x40800000
Alles anzeigen
Der gesamte Code:
.file "Mandelbrot.c"
.intel_syntax noprefix
.section .text.unlikely,"x"
.LCOLDB9:
.text
.LHOTB9:
.p2align 4,,15
.globl MANDELBROT
.def MANDELBROT; .scl 2; .type 32; .endef
MANDELBROT:
.L2:
push r15
push r14
subss xmm1, xmm0
push r13
push r12
subss xmm3, xmm2
push rbp
push rdi
push rsi
push rbx
sub rsp, 328
mov eax, DWORD PTR IH$[rip]
movaps XMMWORD PTR 160[rsp], xmm6
pxor xmm6, xmm6
mov r15d, DWORD PTR 432[rsp]
movaps XMMWORD PTR 224[rsp], xmm10
pxor xmm10, xmm10
lea r14, 136[rsp]
cvtss2sd xmm6, xmm2
lea r13, 140[rsp]
lea r12, 144[rsp]
movaps XMMWORD PTR 192[rsp], xmm8
mov DWORD PTR 96[rsp], eax
sub eax, 1
mov QWORD PTR 152[rsp], 0
movsd QWORD PTR 104[rsp], xmm6
pxor xmm6, xmm6
movaps XMMWORD PTR 208[rsp], xmm9
mov DWORD PTR 112[rsp], eax
movaps xmm8, xmm1
movaps XMMWORD PTR 176[rsp], xmm7
lea rbp, 148[rsp]
movaps XMMWORD PTR 240[rsp], xmm11
movaps XMMWORD PTR 256[rsp], xmm12
movaps XMMWORD PTR 272[rsp], xmm13
movaps XMMWORD PTR 288[rsp], xmm14
movaps XMMWORD PTR 304[rsp], xmm15
movss DWORD PTR 116[rsp], xmm3
cvtss2sd xmm10, xmm0
mov eax, DWORD PTR 440[rsp]
mov DWORD PTR 84[rsp], 0
movsd xmm9, QWORD PTR .LC3[rip]
mov QWORD PTR 120[rsp], rax
mov eax, DWORD PTR IW$[rip]
mov DWORD PTR 100[rsp], eax
movsd xmm11, QWORD PTR .LC4[rip]
.L3:
mov ebx, DWORD PTR 100[rsp]
mov edi, DWORD PTR 84[rsp]
xor esi, esi
pxor xmm14, xmm14
pxor xmm0, xmm0
mov eax, ebx
pxor xmm7, xmm7
sub eax, 1
movsd xmm12, QWORD PTR .LC6[rip]
mov DWORD PTR 80[rsp], eax
mov eax, edi
cvtsi2ssq xmm14, rax
mov QWORD PTR 88[rsp], rax
mov eax, DWORD PTR 96[rsp]
movsd xmm13, QWORD PTR .LC5[rip]
imul edi, ebx
sub rax, 1
cvtsi2sdq xmm0, rax
mov eax, ebx
mov ebx, r15d
sub rax, 1
cvtsi2sdq xmm7, rax
mulss xmm14, DWORD PTR 116[rsp]
cvtss2sd xmm14, xmm14
divsd xmm14, xmm0
addsd xmm14, QWORD PTR 104[rsp]
cvtsd2ss xmm14, xmm14
.p2align 4,,10
.L4:
pxor xmm4, xmm4
mov eax, esi
test ebx, ebx
mov DWORD PTR [r14], 0
mov DWORD PTR 0[r13], 0
mov DWORD PTR [r12], 0
mov DWORD PTR 0[rbp], 0
cvtsi2ssq xmm4, rax
mulss xmm4, xmm8
cvtss2sd xmm4, xmm4
divsd xmm4, xmm7
addsd xmm4, xmm10
cvtsd2ss xmm4, xmm4
je .L5
movaps xmm3, xmm6
movaps xmm2, xmm6
mov ecx, ebx
movss xmm5, DWORD PTR .LC2[rip]
.p2align 4,,10
.L6:
movaps xmm1, xmm2
xor edx, edx
movaps xmm0, xmm3
mulss xmm1, xmm2
movaps xmm15, xmm2
mulss xmm0, xmm3
mulss xmm15, xmm3
movaps xmm2, xmm1
subss xmm2, xmm0
movaps xmm3, xmm15
addss xmm0, xmm1
addss xmm3, xmm14
addss xmm2, xmm4
ucomiss xmm5, xmm0
setnb dl
xor eax, eax
neg edx
sub ecx, 1
setne al
neg eax
test edx, eax
jne .L6
.L7:
mov eax, ebx
lea r15d, [rdi+rsi]
sub eax, ecx
cmp ebx, eax
jnb .L8
mov rax, QWORD PTR ABITS$[rip]
mov DWORD PTR [rax+r15*4], -16777216
.L9:
.L13:
.L14:
add esi, 1
cmp DWORD PTR 80[rsp], esi
jnb .L4
.L15:
mov rax, QWORD PTR 88[rsp]
mov r15d, ebx
cqo
idiv QWORD PTR 120[rsp]
test rdx, rdx
je .L25
.L16:
.L17:
add DWORD PTR 84[rsp], 1
mov eax, DWORD PTR 84[rsp]
cmp DWORD PTR 112[rsp], eax
jnb .L3
.L18:
mov rax, QWORD PTR HGFXDC$[rip]
mov r9d, DWORD PTR 100[rsp]
xor r8d, r8d
mov rcx, QWORD PTR HDC$[rip]
mov DWORD PTR 64[rsp], 13369376
xor edx, edx
mov DWORD PTR 56[rsp], 0
mov DWORD PTR 48[rsp], 0
mov QWORD PTR 40[rsp], rax
mov eax, DWORD PTR 96[rsp]
mov DWORD PTR 32[rsp], eax
call BitBlt
movaps xmm6, XMMWORD PTR 160[rsp]
movaps xmm7, XMMWORD PTR 176[rsp]
movaps xmm8, XMMWORD PTR 192[rsp]
movaps xmm9, XMMWORD PTR 208[rsp]
movaps xmm10, XMMWORD PTR 224[rsp]
movaps xmm11, XMMWORD PTR 240[rsp]
movaps xmm12, XMMWORD PTR 256[rsp]
movaps xmm13, XMMWORD PTR 272[rsp]
movaps xmm14, XMMWORD PTR 288[rsp]
movaps xmm15, XMMWORD PTR 304[rsp]
add rsp, 328
pop rbx
pop rsi
pop rdi
pop rbp
pop r12
pop r13
pop r14
pop r15
ret
.p2align 4,,10
.L8:
pxor xmm0, xmm0
cvtsi2sdq xmm0, rax
.L10:
call log
movapd xmm15, xmm0
mov eax, ebx
pxor xmm0, xmm0
mulsd xmm15, xmm11
cvtsi2sdq xmm0, rax
subsd xmm0, xmm9
call log
divsd xmm15, xmm0
ucomisd xmm15, xmm9
movapd xmm0, xmm15
movsd QWORD PTR 152[rsp], xmm15
jb .L26
.L11:
ucomisd xmm15, xmm12
jnb .L12
movsd xmm1, QWORD PTR .LC5[rip]
mulsd xmm0, xmm1
subsd xmm0, xmm1
call floor
cvttsd2si rax, xmm0
mov rdx, QWORD PTR ABITS$[rip]
sal eax, 8
sub eax, 65536
mov DWORD PTR [rdx+r15*4], eax
jmp .L14
.p2align 4,,10
.L12:
mulsd xmm0, xmm13
subsd xmm0, QWORD PTR .LC7[rip]
call floor
addsd xmm0, QWORD PTR .LC8[rip]
mov rdx, QWORD PTR ABITS$[rip]
cvttsd2si rax, xmm0
mov DWORD PTR [rdx+r15*4], eax
jmp .L14
.p2align 4,,10
.L26:
mulsd xmm0, QWORD PTR .LC5[rip]
call floor
cvttsd2si rax, xmm0
mov rdx, QWORD PTR ABITS$[rip]
sal eax, 16
sub eax, 16777216
mov DWORD PTR [rdx+r15*4], eax
jmp .L14
.L5:
lea r15d, [rdi+rsi]
pxor xmm0, xmm0
jmp .L10
.L25:
mov rax, QWORD PTR HGFXDC$[rip]
mov r9d, DWORD PTR 100[rsp]
xor r8d, r8d
mov rcx, QWORD PTR HDC$[rip]
mov DWORD PTR 64[rsp], 13369376
mov DWORD PTR 56[rsp], 0
mov DWORD PTR 48[rsp], 0
mov QWORD PTR 40[rsp], rax
mov eax, DWORD PTR 96[rsp]
mov DWORD PTR 32[rsp], eax
call BitBlt
mov eax, DWORD PTR IH$[rip]
mov DWORD PTR 96[rsp], eax
mov eax, DWORD PTR IW$[rip]
mov DWORD PTR 100[rsp], eax
jmp .L17
.section .text.unlikely,"x"
.LCOLDE9:
.text
.LHOTE9:
.section .text.unlikely,"x"
.LCOLDB10:
.text
.LHOTB10:
.p2align 4,,15
.globl MANDELITER
.def MANDELITER; .scl 2; .type 32; .endef
MANDELITER:
test r8d, r8d
je .L30
pxor xmm4, xmm4
sub rsp, 40
mov r9d, r8d
movaps XMMWORD PTR [rsp], xmm6
movaps xmm2, xmm4
movaps XMMWORD PTR 16[rsp], xmm7
movss xmm7, DWORD PTR .LC2[rip]
.p2align 4,,10
.L29:
movaps xmm5, xmm2
movaps xmm3, xmm4
movaps xmm6, xmm2
xor ecx, ecx
mulss xmm5, xmm2
mulss xmm3, xmm4
mulss xmm6, xmm4
movaps xmm2, xmm5
subss xmm2, xmm3
movaps xmm4, xmm6
addss xmm3, xmm5
addss xmm4, xmm1
addss xmm2, xmm0
ucomiss xmm7, xmm3
setnb cl
xor edx, edx
neg ecx
sub r9d, 1
setne dl
neg edx
test ecx, edx
jne .L29
.L28:
mov eax, r8d
movaps xmm6, XMMWORD PTR [rsp]
sub eax, r9d
movaps xmm7, XMMWORD PTR 16[rsp]
add rsp, 40
ret
.L30:
xor eax, eax
ret
.section .text.unlikely,"x"
.LCOLDE10:
.text
.LHOTE10:
.def __main; .scl 2; .type 32; .endef
.section .rdata,"dr"
.LC11:
.ascii "\0"
.LC12:
.ascii "GDI\0"
.LC13:
.ascii "GDI Mandelbrot\0"
.LC17:
.ascii " / Took \0"
.LC18:
.ascii " seconds to render.\0"
.section .text.unlikely,"x"
.LCOLDB19:
.section .text.startup,"x"
.LHOTB19:
.p2align 4,,15
.globl main
.def main; .scl 2; .type 32; .endef
main:
push rbp
push rdi
push rsi
push rbx
mov rsi, rdx
mov ebx, ecx
sub rsp, 456
movaps XMMWORD PTR 432[rsp], xmm6
call __main
xor r8d, r8d
mov rdx, rsi
mov ecx, ebx
call fb_Init
lea rcx, .LC11[rip]
xor edx, edx
mov QWORD PTR 120[rsp], 0
mov QWORD PTR 128[rsp], 0
lea rsi, 272[rsp]
call fb_StrAllocTempDescZEx
mov QWORD PTR 48[rsp], rax
lea rax, 88[rsp]
lea r9, 72[rsp]
lea r8, 64[rsp]
lea rdx, 128[rsp]
lea rcx, 120[rsp]
mov QWORD PTR 40[rsp], rax
lea rax, 80[rsp]
mov QWORD PTR 88[rsp], 0
mov QWORD PTR 80[rsp], 0
mov QWORD PTR 72[rsp], 0
mov QWORD PTR 32[rsp], rax
mov QWORD PTR 64[rsp], 0
call fb_GfxScreenInfo
lea rcx, .LC12[rip]
mov edx, 3
mov DWORD PTR IW$[rip], 1000
mov DWORD PTR IH$[rip], 600
call fb_StrAllocTempDescZEx
mov ecx, 103
mov rdx, rax
call fb_GfxControl_s
mov edx, DWORD PTR IH$[rip]
mov ecx, DWORD PTR IW$[rip]
mov r9d, 1
mov r8d, 24
mov DWORD PTR 40[rsp], 0
mov DWORD PTR 32[rsp], 0
call fb_GfxScreenRes
lea r8, .LC13[rip]
mov r9d, 15
mov rdx, -1
mov rcx, rsi
mov DWORD PTR 32[rsp], 0
call fb_StrInit
mov rcx, rsi
call fb_GfxSetWindowTitle
mov eax, 2147483648
lea rdx, 136[rsp]
lea r9, 104[rsp]
mov QWORD PTR 112[rsp], rax
mov QWORD PTR 104[rsp], rax
lea r8, 96[rsp]
mov QWORD PTR 96[rsp], rax
lea rax, 112[rsp]
mov ecx, 2
mov QWORD PTR 136[rsp], 0
mov QWORD PTR 32[rsp], rax
call fb_GfxControl_i
mov rcx, QWORD PTR 136[rsp]
call GetDC
lea rdx, 304[rsp]
mov r10, rax
mov QWORD PTR HDC$[rip], rax
mov ecx, 15
xor eax, eax
lea r9, ABITS$[rip]
mov rdi, rdx
xor r8d, r8d
rep stosq
mov eax, DWORD PTR IW$[rip]
mov ecx, 32
mov DWORD PTR 304[rsp], 124
mov WORD PTR 318[rsp], cx
mov rcx, r10
mov DWORD PTR 320[rsp], 3
mov DWORD PTR 356[rsp], -16777216
mov DWORD PTR 344[rsp], 16711680
mov DWORD PTR 308[rsp], eax
mov eax, DWORD PTR IH$[rip]
mov DWORD PTR 348[rsp], 65280
mov DWORD PTR 352[rsp], 255
mov DWORD PTR [rdi], 0
mov DWORD PTR 40[rsp], 0
neg eax
mov QWORD PTR 32[rsp], 0
mov DWORD PTR 312[rsp], eax
mov eax, 1
mov WORD PTR 316[rsp], ax
call CreateDIBSection
mov rcx, QWORD PTR HDC$[rip]
mov rdi, rax
call CreateCompatibleDC
mov rdx, rdi
mov rcx, rax
mov QWORD PTR HGFXDC$[rip], rax
call SelectObject
mov QWORD PTR 144[rsp], 0
mov rbp, rax
mov QWORD PTR 152[rsp], 0
mov DWORD PTR 160[rsp], 0
call fb_Timer
movss xmm3, DWORD PTR .LC14[rip]
mov DWORD PTR 40[rsp], 100
movaps xmm1, xmm3
mov DWORD PTR 32[rsp], 5000
movapd xmm6, xmm0
movss xmm2, DWORD PTR .LC15[rip]
movss xmm0, DWORD PTR .LC16[rip]
call MANDELBROT
call fb_Timer
subsd xmm0, xmm6
call fb_DoubleToStr
lea rcx, 176[rsp]
lea r9, .LC17[rip]
mov r8, -1
mov rdx, rsi
mov QWORD PTR 32[rsp], 9
mov rbx, rax
mov QWORD PTR 176[rsp], 0
mov QWORD PTR 184[rsp], 0
mov QWORD PTR 192[rsp], 0
call fb_StrConcat
lea rcx, 208[rsp]
mov r9, rbx
mov r8, -1
mov rdx, rax
mov QWORD PTR 32[rsp], -1
mov QWORD PTR 208[rsp], 0
mov QWORD PTR 216[rsp], 0
mov QWORD PTR 224[rsp], 0
lea rbx, 144[rsp]
call fb_StrConcat
lea rcx, 240[rsp]
lea r9, .LC18[rip]
mov r8, -1
mov rdx, rax
mov QWORD PTR 32[rsp], 20
mov QWORD PTR 240[rsp], 0
mov QWORD PTR 248[rsp], 0
mov QWORD PTR 256[rsp], 0
call fb_StrConcat
mov rcx, rax
call fb_GfxSetWindowTitle
jmp .L35
.p2align 4,,10
.L50:
cmp eax, 1
je .L38
.L36:
.L39:
.L40:
.L41:
mov ecx, 30
call fb_Sleep
.L35:
mov rcx, rbx
call fb_GfxEvent
test eax, eax
je .L41
mov eax, DWORD PTR 144[rsp]
cmp eax, 13
jne .L50
.L38:
mov rcx, QWORD PTR HGFXDC$[rip]
mov rdx, rbp
call SelectObject
mov rdx, QWORD PTR HDC$[rip]
mov rcx, QWORD PTR 136[rsp]
call ReleaseDC
mov rcx, QWORD PTR HGFXDC$[rip]
call DeleteDC
mov rcx, rdi
call DeleteObject
mov rcx, rsi
call fb_StrDelete
xor ecx, ecx
call fb_End
movaps xmm6, XMMWORD PTR 432[rsp]
add rsp, 456
pop rbx
xor eax, eax
pop rsi
pop rdi
pop rbp
ret
.section .text.unlikely,"x"
.LCOLDE19:
.section .text.startup,"x"
.LHOTE19:
.lcomm HGFXDC$,8,8
.lcomm ABITS$,8,8
.lcomm HDC$,8,8
.lcomm IH$,4,4
.lcomm IW$,4,4
.section .rdata,"dr"
.align 4
.LC2:
.long 1082130432
.align 8
.LC3:
.long 0
.long 1072693248
.align 8
.LC4:
.long 0
.long 1074266112
.align 8
.LC5:
.long 0
.long 1081073664
.align 8
.LC6:
.long 0
.long 1073741824
.align 8
.LC7:
.long 0
.long 1082122240
.align 8
.LC8:
.long -536870912
.long 1106247679
.align 4
.LC14:
.long 1065353216
.align 4
.LC15:
.long -1082130432
.align 4
.LC16:
.long -1073741824
.ident "GCC: (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project) 5.2.0"
.def BitBlt; .scl 2; .type 32; .endef
.def log; .scl 2; .type 32; .endef
.def floor; .scl 2; .type 32; .endef
.def fb_Init; .scl 2; .type 32; .endef
.def fb_StrAllocTempDescZEx; .scl 2; .type 32; .endef
.def fb_GfxScreenInfo; .scl 2; .type 32; .endef
.def fb_GfxControl_s; .scl 2; .type 32; .endef
.def fb_GfxScreenRes; .scl 2; .type 32; .endef
.def fb_StrInit; .scl 2; .type 32; .endef
.def fb_GfxSetWindowTitle; .scl 2; .type 32; .endef
.def fb_GfxControl_i; .scl 2; .type 32; .endef
.def GetDC; .scl 2; .type 32; .endef
.def CreateDIBSection; .scl 2; .type 32; .endef
.def CreateCompatibleDC; .scl 2; .type 32; .endef
.def SelectObject; .scl 2; .type 32; .endef
.def fb_Timer; .scl 2; .type 32; .endef
.def fb_DoubleToStr; .scl 2; .type 32; .endef
.def fb_StrConcat; .scl 2; .type 32; .endef
.def fb_Sleep; .scl 2; .type 32; .endef
.def fb_GfxEvent; .scl 2; .type 32; .endef
.def ReleaseDC; .scl 2; .type 32; .endef
.def DeleteDC; .scl 2; .type 32; .endef
.def DeleteObject; .scl 2; .type 32; .endef
.def fb_StrDelete; .scl 2; .type 32; .endef
.def fb_End; .scl 2; .type 32; .endef
Alles anzeigen
Kompiliert mit folgenden Parametern: fbc -s gui -RR -fpu SSE -vec 2 "Mandelbrot.bas"
Wenn ich den Code als 64-bit kompiliere, dann wird die Mandelbrot Grafik rund dargestellt!
Auch im Hinblick auf auf weitere "Battles" hätte ich gerne Anwendungen gesehen, welche von den bei FB und AutoIt gleich schnell ausgeführten API-Funktionen (ist das so?) abhängig sind.
Du meinst also, dass ich z.B. eine GDI+ Code in FB umwandeln soll. Kann ich machen, aber mit großer Wahrscheinlichkeit wird der Unterschied nicht mehr so immens sein, da die GDI+ Calls ausbremsen.
In FB sollten imho auch Arrayfunktionen (Arraysort bspw) wesentlich schneller arbeiten.
Ich habe für die _GDIPlus_BitmapApplyFilter DLL ein ArraySort benötigt, aber habe keine native FB Funktion gefunden. Entweder bin ich blind oder zu blöd zum Suchen.
Zum Sortieren von Arrays habe ich eine WinAPI Funktion verwendet: QSort.
Das wurde auch in AutoIt bereits umgesetzt.
_ArraySortClib:
; http://www.autoitscript.com/forum/index.php?showtopic=63525&view=findpost&p=474072
;===============================================================================
; Function Name: _ArraySortClib() v4
; Description: Sort 1D/2D array using qsort() from C runtime library
; Syntax:
; Parameter(s): $Array - the array to be sorted, ByRef
; $iMode - sort mode, can be one of the following:
; 0 = numerical, using double precision float compare
; 1 = string sort, case insensitive (default)
; 2 = string sort, case sensitive
; 3 = word sort, case insensitive - compatible with AutoIt's native compare
; $fDescend - sort direction. True = descending, False = ascending (default)
; $iStart - index of starting element (default 0 = $array[0])
; $iEnd - index of ending element (default 0 = Ubound($array)-1)
; $iColumn - index of column to sort by (default 0 = first column)
; $iStrMax - max string length of each array element to compare (default 4095 chars)
; Requirement(s): msvcrt.dll (shipped with Windows since Win98 at least), 32-bit version of AutoIt
; Return Value(s): Success = Returns 1
; Failure = Returns 0 and sets error:
; @error 1 = invalid array
; @error 2 = invalid param
; @error 3 = dll error
; @error 64 = 64-bit AutoIt unsupported
; Author(s): Siao
; Modification(s): KaFu, added three global _MemVirtualAlloc() calls to top of script to prevent DEP Errors:
;
; Global $pEnumProc_ArraySortClib_Mem1 = _MemVirtualAlloc(0, 64, $MEM_COMMIT, $PAGE_EXECUTE_READWRITE) ; needed for _ArraySortClib()
; Global $pEnumProc_ArraySortClib_Mem2 = _MemVirtualAlloc(0, 64, $MEM_COMMIT, $PAGE_EXECUTE_READWRITE) ; needed for _ArraySortClib()
; Global $pEnumProc_ArraySortClib_Mem3 = _MemVirtualAlloc(0, 36, $MEM_COMMIT, $PAGE_EXECUTE_READWRITE) ; needed for _ArraySortClib()
;
;===============================================================================
Func _ArraySortClib(ByRef $array, $iMode = 1, $fDescend = False, $iStart = 0, $iEnd = 0, $iColumn = 0, $iStrMax = 4095)
If @AutoItX64 Then Return SetError(64, 0, 0)
Local $iArrayDims = UBound($array, 0)
If @error Or $iArrayDims > 2 Then Return SetError(1, 0, 0)
Local $iArraySize = UBound($array, 1), $iColumnMax = UBound($array, 2)
If $iArraySize < 2 Then Return SetError(1, 0, 0)
If $iEnd < 1 Or $iEnd > $iArraySize - 1 Then $iEnd = $iArraySize - 1
If ($iEnd - $iStart < 1) Then
; ConsoleWrite("- _ArraySortClib ERROR: #1 - " & ($iEnd - $iStart < 1) & @tab & ($iEnd - $iStart) & @crlf)
Return SetError(2, 0, 0)
EndIf
If $iArrayDims = 2 And ($iColumnMax - $iColumn < 0) Then
; ConsoleWrite("- _ArraySortClib ERROR: #2 - " & $iArrayDims & @tab & ($iColumnMax - $iColumn < 0) & @tab & ($iColumnMax - $iColumn) & @crlf)
Return SetError(2, 0, 0)
EndIf
If $iStrMax < 1 Then
; ConsoleWrite("- _ArraySortClib ERROR: #3 - " & $iStrMax & @crlf)
Return SetError(2, 0, 0)
EndIf
Local $i, $j, $iCount = $iEnd - $iStart + 1, $fNumeric, $aRet, $sZero = ChrW(0), $sStrCmp, $sBufType = 'byte[', $tSource, $tIndex, $tFloatCmp
Local $tEnumProc = DllStructCreate('byte[64]', $pEnumProc_ArraySortClib_Mem1)
Local $tCmpWrap = DllStructCreate('byte[64]', $pEnumProc_ArraySortClib_Mem2)
If $h_DLL_msvcrt = -1 Then Return SetError(3, 0, 0)
;; initialize compare proc
Switch $iMode
Case 0
$fNumeric = True
$tFloatCmp = DllStructCreate('byte[36]', $pEnumProc_ArraySortClib_Mem3)
DllStructSetData($tFloatCmp, 1, '0x8B4C24048B542408DD01DC1ADFE0F6C440750D80E441740433C048C333C040C333C0C3')
DllStructSetData($tCmpWrap, 1, '0xBA' & Hex(Binary(DllStructGetPtr($tFloatCmp)), 8) & '8B4424088B4C2404FF30FF31FFD283C408C3')
DllStructSetData($tEnumProc, 1, '0x8B7424048B7C24088B4C240C8B442410893789470483C60883C708404975F1C21000')
Case 1, 2
$sStrCmp = "_strcmpi" ;case insensitive
If $iMode = 2 Then $sStrCmp = "strcmp" ;case sensitive
$aRet = DllCall($h_DLL_Kernel32, 'ptr', 'GetModuleHandle', 'str', 'msvcrt.dll')
$aRet = DllCall($h_DLL_Kernel32, 'ptr', 'GetProcAddress', 'ptr', $aRet[0], 'str', $sStrCmp)
;If $aRet[0] = 0 Then Return SetError(3, 0, 0 * DllClose($h_DLL_msvcrt))
If $aRet[0] = 0 Then Return SetError(3, 0, 1)
DllStructSetData($tCmpWrap, 1, '0xBA' & Hex(Binary($aRet[0]), 8) & '8B4424088B4C2404FF30FF31FFD283C408C3')
DllStructSetData($tEnumProc, 1, '0x8B7424048B7C24088B4C240C8B542410893789570483C7088A064684C075F9424975EDC21000')
Case 3
$sBufType = 'wchar['
$aRet = DllCall($h_DLL_Kernel32, 'ptr', 'GetModuleHandle', 'str', 'kernel32.dll')
$aRet = DllCall($h_DLL_Kernel32, 'ptr', 'GetProcAddress', 'ptr', $aRet[0], 'str', 'CompareStringW')
;If $aRet[0] = 0 Then Return SetError(3, 0, 0 * DllClose($h_DLL_msvcrt))
If $aRet[0] = 0 Then Return SetError(3, 0, 1)
DllStructSetData($tCmpWrap, 1, '0xBA' & Hex(Binary($aRet[0]), 8) & '8B4424088B4C24046AFFFF306AFFFF3168000000006800040000FFD283E802C3')
DllStructSetData($tEnumProc, 1, '0x8B7424048B7C24088B4C240C8B542410893789570483C7080FB70683C60285C075F6424975EAC21000')
Case Else
Return SetError(2, 0, 0)
EndSwitch
;; write data to memory
If $fNumeric Then
$tSource = DllStructCreate('double[' & $iCount & ']')
If $iArrayDims = 1 Then
For $i = 1 To $iCount
DllStructSetData($tSource, 1, $array[$iStart + $i - 1], $i)
Next
Else
For $i = 1 To $iCount
DllStructSetData($tSource, 1, $array[$iStart + $i - 1][$iColumn], $i)
Next
EndIf
Else
Local $sMem = ""
If $iArrayDims = 1 Then
For $i = $iStart To $iEnd
$sMem &= StringLeft($array[$i], $iStrMax) & $sZero
Next
Else
For $i = $iStart To $iEnd
$sMem &= StringLeft($array[$i][$iColumn], $iStrMax) & $sZero
Next
EndIf
$tSource = DllStructCreate($sBufType & StringLen($sMem) + 1 & ']')
DllStructSetData($tSource, 1, $sMem)
$sMem = ""
EndIf
;; index data
$tIndex = DllStructCreate('int[' & $iCount * 2 & ']')
DllCall($h_DLL_user32, 'uint', 'CallWindowProc', 'ptr', DllStructGetPtr($tEnumProc), 'ptr', DllStructGetPtr($tSource), 'ptr', DllStructGetPtr($tIndex), 'int', $iCount, 'int', $iStart)
;; sort
DllCall($h_DLL_msvcrt, 'none:cdecl', 'qsort', 'ptr', DllStructGetPtr($tIndex), 'int', $iCount, 'int', 8, 'ptr', DllStructGetPtr($tCmpWrap))
;DllClose($h_DLL_msvcrt)
;; rearrange the array by sorted index
Local $aTmp = $array, $iRef
If $iArrayDims = 1 Then ; 1D
If $fDescend Then
For $i = 0 To $iCount - 1
$iRef = DllStructGetData($tIndex, 1, $i * 2 + 2)
$array[$iEnd - $i] = $aTmp[$iRef]
Next
Else ; ascending
For $i = $iStart To $iEnd
$iRef = DllStructGetData($tIndex, 1, ($i - $iStart) * 2 + 2)
$array[$i] = $aTmp[$iRef]
Next
EndIf
Else ; 2D
If $fDescend Then
For $i = 0 To $iCount - 1
$iRef = DllStructGetData($tIndex, 1, $i * 2 + 2)
For $j = 0 To $iColumnMax - 1
$array[$iEnd - $i][$j] = $aTmp[$iRef][$j]
Next
Next
Else ; ascending
For $i = $iStart To $iEnd
$iRef = DllStructGetData($tIndex, 1, ($i - $iStart) * 2 + 2)
For $j = 0 To $iColumnMax - 1
$array[$i][$j] = $aTmp[$iRef][$j]
Next
Next
EndIf
EndIf
Return 1
EndFunc ;==>_ArraySortClib
Alles anzeigen
Auch im Hinblick auf auf weitere "Battles" hätte ich gerne Anwendungen gesehen, welche von den bei FB und AutoIt gleich schnell ausgeführten API-Funktionen (ist das so?) abhängig sind.
Ich habe mal einen weiteren Test hinzugefügt, wo primär GDI+ Funktionen aufgerufen werden und siehe da, AutoIt schlägt sich tapfer Dank der "lahmen" GDI+ Funktionen.
FB kann erst nativ die volle Hengst Power entfalten, wenn die API Calls entfallen.
Function mandelIter:
Wie schon in anderen "Sichtungen" festgestellt, ist das FB-compilat wirklich "schön". Nicht gelungen, aber "schön"
SSE wird zwar nur mit "einem" 32-Bitregister (statt der verfügbaren 4) benutzt, allerdings sind die SSE-Befehle generell schneller. Handoptimiert schätze ich mal die mögliche Beschleunigung locker auf Faktor 2-3, weil ich statt, wie der Compiler, die Parameter auch in die SSE-Register schreiben würde statt, wie der Compiler, mir vom Stack einige Bytes an RAM zu genehmigen. Was btw. aber eine sehr "schicke" Lösung für einen Compiler ist, da habe ich schon weit üblere Varianten gesehen...
Hat man das erst einmal erkannt, lässt sich auch der Compilercode um Faktor 2-3 beschleunigen, statt des "Basic"-Codes für den inner Loop nutzt man den Inline Assembler!
Wenn man aber Inline Assembler nutzt, dann kann man ja gleich AssembleIt() nutzen und braucht kein Freebasic
Nichtsdestotrotz ist diese Lösung des FB-Compilers/Assemblers aber Faktor 100 langsamer als bspw. ein (auch per AutoIt ansprechbarer) OpenCL-Code, welcher auf einer Grafikkarte (alternativ CPU) läuft. Und OpenCL wiederum ist "simpler" C-Code, auf den hunderten Prozessoren einer 80€- Graka ausgeführt 100x schneller als auf einer schnarchlahmen 1000€-Oktacore-CPU!
Wenn ich jetzt wirklich bitterböse wäre, dann würde ich folgendes Fazit aus dem Battle "AutoIt vs. FreeBasic" ziehen.
Die Faktoren beziehen sich jedes Mal auf die vorherige Position:
AutoIt-Code lahm...Faktor 1
FB-Compiler schnell(er) Faktor 100
FB-Compiler handoptimiert Inline-ASM Faktor 3
AutoIt AssembleIt Faktor 1
AutoIt OpenCL Faktor 100-1000 je nach Grafikkarte (ja, 100 bis 1000 (tausend) mal schneller als der FB-(und übrigens auch jeder andere CPU-)Compiler! )
OpenCL-Version, Infos dazu hier
OpenCl_Apfel_Forumversion.zip
Mein Fazit:
Mir persönlich ist der Weg "durch die Brust ins Auge -> AutoIt Inline Assembler" der schwierigere Weg, da FB relativ einfach zu lernen ist und man damit schnelle Dinge "zaubern" kann.