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

  • Ich bin ziemlich sicher, dass mindestens noch ein Faktor 5-10 in der Geschwindigkeit der Berechnung machbar wäre, würde man die FPU-Sequenz in Assembler handcoden....von SSE mit 4 gleichzeitig berechenbaren Arrayinhalten garnicht zu reden. Die Compilereinstellung zur Verwendung von SSE bringt übrigens keinen Vorteil, die "schnelleren" Befehle werden gänzlich von unproduktiven Zugriffen auf den Speicher ausgebremst

    Ich habe auch mal die schnelleren Sin/Cos Funktionen von Eukalyptus benutzt, aber das sehe ich kein Geschwindigkeitsgewinn. D.h. ich kann das nur bestätigen, was du geschrieben hast.

    Habt ihr das mal mit Direct2D probiert?

    Ich kann dir nicht sagen, warum ich und einige andere immer auf GDI/GDI+ herumreiten, obwohl es bessere Gfx Libs gibt, wie z.B. die Direct2D UDF.
    Vielleicht "Macht der Gewohnheit" oder weil's leichter fällt oder einfach nur Sturheit...

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Ich kann dir sagen, warum du das machst. GDI+ funktioniert, D2D nicht. (zumindest in AutoIt).
    Ich habe viel mit D2D herumprobiert, und es gibt wirklich schöne Sachen die damit möglich sind, die man mit GDI+ direct in die Tonne treten kann. Allerdings funktionieren schon triviale Sachen wie "Lade ein Bild mit Alphakanal aus dem Arbeitsspeicher" nicht einfach so, obwohl es speziell zu diesem Zweck D2D Funktionen gibt. Ich habe Stunden und Tagelang (mit eukalyptus zusammen) herumprobiert, die Funktionen arbeiten in AutoIt nicht so wie sie sollten. Weiterhin ist es schwieriger Fehler zu finden, bei GDI+ gibt es wesentlich weniger "seltsame Einstellungen", Flags, "Versionen eines Elements" usw usw, die einem die Fehlersuche erschweren. Wenn es klemmt schaut man, ob GDI+ Startup aufgerufen wurde, überprüft ein paar Variablen, fertig. Bei D2D kommt es oft vor, dass alles so ist wie es sein sollte und man keine Ahnung hat was hier eigentlich los ist und warum etwas nicht funktioniert.

    In golang habe ich SDL ausprobiert und muss sagen: Das ist ein schöner Wrapper für D2D (sehr einfach gehalten, tut exakt das was es soll, schmiert nicht oft ab wenn man Fehler macht), ist wahrscheinlich auch in AutoIt wesentlich einfacher zu verwenden als D2D. UDFs in der Richtung gibts soweit ich weiß auch.

    lg
    M

  • In AutoIt habe ich mit GDI 10fps und mit GDI+ 6 fps.
    Man kann tatsächlich einen minimalen Unterschied feststellen,
    bei GDI+ ruckelt es ein wenig mehr.

    AutoIt hat mit 13,9% auch deutlich mehr CPU Auslastung als FB (GDI) mit 7%.

  • Heute habe ich in der aktuellen c´t einen umfassenden Bericht zum Thema von Apples neuer Grafikschnittstelle Metal gelesen. Diese ist, da Apple eins der führenden Mitglieder der Khronos-Group ist, sehr nah mit Vulkan verwandt. Verglichen wird im Bericht fast ausschliesslich mit OpenGL, Vor- und Nachteile werden herausgestellt.
    Dabei interessant ist der Ansatz von Vulkan/Metal, dem Entwickler mehr Freiheiten (und vor allem auch Verantwortlichkeiten! ) im Bezug auf die Programmierung der Hardware zu geben, und somit die API extrem schlank und somit schnell zu machen!
    Etwas, dass GDI/GDI+ gänzlich fehlt....

    M$ geht davon aus, dass alle machbaren Fehler seitens Programmierer auch gemacht werden, und darauf hin werden die API´s programmiert! Fehlermanagement der allerfeinsten Sorte, die Funktionen werden laufzeittechnisch totgespielt, da man von einem Vollhonk von Anwender ausgeht (und das in vielen Fällen leider auch muss, wer das nicht glaubt, der liest die Beiträge zu diesem Thema in gängigen Foren... || ). Oberste Priorität ist dabei, ALLE möglichen und unmöglichen Fehler des Anwenders abzufangen und diese dann in einer schönen Message auszugeben. Nicht umsonst ist die erste Frage auf die geschilderten Probleme des Anwenders/Programmierers (in AutoIt lautet diese Frage übrigens genauso unisono) "Wie lautet denn der Fehlercode/die Errormeldung?!"

    Ich gehe davon aus, dass GDI(+) nur deshalb noch existiert, weil es die Grundlage der M$-Fensterdarstellung ist. Für grafische Fensterinhalte gibt es andere/bessere/schnellere Grafikbibliotheken.

    Wieso GDI+ bei identischen Funktionen meßbar langsamer ist als das "uralte" GDI, sollte jetzt klar sein :love: . Dazu der imho inkonsistente und unverständliche Gebrauch verschiedenster Funktionsverweise/namen wie bsp. Graphics/Bitmap/HBitmap/Image in GDI+ für ein und dasselbe schrecken mich immer von neuem ab.
    Entweder "schnell" in oldschool GDI oder aber gleich eine wirklich schnelle Alternative wie D2D/OpenGL wobei OpenGL wie oben beschrieben für "professionelle" Anwendungen auch schon wieder als zu langsam/schwerfällig empfunden wird... :Face:

  • Bei AutoIt haben alle 3 Varianten, also GDI, GDI+ und OpenGL in etwa die gleiche Performance, ca. 10 FPS.
    FB ist in GDI/GDI+ gerade einmal doppelt so schnell, also 20FPS, das liegt offensichtlich an den "einfachen" Berechnungen.
    OpenGL in FB hat "nur" 7 FPS, allerdings bei 130000 Rechtecken/Sekunde und ca. 1 Million Recursions-Calls :rock:

  • OpenGL in FB hat "nur" 7 FPS, allerdings bei 130000 Rechtecken/Sekunde und ca. 1 Million Recursions-Calls


    Meine Werte:
    PT.png


    Bei der gleichen Rekursionstiefe wie bei GDI, komme ich auf ca. 70 FPS, ca. 300.000 Rekursionsaufrufe pro Sekunde und 4095 Rechtecken pro Funktionsaufruf.

    ^^

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Und noch'ne Spielerei -> GDI Particle Repulsion Grid (einfach die Maus über das Bild bewegen...)

    Mit AutoIt nicht in dieser Geschwindigkeit realisierbar.

    Edit: jetzt noch mit Scroller und Tracker Sound
    GDI Particle Repulsion Grid v1 + sound build 2016-10-13.png