Battle: Autoit vs. FreeBasic - Runde 1+2+3

  • 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"!!!

    :rofl: :rofl: :rofl: :rofl: :rofl:

    Es gibt sehr viele Leute, die glauben. Aber aus Aberglauben.
    - Blaise Pascal

  • 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.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • 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 8o
    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.

  • 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 ;)

    Es gibt sehr viele Leute, die glauben. Aber aus Aberglauben.
    - Blaise Pascal

  • 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" :theke:

  • 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? ;)

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • 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.... :whistling:


    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... :theke:
    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:


    Der gesamte Code:

    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:

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • 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.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Function mandelIter:

    Wie schon in anderen "Sichtungen" festgestellt, ist das FB-compilat wirklich "schön". Nicht gelungen, aber "schön" :D
    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 8o

    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:

    • willst du in der Hauptschleife GDI+ Funktionen benutzen, dann kann FB auch keine Wunder bewirken, da die GDI+ DLL Aufrufe langsam sind
    • benutzt du native Funktionen, wie z.B. das Setzen eines Pixels, so vollbringt FB einen richtigen Performance Schub
    • willst du noch weiter den Speed steigern, so benutze eigenen MMX/SSE optimierten Assembler Code
    • für AutoIt lagere die Performance Killer in eine externe DLL aus oder benutze gleich den Inline Assembler, dann sollte der Speed adequat zu FB sein
    • wenn trotz allem die Performance immer noch zu langsam ist, dann versuche es mal mit OpenCL

    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.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯