Geschwindigkeitsoptimierung in AutoIt

    • Offizieller Beitrag

    Wieso sind meine Ergebnisse deutlich schneller als bei euch? In der Hardware sehe ich keine gravierenden Unterschiede (eher ist meine Hardware lahmer). :/

    Spoiler anzeigen


    Edit: Ergänzt um Beta-Ergebnisse

  • Spoiler anzeigen


    Wie man deutlich sieht, weichen die Ergebnisse der einzelnen "Tests" voneinander ab, obwohl diese direkt hintereinander durchgeführt wurden!
    DAS ist das eigentliche Problem bei AutoIt-Scripten!
    Wie soll man etwas profilen und nach Geschwindigkeit optimieren, wenn Laufzeitunterschiede von +-20-30% völlig normal sind?!
    Windows an sich funkt derart oft dazwischen, da bekommt ein Interpreter echte Probleme und öfter mal den Boden unter den Füssen weggezogen.
    Selbst während der Laufzeit dieser Tests werden Prozessorcores in den Tiefschlaf versetzt :D .

  • Sodele,
    habe mal bissl rumgespielt mit den P-Stats meines (Laptop-) Prozessors.
    Ich habe den überwiegenden Modus P6 (alles schläft, d.h. überwiegende Nutzung von Browser, Textverarbeitung, RDP usw) underclocked und massiv undervolted.
    Schon ab P5 ist aber die maximale Taktfrequenz für alle Cores eingestellt!
    Dadurch beschleunigt sich der Testlauf auf nahezu die dreifache Geschwindigkeit! vgl- oben.

    Spoiler anzeigen
    Code
    >CPU: AMD A6-3400M APU with Radeon(tm) HD Graphics X64
    >RAM: 1.29/3.48 GB
    >OS: WIN_7 (7601) X64
    >Parameter: 100
    +Func For (1)    needs for 4095 runs 424.79 ms (Average: 0.1037 ms)    --> 1.0x
    -Func While (2)    needs for 4095 runs 684.54 ms (Average: 0.1672 ms)    --> 1.6x
    !Func Do (3)    needs for 4095 runs 690.04 ms (Average: 0.1685 ms)    --> 1.6x


    Für 08/15-AutoItscripte bringt das den nötigen "Druck", allerdings sei erwähnt, dass solche "Optimierungen" nur sinnvoll sind, wenn man weiß, was man tut!
    Übrigens verkürzt sich die Batterielaufzeit im Akkubetrieb nicht, wenn nicht gerade Games gezockt, oder andere prozessorlastige Anwendungen laufen...

    //EDIT
    Um nochmal klarzustellen:
    Es wurde NICHTS übertaktet oder an der Hardware gepfriemelt, lediglich der voreingestellte "Schlafmodus" des Prozessors wurde per SOFTWARE angepasst!

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    Einmal editiert, zuletzt von Andy (20. Dezember 2014 um 09:18)

  • Hier meine Werte:

    Die Beta x64 scheint die schnellste Version zu sein.

    Gruß,
    UEZ

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • @UEZ und BugFix,
    sehr interessant, dass bei euren Prozessoren FOR ca. 10x schneller ist, als die anderen Schleifen!
    Ich vermute einfach mal ein "passendes" Flag beim Compilieren von AutoIt für diesen Prozessortyp. Wobei ich mich dann frage, was an einer WHILE 10x mehr Zeit verbraten soll?!
    Kann genausogut sein, dass der Prozessor bei FOR durch irgendwelchen Code NICHT in den Schlafmodus geschickt wird, bei den anderen Schleifen aber schon.

    Man sieht mal wieder deutlich die Hardware-Abhängigkeit, unabhängig von der Geschwindigkeit der verwendeten Prozessoren/Systeme.
    Ich dreh schon durch, wenn ich diese "Speedtests" sehe, die bei 20% Prozessorlast laufen. Was wird denn da gemessen?

    Vielleicht sollte man sich eher darauf konzentrieren eine UDF zu erstellen, welche bei zeitkritischen AutoIt-Scripten diese zwingt,
    - auf einem Prozessorkern zu laufen (und damit den Turbo-Modus zu erzwingen)
    - nicht durch das BS unterbrochen zu werden ( Priorität erhöhen)
    - uswusf (Ideen erwünscht ^^ )
    also erstmal die Hardware in einen definierten Zustand zu zwingen was ca. 200-300% Geschwindigkeitszuwachs bringt, bevor man sich Gedanken über Optimierungen innerhalb der Software macht, welche gerade mal 20-30% schnellere Ergebnisse erzielt!
    Im Batteriebetrieb bei Notebooks kann man ja (automatisch) diese Funktionen abschalten, bzw. per User-Interaktion auswählbar machen.

    Ich vermute, dasss gerade die aktuellen "Super-Duper-Stromspar-Prozessoren" egal von welchem Hersteller vom BS auf lange Akkulaufzeit gezwungen werden (ansonsten machen diese Dinger auch überhaupt keinen Sinn! )
    Daraus resultiert dann natürlich, dass so wenig Leistung wie möglich abgefragt wird. Wenig Leistung = geringe Geschwindigkeit...
    Was diesen Thread dann auch ad absurdum führt!

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    2 Mal editiert, zuletzt von Andy (20. Dezember 2014 um 09:26)

  • Ich habe mir die 1 Test Funktion mal näher angeschaut und es sieht so aus, als ob der Prozessor die "leere" For/Next Schleife anders ausführt als die anderen 2 Funktionen, die in der Schleife die Variable hochzählen.

    Ergo:

    [autoit]


    Func _TestFunc_1($vParam = False);funktion 1
    Local $j = 0
    For $i = 1 To $vParam
    $j += 1
    Next
    EndFunc ;==>_TestFunc_1

    [/autoit]

    Das Resultat sieht dann bei mir anders aus!

    Code
    >Result with AutoIt 3.3.12.0 x64.
    >CPU: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz X64
    >RAM: 4.25/7.43 GB
    >OS: WIN_81 (9600) X64
    >Parameter: 1000
    +Func For (1)    needs for 4095 runs 710.43 ms (Average: 0.1735 ms)    --> 1.0x
    -Func While (2)    needs for 4095 runs 1997.82 ms (Average: 0.4879 ms)    --> 2.8x
    !Func Do (3)    needs for 4095 runs 2062.90 ms (Average: 0.5038 ms)    --> 2.9x

    Das würde bedeuten, dass mein Prozessor die nichts tuende Schleife einfach ignoriert und deshalb es zu dem Faktor 12 kommt.

    Gruß,
    UEZ

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

    Einmal editiert, zuletzt von UEZ (20. Dezember 2014 um 14:49)

  • Das würde bedeuten, dass mein Prozessor die nichts tuende Schleife einfach ignoriert und deshalb es zu dem Faktor 12 kommt.

    Nein, der Prozessor ignoriert das imho nicht, ich bin überzeugt, dass der Code ausgeführt wird!

    [autoit]


    For $v = 10 To 22
    $t = TimerInit()
    $s = 2 ^ $v
    For $i = 1 To $s ;leere Schleife
    Next
    $m = TimerDiff($t)
    ConsoleWrite($v & " $i=" & $i & " Zeit=" & $m & @CRLF)
    Next

    [/autoit]

    Skaliert eindeutig!

    "Leere" Schleifen optimieren die gängigen Compiler weg, einem Interpreter diese Tricks beizubringen, ist etwas zuviel verlangt :), wozu auch?

  • Ich vermute eher, dass es die CPU ist, die bestimmte Befehle in den schnellen Cache legt, um wiederkehrende Prozessor Code schneller ablaufen zu lassen.

    Ich könnte ja dir meine komplilierte Exe geben und die sollte sich theoretisch nicht von deiner Version in Bezug auf Geschwindigkeit unterscheiden.


    Resultat von Post#13

    Code
    >Result with AutoIt 3.3.13.19 x64.
    >CPU: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz X64
    >RAM: 4.28/7.43 GB
    >OS: WIN_81 (9600) X64
    >Parameter: 100
    +Func For (1)    needs for 4095 runs 519.66 ms (Average: 0.1269 ms)    --> 1.0x
    !Func While (2)    needs for 4095 runs 685.15 ms (Average: 0.1673 ms)    --> 1.3x
    -Func Do (3)    needs for 4095 runs 671.51 ms (Average: 0.1640 ms)    --> 1.3x

    Gruß,
    UEZ

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯