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

  • da FB relativ einfach zu lernen ist und man damit schnelle Dinge "zaubern" kann.

    "schnelle Dinge zaubern" :D
    Ok,da gehe ich mit! Einfach zu lernen, für das meiste schnell genug....SO sollte AutoIt sein, oder ist es das nicht sogar? :theke:
    Gut zu parallelisierende Algorithmen sind zwar immer noch 100x schneller per OpenCL/CUDA, aber wenn man SOOO schnell gar nicht braucht ist die damit erreichte Beschleunigung überflüssig.


    Battle 3. Teil kann kommen.... 8o:klatschen:

  • Battle 3. Teil kann kommen....

    Du meinst bestimmt Battle 4. Teil... :P


    Ich sehe gegenüber AutoIt eine Menge Vorteile, wenn es um "Brotlose Kunst" geht: schneller, Multithreading fähig, Inline Assembler bereits an Bord, auch relativ einfach zu lernen.


    Ich bin mir nicht sicher, aber OpenGL und DirectX sind ebenfalls an Board.


    Da frage ich mich ernsthaft, warum ich noch in AutoIt "Brotlose Kunst" coden soll!

  • Da frage ich mich ernsthaft, warum ich noch in AutoIt "Brotlose Kunst" coden soll!

    Ich zitiere mich mal selbst:


    Zitat von Andy

    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.

    Na gut, für dich als "Künstler der brotlosen Künste" liegt der Anteil bei vielleicht 50% "Eignung" für deine Vorhaben. Das sind immer noch NUR 50%. Also absolut kein Grund, weiter bei AutoIt zu bleiben. Jedenfalls in diesem Bereich....
    Was die Frage aufkommen lässt, wieso jemand, der sowieso die Vorteile einer anderen Programmiersprache ausnutzt, nicht gleich komplett wechseln soll?!
    Ich jedenfalls arbeite nur noch just for Fun mit AutoIt. Und dann, wenn ich "Fernsteuerungs- und Datentransfereigenschaften" nutzen muss. Und auch DAS ist selten genug...
    Das bissl GUI-Gedöns (alles rund um das Window-Info-Tool) ist schnell nach FB oder auch anderen Sprachen gewrappert, dann hätte AutoIt KEINEN Vorteil gegenüber anderen Basic-Dialekten mehr für mich.


    Hier im Forum hält mich nur noch die Nostalgie, da viele der fitten Leute bereits abgewandert sind. :huh: Wenn die ein- bis zwei Handvoll User, die ich sehr schätze, sich weiter so rar machen, werde ich mir auch (zwangsläufig) andere Betätigungsfelder suchen, bzw. mit diesen Usern mitwandern....

  • Ich doppelposte mal 8o


    @UEZ,
    hihi, der FB-Compiler ist kein Stück besser wie der AutoIt-Interpreter :rofl: . Zwar schneller, aber kein Stück besser....
    Anbei Script der "handoptimierten" Funktion MandelIter().
    Das komplette Programm ist dadurch knapp doppelt so schnell, allerdings wäre noch weit mehr drin, wenn , GENAU WIE IN AUTOIT, diese vermaledeite Doppel-For-To-Schleife nicht für jede einzelne Pixelberechnung einen ziemlich großen Overhead hätte!
    Ich schätze mal locker nochmal Faktor 2-3 schneller, wenn man die Doppelschleife per ASM "handcoden" würde. Auch die Codelänge würde sich ca. halbieren.
    Jedenfalls habe ich Respekt von den FB-Compilerbauern bekommen, die verwenden schnuckelige Tricks, die ich mir direkt für mein weiteres ASM-Gedöns abgeguckt habe :thumbsup: (btw. sind die Tricks gut, die Umsetzung in Code ist nur lausig...aber ich denke, das wird die einen sch**** interessieren :rolleyes: )


    Wenn man 64Bit verwendet, hat man Register in Hülle und Fülle, da muss man nicht haufenweise Variablen in den Speicher schreiben und daraus lesen.
    Kein Wunder, dass viele der hochoptimierten Mathe-Bibliotheken in ASM geschrieben werden....
    Bei gut parallelisierbarem Code stinkt auch die schnellste CPU und hochoptimierter Code nicht gegen eine unoptimierte OpenCl-Version an:
    Apfelmännchen in OpenCL 15ms auf meiner AMDA6-APU, und da ist das gesamte Speichergeschiebe schon mit drin, die Codelaufzeit auf der 7790-Graka beträgt 1.5ms!
    Apfelmännchen in FB 1500ms, Diskussion abgeschlossen. Selbst wenn der Code durch MT 4x schneller wird, und wegen mir noch mal 4x durch AVX rausgeholt wird, ist die Berechnung auf der CPU immer noch 100x langsamer...


  • Bei mir sind's ca. 50-55% schneller. :thumbsup:


    Hier der ASM Code von FB vs Andy:


    Das FB schneller ist als AutoIt bzw. GPU schneller als CPU muss nicht diskutiert werden.


    Wie gesagt, fehlt mir das Wissen MMX/SSE Code zu schreiben, aber die Idee hatte ich auch, schon bei dem Partikel beispiel.


    Und bist du mit FB zurecht gekommen? Der Editor (FbEdit) könnte ruhig ein paar Features mehr haben.

  • Und bist du mit FB zurecht gekommen? Der Editor (FbEdit) könnte ruhig ein paar Features mehr haben.

    Als erstes habe ich mir die Farben von AutoIt-Scite eingestellt :rock:
    Die IDE ist so, wie ich sie seit Turbo/Power-Basic-Zeiten (ca. 25 Jahre her) kenne. Und seitdem nicht ein Stück weiterentwickelt....
    Das in den Schlüsselwörtern fehlende ENDIF habe ich dort nachgetragen :Face: Fällt ja auch sonst niemandem auf, IF/ENDIF wird ja so gut wie nie benutzt... ||


    Sofort aufgefallen ist mir die fehlende Console, die ich fürs Debuggen eigentlich bräuchte. Den "Debugger" habe ich mir garnicht erst angeguckt, die Beschreibung für die Benutzung hat mir völlig gereicht :thumbdown: . Im Turbobasic war der in der IDE integriert und hatte einwandfrei funktioniert.
    Letztendlich habe ich mir mit PRINT und SLEEP ausgeholfen, das schreibt einfach ins nächste geöffnete Fenster, eine Messagebox per shortcut fehlt uswusf... typische Linux-"Programmierer-Umgebung eben", viel Getipper, dass man mit einem Mausklick abhandeln könnte, aber der Programmierer von heute bekommt ja für stundenlanges Getipper Geld und nicht für Vereinfachung/Verbesserung/Innovation!
    Der GCC/GAS-Compiler macht das was er soll, und wie gesagt, nicht mal schlecht. Meinen ASM-Code hat der Compiler ohne Overhead integriert, war zu erwarten.
    Für 08/15-Programme mag die Umsetzung ausreichen, wenn ich mir den erstellten Code ansehe, dann ist bei aufwendigen Berechnungen noch viel Luft für "Handoptimation".


    Insgesamt ein großer Unterschied zum VisualStudio, welches ich jetzt einfach mal als Referenz für ein "Rundumpaket" hernehme. Da ist der gesamte "moderne" Schnickschnack drin, den man braucht oder auch nicht, jedenfalls ist er vorhanden und benutzbar! Der Compiler dort funktioniert auch hervorragend, und man hat den Vorteil, auch für andere Programmiersprachen erstellte Bibliotheken/"UDF´s" einbinden zu können. Ob dieses "Monster" für Quick'n'dirty geeignet ist, muss jeder selbst entscheiden.
    Bei einem Basic-Dialekt möchte ich mich nicht mit OOP beschäftigen, andere sehen das anders.


    Ja, und da wird die Auswahl eines "Basic"-Compilers mit nutzbarer IDE und "Wohlfühlfaktor" bzgl. reichlich vorhandener und verwendbarer Funktionen schon ziemlich eng.
    AutoIt-Compiler?! 8)


    //EDIT
    http://www.blitzbasic.de scheint Prioritäten auf Grafik zu legen!
    http://www.powerbasic.de/html/preisliste.html imho "zu alt"
    Für Hardcore-Programmierer ist im MASM-Forum auch ein MASMBasic verfügbar, sehr schnell, wird ständig weiterentwickelt.

  • Ich finde die Umgebung, wie auch AutoIt, einfach perfekt - installieren und du kannst fast loslegen. VS ist ein Monster diesbezüglich, wo ich mehrmals verzweifelt bin nur die IDE zu bedienen.


    Blitzbasic scheint jetzt seit einiger Zeit Freeware zu sein, nur weiß ich nicht, ob BB die bessere Wahl wäre für die "brotlose Kunst".


    Momentan finde ich FB sehr angenehm zu arbeiten, wobei man im Vergleich zu AutoIt einige Klimmzüge mehr machen muss, um simple Dinge wie z.B. Arraysort oder ein simples GUICreate zu realisieren.


    Hier eine Liste der BASIC Derivate: http://basic.mindteq.com/index.php?i=popular

  • einige Klimmzüge mehr machen muss, um simple Dinge wie z.B. Arraysort oder ein simples GUICreate zu realisieren.

    GuiCreate()...für ein KODA vergleichbares Programm werden bei PB knapp hundert Euro aufgerufen... :S
    Generationen von Programmierern tippern sich die Finger mit API Aufrufen wund, aber mal nen Wrapper zu schreiben, DA fehlt es dann!
    C/C++ macht es vor, da schaue ich ab und zu mal ins CL-Forum, die haben kein Problem, hunderte von immer gleichen Zeilen BEI JEDEM ERSTELLTEN PROGRAMM einzukloppen, inclusive der darin zwangsläufig vorkommenden Fehler....Profis eben...mal nachgefragt, wieso die diese hunderte Zeilen nicht einfach mit 10 Zeilen wrappern hörst du ausschliesslich Gesabbel:"...warum wir das so machen? Weil wir es können!" Auf die Frage, wieso die "Könner" dann an einfachsten "Fehlern" scheitern und damit dann die Foren fluten folgte ein Ban :D ...Profis eben...


    Da gab es früher mal ein pysikalisches Gesetz...warte mal, gleich hab ich´s...ahjetztja...Leistung ist gleich Arbeit pro Zeit...PRO ZEIT!!! Jetzt weiß ich auch, wieso die alle mit 340 Anschlägen in der Minute schreiben müssen, da darf nur wahnsinnig wenig Zeit ins Schreiben investiert werden, damit die wenige Arbeit kompensiert werden kann :rofl:
    Wenn die ihr Geld mit produktivem Arbeiten statt mit Tippern verdienen müssten, würde die Welt sicher anders aussehen. Alles, was sich damit beschäftigt, das Programmieren an sich zu vereinfachen bzw. zu verbessern, scheint garnicht gewünscht zu sein.


    KODA ist auch nur deswegen bei den Autoit-Cracks so verpönt, weil GUI-Erstellung und Management sehr einfach "aus den Fingern laufen". Andere Sprachen würden sich danach alle Finger lecken.



    Btw. PureBasic macht einen runden Eindruck, und über die 79€ kann man nicht meckern. Und deren Forum hat einen guten und kompetenten Auftritt.
    //EDIT
    habe mir die Testversion runtergeladen und werde wohl bestellen, da ist alles dabei, was man sich wünschen kann, und noch mehr^^
    //EDIT2
    hehe, die haben sogar den FASM mit an Bord, besser kann es garnicht kommen, ich hab mir einige Demoprogramme angeschaut, das ist echt klasse, von sämtlichem GUI-Gedöns bis hin zu D2D,OpenGL, über Datenbanken, alles native und vor allem SIMPEL und EINFACH und VERSTÄNDLICH.

  • Bin mal so frei, eine andere Scriptsprache für das Bsp. #3 hinzuzufügen. Aber bitte nicht Steinigen :D


    Dadurch, dass aber weder AutoIt noch Autoh... konstante Werte zurückgeben (bei mir ca. 20000 - 38000 ms) lässt sich das schlecht vergleichen.

  • Danke :thumbup: , wie zu erwarten sind die Werte ähnlich, da die API Calls den Flaschenhals bilden.


    Ich habe einen weiteren Effekt hinzugefügt (GDI Elastic Twister Effect - Au3 vs FB), aber ohne die Runde auf 4 zu erhöhen, da sie eigentlich mit Runde 1+2 ähnlich ist.


    Guckst du Post#1

  • UEZ :
    Hallo,
    ich weiß, daß Du diesen Test speziell mit GDI/GDI+ machst.


    AutoIt ist ja eigentlich als Automatisierungstool gemacht worden. Kann man mit FB auch Programme automatisieren? Wenn ja, wäre da mal ein Geschwindigkeitstest interessant. Und weil es bereits oben erwähnt wurde, auch mit AHK.


    Danke und Gruß

  • Kann man mit FB auch Programme automatisieren?

    Man kann mit jeder Programmiersprache Programme automatisieren.
    Im Prinzip reduziert sich alles auf das Wrappern/Aufrufen einfachster API-Funktionen. Sobald du mit einer Programmiersprache Zugriff auf die Windows-API hast, kannst du dich austoben!
    Und da die Laufzeit der API-Funktionen für alle Programmiersprachen gleich ist, unterscheidet sich die Laufzeit der Programme lediglich durch den Overhead des Aufrufs. Was allerdings (wie bspw. auch bei Autoit) schon empfindlich die Laufzeit (gerade in Schleifen) beeinflussen kann!
    Ich habe neulich im Assembler-Forum gelesen, dass sich jemand über die Langsamkeit von GetPixel() aufgeregt hat. Da gab es dann wieder ellenlange Diskussionen, ich frage mich dann immer was diese Leute geraucht haben, KEIN MENSCH MIT HIRN liest 1000x1200 Pixel nacheinander mit einer API-Funktion aus.
    Eins steht fest, ES GIBT KEINE SCHNELLE API_FUNKTION. Punkt. Diskussion beendet.
    Die KANN es gar nicht geben, denn aus "sicherheitspolitischen" Gründen werden sämtliche Anwender (aus gutem Grund) als Vollspaten angesehen. Und daher wird oft mehr Error-Management in die Funktion gepackt, als letztendlich nötig wäre.
    Ein Sinus() per API dauert 3x so lange wie ein FSIN() per Opcode. In C(++) sind Intrinsics voll in Mode, damit lassen sich die "langsamen" C(++)/aka API-Befehle/Funktionen massiv beschleunigen. Sobald man weiß, was man tut....

  • UEZ :
    Hallo,
    ich weiß, daß Du diesen Test speziell mit GDI/GDI+ machst.


    AutoIt ist ja eigentlich als Automatisierungstool gemacht worden. Kann man mit FB auch Programme automatisieren? Wenn ja, wäre da mal ein Geschwindigkeitstest interessant. Und weil es bereits oben erwähnt wurde, auch mit AHK.


    Danke und Gruß

    Das kann ich dir im Detail nicht sagen, aber Andy hat recht, wenn er sagt, dass man fast mit allen Programmiersprachen automatisieren kann. Ich weiß nicht, inwiefern FB mit Automatisierungsfunktionen ausgestattet ist. Dafür ist ja AutoIt da...


    Ein weiterer Vorteil von FB ist, dass i.d.R. der Code auch unter Linux läuft. Für den grafischen Schnick-Schnack muss man ggf. Anpassungen vornehmen.

  • Hier noch ein weiteres Beispiel -> GDI Liquid Pixels (siehe Post #1) mit 278784 sich bewegenden Pixels. In AutoIt brauche ich erst gar nicht damit anzufangen. :*


    Danke an Eukalyptus für die schneller Sin/Cos ASM Funktionen! :rock:


    Momentan versuche ich _GDIPlus_BitmapCreateFromMemory in FB zu implementieren... ?(

  • mit Benchmarks die der realen Welt nahekommen?

    Was sind denn Benchmarks in "der realen Welt"?
    Textver/bearbeitung, sobald mit den nativen AutoItfunktionen vorgenommen, bedienen sich der API bzw. sind C(++)-Funktionen, von Regex ganz zu schweigen.
    Dateien benennen...na gut, wieviele tausende/millionen Dateien benennst du am Tag um? Ich verschiebe in einigen AutoIt-Scripten bei mehrmals täglichem Aufruf alle Dateien (einige hundert) älter als 14 Tage ins Nirvana bzw. in Sicherungsverzeichnisse, das ist im Vergleich zum restlichen Programmablauf (Aufbereitung von Maschinendaten) zeitlich völlig irrelevant.
    Und da alle meine in der Firma laufenden Scripte per Netzwerk auf Serverdaten zugreifen bzw. teilweise auch miteinander kommunizieren, ist deren Geschwindigkeit abhängig von der Netzwerkleistung/Infrastruktur. Und nicht von der Programmiersprache.


    Viel interessanter wäre u.a. Arraymanagement, bspw. Arraysort(). Da brauchen wir garnicht anzufangen, mehrere ineinander verschachtelte FOR/TO, siehe Anmerkungen/Beispiele in den obigen Posts, ich schätze Faktor 50-100 schneller als AutoIt.


    Alles, was mit aufwendigen (!) "Berechnungen" zu tun hat, bzw. mit langen/häufigen Schleifenaufrufen, läuft in FB wesentlich schneller.
    Um beispielsweise Börsenkurse aus dem Internet zu laden und grafisch darzustellen sind einige hundert Schleifendurchläufe nötig. Da ist es völlig unerheblich, ob die Grafik in 20 oder 200 Millisekunden dargestellt wird, wenn der InetGet() an sich schon mehrere Sekunden dauert.


    Imho ist es wesentlich wichtiger/sinnvoller, einen geeigneten/schnellen Algorithmus für die Problemlösung zu finden. Und da sind diverse Techniken und Programmiererskill gefragt, und nicht die "schnellste" Programmiersprache. Ein "langsamer" Algorithmus wird immer "langsam" bleiben, auch wenn er auf eine schnellere Hardware/Programmiersprache portiert wird.
    Nicht umsonst sind Assemblerprogrammierer in den letzten Jahren immer mehr gefragt, bzw. der Einsatz von "prozessornahen" Operationen in diversen Sprachen. Scheiss auf Portabilität, in den neuen Compilern/Bibliotheken werden je nach Architektur höchstoptimierte, genau auf DIESE EINE Architektur erstellte ASM-Sequenzen angesprungen. Die Zeiten von "der (Cross-)Compiler macht das schon..." sind nämlich vorbei. Die Compiler werden zwar immer besser, doch handoptimierter Code ist bei aufwendigen Aufgaben immer noch einen Tick schneller. Und im Bereich des Supercomputings, wo Zeit SEHR VIEL Geld kostet, verwendet niemand die Standard-Bibliotheken wenn es eine hochoptimierte Alternative gibt!

  • Wie wäre es denn mal mit Benchmarks die der realen Welt nahekommen?
    Z.B. Textverarbeitung, Dateien benennen/verschieben, Netzwerkleistung (TCP/UDP).

    Interessanter wäre der Vergleich zwischen den BASIC Derivaten bzw. mit anderen Compiler Sprachen, denn der direkte Vergleich mit AutoIt macht keinen richtigen Sinn.


    Da gebe ich Andy recht, dass man Tests wählen sollte, die keine externen Abhängigkeiten haben, damit das Ergebnis nicht verfälscht wird.

  • Hmmm, die Exe zu GDI Liquid Pixels sollte eigentlich nicht funzen, da der Pfad zu dem Bild fest eingelinkt wurde und keiner hat sich gemeldet.
    Ich dachte, dass __PATH__ & "\salvador-dali 528x528.png" ein Makro ist, ist aber nicht so.


    Ich habe jetzt den Code angepasst, sodass nur im gleichen Pfad geschaut wird, d.h. sollte jetzt funzen.


    Bitte mal testen!