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

  • Da ich seit einigen Wochen FreeBasic (FB) lerne, wollte ich AutoIt mit FreeBasic in Bezug auf GDI / GDI+ Geschwindigkeit testen.
    Ich weiß, dass dies ein Vergleich David gegen Goliath ist, aber man sieht den krassen Unterschied.



    Runde1 -> GDI Particles Mouse Attraction:

    FB: 25.000 Partikel @ 1024x768
    Au3: 1.000 Partikel @ 800x600.




    AU3:


    FB:


    Der Code Aufbau sollte in beiden Sprachen relativ identisch sein (GDI). Die Exe starten und mit der Maus auf der GUI hin und her fahren.



    Ergebnis:
    Autoit @ 1000 Pixel: ~14 FPS
    FB @ 25000 Pixel: ~64 FPS (limitiert, da Sleep verwendet wird)


    Krass!





    Runde2 -> Mandelbrot:

    Au3:



    FB:



    AU3: ~107 Sekunden @100
    FB: ~0.30 Sekunden @100, 1,7s @1000, 7,8s @5000 und 14,6s @10000.


    Falls ihr Au3 mit $iDetails = 1000 ausprobieren wollt, dann macht euch vorher einen Kaffee, den ihr langsam und genüsslich trinken könnt oder falls ihr Raucher seid, dann raucht am besten eine dicke fette Zigarre :!:





    Runde3 -> GDI+ Performance Test:


    Au3:




    FB:



    Au3: ca. 16,9 Sekunden
    FB: ca. 14,5 Sekunden







    Im Anhang die Source Codes + kompilierte Exes.



    FB gefällt mir immer mehr...



    Weitere Bespiele:


    Battle GDI vs GDI+: Battle: Autoit vs. FreeBasic - Runde 1+2+3
    Animated Pythagoras Tree in GDI / GDI+ / OpenGL: Battle: Autoit vs. FreeBasic - Runde 1+2+3
    GDI Particle Repulsion Grid in GDI: Battle: Autoit vs. FreeBasic - Runde 1+2+3


    ^^

  • FB scheint in GDI ausgereifter zu sin. Aber was macht den Unterschied aus? Durch was ist das bedingt? Auf jeden Fall ist das sehr faszinierend.


    Nachtrag: alpines hatte schneller eine mögliche Erklärung als ich die Frage fertig


    [Offtopic]
    ... mit FB "Particles Mouse Attraction" zu spielen macht mir echt Spass. Ein echter Pokemon Killer. :thumbsup:


    Jetzt noch Zimtsternfressende Monster in das Spiel einbauen und Punkte sammeln lassen. Ein neuer Name wie "Startransformer" und Du kannst berühmt werden.[/Offtopic]

  • Ich vermute mal gaanz vage und vorsichtig das es daran liegen könnte das AutoIt3 interpretiert und nicht compiliert wird.

    Nichtsdestotrotz ist das Verhältnis "Anzahl der Partikel" 25:1 und trotzdem liegt AutoIt weit hinten!


    Selbst bei 100.000 Pixel sinkt die FPS nur auf 48 FPS! 8o

  • Das hat man davon das die AutoIt-Entwickler neue Features hinzufügen und keinen effizienten Code produzieren.

    AutoIt ist auch für solche "Spielereien" nicht gemacht worden. ;)


    Leider ist die Au3 Entwicklung eingeschlafen bzw. innovative Ideen wurden abgelehnt. Mal sehen, was da noch kommen wird...

  • David gegen Goliath

    Das trifft es ganz gut, Interpreter gegen Compiler wird niemals nie schneller sein.
    Sehr schönes Beispiel!



    Das hat man davon das die AutoIt-Entwickler neue Features hinzufügen und keinen effizienten Code produzieren. 25:1 ist schon ziemlich krass.

    Ich denke das liegt weniger am mangelnden Interpreter, als an der Tatsache dass du 0 Optimierung durch AutoIt betreiben kannst, die nicht in "pre-compiled" Code enden würde.

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

  • Ich denke das liegt weniger am mangelnden Interpreter, als an der Tatsache dass du 0 Optimierung durch AutoIt betreiben kannst, die nicht in "pre-compiled" Code enden würde.

    Dafür ist es schließlich auch nicht ausgelegt, aber ich bin mir sicher das dennoch ein signifikanter Geschwindigkeitsschub erreicht werden kann wenn man mal den Interpreter ordentlich überarbeiten würde.
    Der ist in den letzten Versionen nur größer und größer geworden aber leistungstechnisch hat sich nichts verändert.

  • Hi,
    ich finde, AutoIt sieht im Vergleich garnicht mal so schlecht aus...nur 25 mal langsamer als eine Compilersprache ist imho sogar nur deshalb zu erreichen, weil fast ausschließlich "billige" Berechnungen durchgeführt werden, bzw. weil die Ausführungsgeschwindigkeit der "teuren" Funktionen (in diesem Fall das Blitten) als API-Aufruf(e) sowohl beim Compiler als auch bei AutoIt die gleiche Laufzeit benötigen.
    Der viel realistischere Faktor 1000 in der Laufzeit ist schon oft von entsprechenden C(++)-Dll´s oder auch ASM-Code gezeigt worden.


    Viel wichtiger, und das auch im Hinblick auf "Optimierungen" (übrigens sowohl des Compiler- als auch des AutoItcodes!!!) wäre mal ein Vergleich der lokalen Laufzeiten, also profiling. Die Erfahrung zeigt, dass sich durch diese Analysen und die Umsetzung von Verbesserungen im Code wesentliche Beschleunigungen erreichen lassen.


    Es wäre anzunehmen, dass in AutoIt die Funktion MoveParticles() die hauptsächliche Leistung benötigt, dem ist aber garnicht so! Diese Funktion ausgeklammert liefert AutoIt die gleichen FPS!
    Der For $i = 1 To $iParticles - Loop ist die Ursache des AutoIt-Elends. Jede in diesem Loop ausgeführte "Funktion", und sei es nur ein simples "INT()" lässt die Leistung zusammenbrechen!


    Code
    1. For $i = 1 To $iParticles
    2. MoveParticles(MouseGetPos(0), MouseGetPos(1), $i)
    3. $iX = Int($tParticles.x(($i)))
    4. $iY = Int($tParticles.y(($i))) * $iW
    5. ;$tBitmap.px(($iY + $iX)) = $tParticles.color(($i)) ;write directly to the bitmap (one pixel)
    6. Next

    das unsäglich langsame DllstructSetData(), hier als $tBitmap.px(($iY + $iX)), nervt mich schon seit Jahren und war auch der Grund für die Verwendung kleiner ASM-Programme

  • Mal eine ernstgemeinte Frage, was für ein Sinn hat ein Vergleich zwischen Äpfeln (Compiler) und Birnen (Interpreter)?


    Wäre wie wenn ich sagen würde ein Auto ist schneller als ein Fahrrad. Verstehe denn Sinn dieser Sache nicht.

  • Mal eine ernstgemeinte Frage, was für ein Sinn hat ein Vergleich zwischen Äpfeln (Compiler) und Birnen (Interpreter)?

    Nun ja, beides ist Obst. ^^


    Natürlich ist der Vergleich nicht fair, sondern sehr unfair, aber ich wollte nur zeigen, was bei annähernd gleichem Code Aufbaus für ein extremer Unterschied sein kann. Das Ganze relativiert sich ein wenig, wenn viele DLL Calls stattfinden, wo die Ausführungszeit des Aufrufs eher das Problem ist, z.B. bei GDI+ Funktionen, dann ist der Unterschied nicht mehr so krass.


    Man könnte AutoIt pimpen, was Andy bereits erwähnte, gewisse Funktionen in ASM, am besten gleich als MMX/SSE, zu coden. Ich wette, dann würde der Unterschied sich wieder relativieren.


    Die Frage stellt sich dann, warum "durch die Brust ins Auge"?

  • @chip doch, du kannst dem Rennradhersteller ans Bein pissen, dass er seinem Rad nur Features hinzufügte, statt es so schnell wie ein Auto zu machen :rolleyes:
    @UEZ besitzt FreeBasic Threads? Wenn das Blitten bei beiden das langwierige ist, dann lass doch deine Partikel in einem Thread nebenher immer schon fürs neue Bild berechnen. Würde mich mal interessieren, wie hoch der erreichte Speedup dann wäre.

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

  • Xorianator : an Multi Threading hatte ich auch schon gedacht, aber das Memory Management ist nicht immer ganz trivial, deswegen die Threads im FB Forum.


    Mal sehen, ob's klappen wird...

  • Memory Management ist nicht immer ganz trivial

    Meinst du das von FB im Falle von MT, oder meinst du es ist nicht ganz trivial, das mit Threads umzusetzen?

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

  • Meinst du das von FB im Falle von MT, oder meinst du es ist nicht ganz trivial, das mit Threads umzusetzen?

    Ich denke, dass MT generell nicht ganz einfach ist, da der Speicher, muss R/W fähig sein, zwischen den Threads geshared sein muss. Ich weiß, dass Eukalyptus ein sehr gutes MT Beispiel in FB gepostet hatte, das ein Bild in Graustufen umwandelt. Mein Partikel Beispiel ist im Prinzip sehr ähnlich, da die ARGB Werte direkt in die Bitmap geschrieben werden, ohne den Gebrauch von API Funktionen.


    Das MT Beispiel im FB Forum ist ein super Beispiel, wie MT nicht gecodet werden sollte. :D

  • was bei annähernd gleichem Code Aufbaus für ein extremer Unterschied sein kann

    @chip, ich sag`s mal für die "nichtverstehenWOLLER" deutlich: Ein AutoIt-Compiler ist längstens überfällig. Allerdings wurden/werden sämtliche Ansätze dorthin rigoros abgeblockt. So weit, das einige DEV´s lieber das Handtuch werfen, statt weiter "herumzufrickeln". Eins steht fest wie das Amen in der Kirche, der "Compiler-Fork" wäre sofort nach Bekanntgabe massiv unterstützt und gehyped worden. So massiv, dass die "classic"-DEV´s nur noch hinterherschauen...und sich letztendlich von der Community in eine Richtung drücken ließen, die seitens Heeresleitung SO ganz und gar nicht gewünscht ist!



    was für ein Sinn hat ein Vergleich zwischen Äpfeln (Compiler) und Birnen (Interpreter)

    Es stellt sich die Frage, wieso jemand, der fit in AutoIt ist, lieber/besser andere Programmiersprachen nutzt bzw. nutzen MUSS!?
    Und wie ich schon sagte, UEZ´s Beispiel ist geschönt, weil AutoIt viel zu gut dabei wegkommt.


    Wir haben hier im Forum einige TOP-Leute an andere Programmiersprachen genau aus diesem Grund verloren. Und definitiv nicht, weil man heutzutage ohne plusplus-Gedöns keine guten Programme schreiben kann.




    an Multi Threading hatte ich auch schon gedacht, aber das Memory Management ist nicht immer ganz trivial

    Die Komplexität des Memory-Management und explizit der Zugriff auf "shared" Memory hängt mehr vom Können des Programmierers als von den Möglichkeiten der Programmiersprache ab! Multi-Threading ist supersimpel, solange threadsafe Funktionen benutzt werden. Ansonsten wird es zäh...
    Wobei man sich fragen muss, wieso Programme, welche für Multi(=viele, d.h. mehr als die Anzahl von CPU-Kernen)-Threading geeignet sind, nicht direkt per CUDA/OpenCL geschrieben werden. Da übernimmt der Compiler komplett sämtliches Thread-Management und auch das Memory-gefrickel. Und wählt selbst das geeignete Device, entweder CPU oder GPU...


    Was natürlich die Frage aufwirft, wieso nicht per AutoIt und OpenCL zu arbeiten, statt mit CompilerBasic und einem lächerlichen Thread 8o


    Btw. wird die maximale Anzahl FPS sowieso durch den Sleep() begrenzt.

  • Es stellt sich die Frage, wieso jemand, der fit in AutoIt ist, lieber/besser andere Programmiersprachen nutzt bzw. nutzen MUSS!?

    Weil AutoIt für so etwas nun mal nicht erfunden wurde. Es ist (und bleibt ?) eine Interpretersprache, welche Automatisierungszwecken dienlich war, nicht "technischen Spielereien".
    Problem der Devs sehe ich hier: Die Nachfrage, die an AutoIt gestellt wird, ist eine ganz Andere als das Angebot, welches AutoIt ursprünglich hatte. Und wenn der Markt dein Produkt nicht mehr bzw. anders braucht, dann hast du 2 Möglichkeiten: 1. Du stellst es ein, oder 2. Du veränderst dein Produkt, damit du nicht dicht machst.

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

  • Weil AutoIt für so etwas nun mal nicht erfunden wurde.

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



    dann hast du 2 Möglichkeiten: 1. Du stellst es ein, oder 2. Du veränderst dein Produkt, damit du nicht dicht machst.

    Und wer bitteschön hindert die AutoIt-Entscheider daran, einen Compiler zu releasen der in der Schublade liegt? Ich sags dir, "der kurze Bippes"!!! Denn sämtliche Innovationen der letzten Jahre kommen aus der Ecke der progressiven Entwickler, und das ist für die alteingesessenen schon übel genug...deshalb werden diese progressiven Entwickler auch reihenweise abgesägt. Wer aufmuckt, fliegt raus, so läuft der Hase.
    Ein Compiler würde das komplette Weltbild (seitens DEV´s) auf den Kopf stellen, das ist definitiv Fakt! Und dafür soll die Community dann auch noch Beifall spenden?!
    Als ob die Community nicht selbst wüßte woher die Innovationen kommen/kamen...


    Und eins noch, so wie ich meine Pappenheimer kenne, releasen die ganz ohne viel tamtam irgendwann doch den Compiler....und DANN müssen sich die DEV´s fragen lassen, wieso das Ding nicht aus deren Schublade kam. Auf DIE Antwort wirst du so lange warten können wie auf einige der "unbequemen" Antworten in diversen Tickets.