Warum langsam durch mehrere Prozesse ?

    Hey,

    nach langem rumprobieren ohne Erfolg habe ich eine Frage an euch.

    Ich habe ein Testscript erstellt:

    Code
    While 1
    If FileExists(@WorkingDir & "\Test.au3") = 1 Then
        Beep()
    EndIf
WEnd

    Wenn ich dieses Script als .exe starte, verbraucht es 3% der max. CPU-Auslastung. (3% ist auch das Maximum, dass AutoIT in einer leeren While Schleife benutzt)

    Sobald ich aber das Script 2-3 mal öffne, sollte eigentlich jeder Prozess 3% Auslastung in Anspruch nehmen... komischerweise springt auf einmal die CPU-Auslastung von den 2-3 Prozessen von 3% auf 2%.

    Habe auch getestet, die .exe einfach mal 5-10 mal zu öffnen, dann springt die CPU-Auslastung von jedem einzelnen Prozess auf 0-1%, wobei der Leerlaufprozess auf 95-99% läuft.

    Okay, AutoIT kann kein Multithreading, aber dann sollte doch trotzdem jeder Prozess auf seinem max. von 3% Auslastung laufen, oder nicht ?

    mfg

    Je mehr Prozesse du startest desto mehr ist dein Betriebssystem damit beschäftigt die anfallenden Aufgaben (Tasks) der Prozesse sinnvoll auf die physikalischen CPU Kerne und sofern vorhanden virtuellen Kerne (HT) zu verteilen. Dies erledigt der Taskscheduler des Betriebssystem. Damit im Endeffekt die verfügbaren Ressourcen gleichmäßig genutzt werden. Sollte dieser der Meinung sein ein anderer Core ist weniger ausgelastet und besser geeignet werden alle Task Daten des L1/L2 Caches in den Cache des anderen Kerns transferiert und die Aufgabe dort fortgesetzt. Wenn da dann zufällig auch noch ein anderer Task läuft muss deiner warten bis dieser abgeschlossen ist oder ebenfalls auf einen anderen Kern verschoben wurde. Dieser Vorgang kostet Rechenzeit.

    Dein Testscript generiert im Erfolgsfall außerdem noch ein externes Event und nutzt hierfür vermutlich einen Systemprozess (Beep). Auch der Zugriff auf die Festplatte findet unglaublich oft statt, da du keine Pause in der Schleife verwendest. Dein Code ist also nicht nur CPU limitiert, sondern auch davon abhängig schnellstmöglich Rückmeldungen vom Betriebssystem zu erhalten. Das könnte aber durch die Anzahl an Tasks zu beschäftigt sein, insbesondere Wenn Windows nur 1-2 Cores hierfür paralell nutzt. Deine System Tasks werden vom Taskscheduler dann eben eingereiht bis die Tasks abgeabeitet wurden. Der Mehrnutzen durch paralelle Anfragen geht dann weitestgehendst verloren.

    Anderst schaut das wahrscheiunlich aus, wenn du massive Berechnungen in deinen eigenen Scripten durchführst und weitgehend unabhängig vom Betriebssystem vor dich hinrechnest.

    Das Thema wurde vor ein paar Wochen hier übrigens schonmal sehr ausführlich beleuchtet. Vielleicht hat ja jemand Lust dir den Thread rauszusuchen.

    Hi,

    Zitat von Larsson

    Wenn ich dieses Script als .exe starte, verbraucht es 3% der max. CPU-Auslastung.

    Zitat von Larsson

    Sobald ich aber das Script 2-3 mal öffne.....,

    Zitat von Larsson

    dann springt die CPU-Auslastung von jedem einzelnen Prozess auf 0-1%

    sagt wer?

    Ohne Angabe des verwendeten Systems (Prozessor), des Betriebssystem und dessen Einstellungen der ANZEIGE (!) dieser Daten ist nicht nur die Fragestellung, sondern auch jede Antwort obsolet.

    In deinem speziellen Fall noch besonders, da in einer "unendlich" schnellen Schleifenkonstruktion (While 1) der einzige limitierende Faktor ein endlich schneller Zugriffsprozess mit (Achtung!) GLEICHEM (und auch aus der Sicht eines Anwenders sehr schnellem) Zeitverlauf ist.

    Einfaches Beispiel:

    Der Refresh der Anzeige,also die Messdauer, in einem "Auslastungsanzeigetool" eines bestimmten Prozesses ist auf 1 Sekunde (1000 Millisekunden) eingestellt. Du fragst die "Auslastung" eines Prozesses1 ab, der 100 Millisekunden dauert. In diesen 100 Millisekunden läuft der Prozessor mit 100% Leistung. Es ergibt sich eine "Auslastung" des Prozessors mit diesem Vorgang von ...naja, da muss man kein Mathegenie sein, von 10%. Das Anzeigetool zeigt "Prozessorauslastung Prozess1 von 10%" an.

    Die gleiche Auslastung ermittelt das Tool, wenn innerhalb dieser einen Sekunde ein Prozess2 tausend(!) Mal mit einer Dauer von einer zehntel Millisekunde die volle Prozessorleistung beansprucht. "Prozessorauslastung Prozess2 von 10%".

    Prozess1: Messdauer 1000 Millisekunden, Prozessorauslastung Prozess1 von 1 Mal 100 Millisekunden > Anzeige Auslastung 10%.

    Prozess2: Messdauer 1000 Millisekunden, Prozessorauslastung Prozess2 von 1000 Mal 1/10 Millisekunden > Anzeige Auslastung 10%.

    Soweit so klar!

    Jetzt verkürzen wir den Anzeigerefresh (die Messdauer) auf eine halbe Sekunde. Was macht das Tool? Es misst die Zeit und die Prozessorauslastung und bildet das Verhältnis. In x Zeit y Prozessorlast.

    Für obige zwei Beispiele:

    Prozess1: Messdauer 500 Millisekunden, Prozessorauslastung Prozess1 von 1 Mal 100 Millisekunden > Anzeige Auslastung 20%.

    Prozess2: Messdauer 500 Millisekunden, Prozessorauslastung Prozess2 von 500 Mal 1/10 Millisekunden > Anzeige Auslastung 10%.

    ....

    Prozess1: Messdauer 200 Millisekunden, Prozessorauslastung Prozess1 von 1 Mal 100 Millisekunden > Anzeige Auslastung 50%.

    Prozess2: Messdauer 200 Millisekunden, Prozessorauslastung Prozess2 von 200 Mal 1/10 Millisekunden > Anzeige Auslastung 10%.

    ....

    Prozess1: Messdauer 100 Millisekunden, Prozessorauslastung Prozess1 von 1 Mal 100 Millisekunden > Anzeige Auslastung 100%.

    Prozess2: Messdauer 100 Millisekunden, Prozessorauslastung Prozess2 von 100 Mal 1/10 Millisekunden > Anzeige Auslastung 10%.

    ....

    Oha!

    Je nachem, welche die "Bedingungen" eingestellt sind, ergeben sich spektakulär erscheinende Unterschiede!

    Wenn also jemand von

    Zitat von Larsson

    verbraucht es 3% der max. CPU-Auslastung.

    spricht, und daraus folgert, dass die "Anzeige" für alle (!) möglichen Prozesse genau ist, dann irrt er sich gewaltig! Das Anzeigetool gibt nur SEHR grobe "Tendenzen" wieder.


    Neben den von misterspeed schon dargebrachten Erklärungen kommt noch hinzu, dass die im Startpost verwendete Funktion "FileExists()" natürlich NICHT bei jedem Aufruf das Verzeichnis auf dem Datenträger scannt!

    Wozu auch?! Das Betriebsystem lädt beim ersten (!) Aufruf dieser Funktion den Ordnerinhalt in den RAM, also den Speicher (caching) und stellt diese Daten dann sehr schnell, da aus dem Cache gelesen, zur Verfügung. Erst wenn sich der Ordnerinhalt ändert, wird der "Dateicache" gelöscht und neu aufgebaut. DAS dauert. Ein Zugriff auf eine Festplatte und auch eine SSD sind um ein Vielfaches langsamer als ein Speicherzugriff!

    Von daher ist bei "Geschwindigkeitsüberprüfungen" immer sicherzustellen, dass exakt die gleichen Bedingungen vorherrschen.

    Aber genau DAS ist bei den heutigen hochoptimierten Betriebssystemen und Prozessoren, die nebenbei auch natürlich versuchen, richtige "Vorhersagen" zu treffen und Daten schon "auf Vorrat" im RAM zu speichern (cachen), damit der User die Daten dann "schnell" aus dem Cache bereitgestellt bekommt, schlicht UNMÖGLICH!

    Wenn jetzt auch noch Multithreading/tasking Betriebssysteme und Multicoreprozessoren mit Hyperthreading ins Spiel kommen, ist es ganz aus....

    Da stellt sich dann die Frage nach einer "cleveren" Lösung!

    Und die sieht imho im Fall von Larsson ganz einfach aus.

    Frag nicht hunderte oder tausende Mal pro Sekunde die Existenz einer Datei ab, sondern lasse dich vom Betriebssystem einfach darüber informieren, wenn diese Datei erstellt/gelöscht/geändert wurde!(<das ist ein Link!)

    Nebenbei "rödelt" die Platte/SSD nicht permanent, sondern kann ggf. im Tiefschlaf energiesparend warten, und der Prozessor, der jetzt mit 3% Last permanent UNNÖTIGE Arbeit verrichten muss, auch!