Irgendwas stimmt mit der Ausführungsgeschwindigkeit nicht...

  • Moin,


    Im Zuge von Optimierungen (ja... aus irgendwelchen Gründen macht es mir Spaß AutoIt für Sachen zu verwenden für die es nicht geeignet ist) habe ich mal wieder ein paar Zeiten gestoppt.


    Beim Timing kommen aber aus irgendwelchen Gründen sehr verschiedene Ergebnisse heraus (ich öffne kein Windows Fenster/Msgbox, es ist also nicht der Skriptverlangsamungsbug der damit zusammenhängt).


    Diese beiden Ergebnisse tauchen beide bei mir reproduzierbar (mit einer gewissen Chance) auf.

    Ergebnis 1: Wenn ich im Skript Zeile 82 und 84 auskommentiere taucht vermehrt Ergebnis 1 auf.
    Ergebnis 2: Wenn ich im Skript Zeile 82 und 84 einkommentiere taucht vermehrt Ergebnis 2 auf.

    (Obwohl diese Zeilen (also eine For-Schleife von 0 bis 0) ansich keinen Einfluss haben sollten)


    Der Unterschied ist hier die Ausführungsgeschwindigkeit von BitOperationen, die brauchen plötzlich 2-3x so lange. Alle anderen Operationen laufen ähnlich schnell ab.


    Entweder sehe ich meinen offensichtlichen Fehler nicht, oder da ist irgendwas im Gange was ich nicht verstehe...

    Deshalb möchte ich in die Runde fragen ob dasselbe Verhalten noch bei anderen Leuten auftritt.



    PS: Ich verwende AutoIt Version 3.3.14.5, habe noch keine anderen Versionen getestet.

    lg

    M

  • Hallo!


    Habe das Script so wie Du es beschrieben hast laufen lassen: sehe aber keine großen Unterschiede ob die zwei Zeilen jetzt remarkt sind oder nicht!


    Ergebnisse:

    Benchmark Result
    _01 4828ns +30.5% ->| int32 bitand & bitshift
    _02 4195ns +13.4% ->| int32 bitand & bitshift (array als int)
    _2A 4073ns +10.1% ->| int32 bitand & bitshift (ternärer operator umgestellt, array als int)
    _2B 3701ns +0.0% ->| int32 bitshift & bitand (array als int)
    _2C 3778ns +2.1% ->| int32 bitshift & bitand (array als int)
    _2D 3940ns +6.5% ->| int32 bitshift & bitand (array als int)
    _03 6155ns +66.3% ->| int32 stringoperationen (array als int)
    _04 4549ns +22.9% ->| int32 stringoperation für Alpha, rest bitoperationen (array als int)
    _05 4585ns +23.9% ->| int32 struct (byte[4] access index, array als int)
    _5A 5245ns +41.7% ->| int32 struct (byte;byte;byte;byte access element, array als int)
    _5B 4762ns +28.7% ->| int32 struct (byte[4] access index via name, array als int)


    Benchmark Result
    _01 4826ns +30.7% ->| int32 bitand & bitshift
    _02 4187ns +13.4% ->| int32 bitand & bitshift (array als int)
    _2A 4062ns +10.0% ->| int32 bitand & bitshift (ternärer operator umgestellt, array als int)
    _2B 3692ns +0.0% ->| int32 bitshift & bitand (array als int)
    _2C 3765ns +2.0% ->| int32 bitshift & bitand (array als int)
    _2D 3947ns +6.9% ->| int32 bitshift & bitand (array als int)
    _03 6161ns +66.9% ->| int32 stringoperationen (array als int)
    _04 4557ns +23.4% ->| int32 stringoperation für Alpha, rest bitoperationen (array als int)
    _05 4577ns +24.0% ->| int32 struct (byte[4] access index, array als int)
    _5A 5240ns +41.9% ->| int32 struct (byte;byte;byte;byte access element, array als int)
    _5B 4753ns +28.7% ->| int32 struct (byte[4] access index via name, array als int)


    lg

    Racer

  • Deshalb möchte ich in die Runde fragen ob dasselbe Verhalten noch bei anderen Leuten auftritt.

    PS: Ich verwende AutoIt Version 3.3.14.5, habe noch keine anderen Versionen getestet.

    Hier mal ein Test mit AutoIt 3.3.14.0, Win 7 SP1 64-Bit :


    Test 1 :

    ;~ For $_ = 0 To 0 Step 1

    Bench(10)

    ;~ Next

    Test 2 :

    For $_ = 0 To 0 Step 1

    Bench(10)

    Next

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • So sieht es bei mir aus:


    Benchmark Result Zeilen 82/84 auskommentiert

    _01 12364ns +32.1% ->| int32 bitand & bitshift

    _02 10781ns +15.2% ->| int32 bitand & bitshift (array als int)

    _2A 10293ns +10.0% ->| int32 bitand & bitshift (ternärer operator umgestellt, array als int)

    _2B 9357ns +0.0% ->| int32 bitshift & bitand (array als int)

    _2C 10195ns +9.0% ->| int32 bitshift & bitand (array als int)

    _2D 9586ns +2.4% ->| int32 bitshift & bitand (array als int)

    _03 14952ns +59.8% ->| int32 stringoperationen (array als int)

    _04 11800ns +26.1% ->| int32 stringoperation für Alpha, rest bitoperationen (array als int)

    _05 11331ns +21.1% ->| int32 struct (byte[4] access index, array als int)

    _5A 13092ns +39.9% ->| int32 struct (byte;byte;byte;byte access element, array als int)

    _5B 10924ns +16.7% ->| int32 struct (byte[4] access index via name, array als int)


    Benchmark Result Zeilen 82/84 nicht auskommentiert

    _01 12184ns +30.6% ->| int32 bitand & bitshift

    _02 10858ns +16.4% ->| int32 bitand & bitshift (array als int)

    _2A 10207ns +9.4% ->| int32 bitand & bitshift (ternärer operator umgestellt, array als int)

    _2B 9602ns +2.9% ->| int32 bitshift & bitand (array als int)

    _2C 9332ns +0.0% ->| int32 bitshift & bitand (array als int)

    _2D 10208ns +9.4% ->| int32 bitshift & bitand (array als int)

    _03 15597ns +67.1% ->| int32 stringoperationen (array als int)

    _04 11523ns +23.5% ->| int32 stringoperation für Alpha, rest bitoperationen (array als int)

    _05 11763ns +26.1% ->| int32 struct (byte[4] access index, array als int)

    _5A 12719ns +36.3% ->| int32 struct (byte;byte;byte;byte access element, array als int)

    _5B 11102ns +19.0% ->| int32 struct (byte[4] access index via name, array als int)

  • Ja, das sind die Ergebnisse, die ich bei mir auch erwartet hätte (Racer, Musashi, Bitnugger). Also, dass BitShift & BitAnd immer am schnellsten sind. Aus irgendwelchen Gründen ist BitShift + BitAnd bei mir (wenn man die Schleife auskommentiert) mit einer gewissen Wahrscheinlichkeit (klappt nicht immer, aber oft... 50% chance auf das "schlechte" Ergebnis) wesentlich langsamer als es sein sollte. Die Operationen werden mehrere zehntausendmal ausgeführt, beste/schlechteste Ergebnisse werden verworfen und das "gemittelte Drittel in der Mitte" ergibt das Timingergebnis. Stochastische Aussetzer sind damit mehr oder weniger ausgeschlossen.

    Dann steht es jetzt 3:1 dafür, dass mein PC seltsam ist ^^

  • Virenscanner? Evtl. auch einfach nur ein Caching Phänomen deiner CPU oder Betriebssystem, evtl. wird deine CPU auch erst nach einer gewissen Zeit unter hoher Last höher getaktet? Autoit nutz außerdem nur einen Kern, es wäre also denkbar, dass manchmal der "bessere" weniger belastete Kern genutzt wird und manchmal ein eher ausgelasteter oder noch schlimmer, dass der Task zur Laufzeit auf einen anderen Kern verschoben wird.


    Hatte selbst schon beobachtet, dass bei mehrmaliger Ausführung eines Scriptes in kurzen Abständen die Laufzeit besser wurde.

  • Hi,


    habe folgende Ergebnisse, AutoIt als einziges offenes Programm, ansonsten ruhender Desktop

    Desktop Ryzen 5 1600



    Und noch mit Laptop I7-7500U

    Mit einer For/To-Schleife bis 5 komme ich direkt nach Rechnerstart und neu gestartetem AutoIt auf folgendes...

    Der erste Durchlauf...(Schleife 3 bis 5 sind gleich wie 3) wiederum ruhender Desktop (Prozessor runtergetaktet lt. Taskmanager)

    Durchlauf direkt im Anschluß


    Das bestätigt meine schon vor etlichen Jahren gemachte Erfahrung mit AutoIt, dass die Programmlaufzeiten im direkten Zusammenhang mit "anderen" Aktivitäten im Rechner zusammenhängen.

    Speziell Festplattenzugriffe und eifriges geswappe im Scheduler führen zu unterschiedlichen Laufzeiten.

    Wobei das natürlich Gemecker auf allerhöchstem Niveau ist^^

    Im vorliegenden Fall geht es im einige handvoll Millisekunden. Für einen "Benchmark" ist das natürlich kritisch, aber benchmarken ist auch immer eine Feststellung der AKTUELLEN Programmlaufzeit und sollte auch so beurteilt werden.


    Trotzdem findet man innerhalb der AutoIt-Versionen dadurch auch mal "undokumentierte" Veränderungen, so bspw. die in der Vergangenheit um Faktor 3 bis 5 verlangsamten "String-Funktionen" bei einer neueren AutoIt-Version, wo ich vermutet hatte, dass dies seitens Entwickler absichtlich gemacht wurde, um das "professionelle" RegEx Geschwindigkeitsmäßig in den Vordergrund zu heben indem man die "Butterbrot"-Programmiererfraktion ins Abseits stellt.

  • Wenn ich die Funktion "_5A()" so ändere, dann ist sie in beiden Fällen die jeweils schnellste:


    Edit:

    Und so ist die Funktion noch ein Tick schneller:

  • Andy : Danke, ich dachte schon bei mir spinnt etwas. Dachte eigentlich ich hätte 6 Kerne und nur einen Browser nebenbei offen (ohne Videoplayback) und <5% cpu Last während dem Test, da war ich irgendwie in der Annahme, dass das Skript einen eigenen Kern bekommt und dementsprechend immer gleichschnell abläuft... Hatte (mit Last auf der CPU) jetzt auch Durchläufe die mehr als 10x länger gebraucht haben (Da stand dann nicht mehr 5000ns, sondern 50000ns...)


    Dann schätze ich, dass der Thread abgehandelt ist. Fazit: AutoIt verlangsamt ne nach Zustand des restlichen PCs willkürlich ausgewählte Funktionen um willkürliche Faktoren.


    Oscar: Auch hier vielen Dank, die Version ist für meinen Anwendungsfall sogar noch besser, da die Daten bereits vorab in einer Struct liegen und damit der SetData Schritt entfällt :thumbup:

  • da war ich irgendwie in der Annahme, dass das Skript einen eigenen Kern bekommt und dementsprechend immer gleichschnell abläuft

    Das kannst du im Scheduler in Windows erzwingen, indem du nach Starten des Scripts im Taskmanager einen Rechtsklick auf das Programm machst, dort im Menü auf "Zu Details wechseln" klickst, in der folgenden Ansicht nochmals Rechtsklick auf das Programm und dort im Menü "Priorität festlegen" auf "Hoch" einstellst.

    Das geht natürlich auch innerhalb des Scripts per ProcessSetPriority ( "process", priority )

  • Trotzdem findet man innerhalb der AutoIt-Versionen dadurch auch mal "undokumentierte" Veränderungen, so bspw. die in der Vergangenheit um Faktor 3 bis 5 verlangsamten "String-Funktionen" bei einer neueren AutoIt-Version, wo ich vermutet hatte, dass dies seitens Entwickler absichtlich gemacht wurde, um das "professionelle" RegEx Geschwindigkeitsmäßig in den Vordergrund zu heben indem man die "Butterbrot"-Programmiererfraktion ins Abseits stellt.

    Das hatten wir doch damals schon durchgekaut - diese "Verlangsamung" konnte ich >>bei mir damals nicht reproduzieren<<.