PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie wird eine CPU-Auslastung eigentlich genau ermittelt?


RaumKraehe
2018-05-31, 21:26:01
Wie wird eine CPU-Auslastung eigentlich genau ermittelt?

Durch den Einstig in VR und den daraus resultierenden meist abschreckenden HW-Anforderungen habe ich meine Hardware mal genau beobachtet und folgendes Phänomen festgestellt.

Es gibt in der Tat Spiele da läuft die CPU nicht mit maximalem Takt, sondern schaltet runter. Das ist ja auch super ökologisch aber bei VR will man doch immer die maximale Leistung haben. Irgend wie. Oder? Das brachte mich zum nachdenken.

Naja, lange Rede kurzer Sinn: Wie wird so eine CPU oder GPU Auslastung eigentlich genau berechnet? Was wird da genau gemessen? Wie funktionieren die Sensoren? Was sind die Parameter?
Ich hatte bei dem Beispiel nicht mal das Gefühl das Leistung fehlte. 90 FPS waren es Konstant.

Tja, falls jemand Ahnung hat. :)

Geldmann3
2018-06-01, 02:24:58
Diese interessante Frage habe ich mir vor kurzem auch gestellt. Bei GPUs konnte ich mir ganz gut vorstellen, dass einfach gemessen wird, wie viele der Rechenwerke gerade ausgelastet sind, da die hier ja ziemlich universal verwendbar sind und je mehr gerade rechnen, desto höher die Auslastung.

Bei CPUs ist das Ganze nicht mehr ganz so einfach, da hier unterschiedliche Teile nur für spezifische Rechenoperationen nutzbar sind. Was passiert zum Beispiel, wenn die Multipliziereinheiten komplett ausgelastet sind aber die anderen Komponenten gar nicht? Sind das dann 100% Auslastung, obwohl ja nur ein Teil des Chips genutzt wird?

Doch jetzt ist mir gerade eine eventuell recht sinnvolle Idee gekommen, wie man die Auslastung so eines Chips recht verlässlich messen kann. Und zwar einfach über den Stromverbrauch eines Cores/einer GPU. Je mehr Einheiten aktiv, desto höher der Stromverbrauch. Das ist dann noch dazu ein Wert, der sich nicht verarschen lässt. Dafür müsste der Chip nur einmal ganz kurz messen, wie viel er maximal verbraucht.

Rolsch
2018-06-01, 08:05:01
Ich denke es ist viel simpler, es werden vermutlich die ausgeführten Befehle pro Zeiteinheit gemessen. Ob dabei andere Rechenwerke brachliegen spielt keine Rolle.

RaumKraehe
2018-06-01, 09:14:07
Doch jetzt ist mir gerade eine eventuell recht sinnvolle Idee gekommen, wie man die Auslastung so eines Chips recht verlässlich messen kann. Und zwar einfach über den Stromverbrauch eines Cores/einer GPU. Je mehr Einheiten aktiv, desto höher der Stromverbrauch. Das ist dann noch dazu ein Wert, der sich nicht verarschen lässt. Dafür müsste der Chip nur einmal ganz kurz messen, wie viel er maximal verbraucht.

Unwahrscheinlich. Da ist ja folgendes Problem. Ich gebe der CPU ein Aufgabe, dieser führt sie aus und senkt dabei den CPU-Takt. Irgend was im Rechner muss ja ermitteln das die Aufgabe welche die CPU ausführen soll auch ohne Probleme mit dem kleineren Takt zu bewältigen ist. Bei einem TV-Stream muss allerdings auch sichergestellt werden das man eben seine 50 Frames in der Sekunde bekommt.

Also irgend ein Mechanismus muss ermitteln das es ausreicht die CPU mit nur 800 Mhz laufen zu lassen und die dabei verfügbare Rechenleistung reicht halt aus um TV zu schauen. Ich hoffe ich hab das halbwegs verständlich geschrieben.

Ganon
2018-06-01, 10:28:19
Sie wird nicht "genau" ermittelt. Das ist alles eine Schätzung des Kernel wie lange ein Task in der CPU "hängt" und wie lange außerhalb. Der Kernel sagt nur: "Hier CPU, da hast'e einen Block Speicher, führe das mal aus" und dann hat der Kernel selbst auch keine direkte Handhabe mehr darüber was die CPU da jetzt eigentlich genau tut. Jetzt misst der Kernel einfach nur die Zeit wie lange irgendwas in der CPU hängt und wie lange nicht. Daraus ergibt sich dann die Prozent-Angabe.

Power Management ist noch mal eine andere Sache. Das basiert auch alles auf Schätzungen ob ein Task vielleicht schnell vorbei ist oder eher länger braucht, ob man einen Boost einlegt oder nicht, Temperatur und Power Target. Hierbei gibt es aber auch seit einiger Zeit Hardware-Unterstützung: Buzzword: Intel Speed Shift.

edit:
Um mal bei deinem Beispiel "Film schauen" zu bleiben. Mal von Hardware-Dekoding abgesehen. Der Decoder verlangt nun von der CPU einen Frame zu dekodieren. Bei einem 60fps Video hat die CPU nun ~16ms Zeit diesen Frame zu dekodieren, bevor der nächste Frame dran ist. Wenn die CPU jetzt aber schon nach 6ms fertig ist, dann tut sie die restlichen 10ms gar nichts mehr, die Auslastung sinkt und der Takt somit auch. So ganz grob zusammengefasst.

edit2:
Und um noch mal den Bogen zum Startpost zu kriegen: Wenn deine CPU beim Zocken runtertaktet, dann liegt der Flaschenhals irgendwo anders. Frame Limit, GPU Limit, IO Limit, was auch immer. Irgendwo klemmt es dann und es ist nicht die CPU.

Zafi
2018-06-01, 11:19:28
Wie es tatsächlich gemacht wird, weiß ich nicht. Aber ich würde es über den Leerlaufprozess ermitteln. Der Leerlaufprozess kann bei maximal Takt eine bestimmte Menge an Arbeit abarbeiten, diese Größe dürfte bekannt sein. Nun lässt man ihn mit niedrigster Priorität nebenher laufen und misst seine Auslastung. Wenn der Leerlaufprozess 75% seiner maximal möglichen Arbeit schafft, dann ist klar, dass 25% der CPU-Last von anderen Prozessen belegt ist.

Der_Korken
2018-06-01, 12:15:54
Bei CPUs ist das Ganze nicht mehr ganz so einfach, da hier unterschiedliche Teile nur für spezifische Rechenoperationen nutzbar sind. Was passiert zum Beispiel, wenn die Multipliziereinheiten komplett ausgelastet sind aber die anderen Komponenten gar nicht? Sind das dann 100% Auslastung, obwohl ja nur ein Teil des Chips genutzt wird?

Mit so einer Metrik wäre es nahezu unmöglich auf 100% Auslastung zu kommen, weil CPUs so viele Recheneinheiten pro Kern haben, dass gar nicht permanent alle ausgelastet werden können - zumindest nicht von normalen Code. Mit speziellen Burn-In-Tools geht es vielleicht. Wenn dein Programm nur multipliziert und alle Multiplzierer permanent beschäftigt sind, dann kann die CPU dein Programm nicht schneller ausführen, als sie es tut. In gewisser Weise ist sie damit zu 100% ausgelastet. Oder wenn du Code hast, der extrem viele Cache misses erzeugt, sodass die CPU zu 99% der Zeit nur auf den Speicher wartet. Ist das dann 1% Auslastung, weil nur 1% aller Takte Arbeit verrichtet wird, oder 100%, weil die CPU quasi schon so schnell "rechnet" wie sie kann? Kann der Kernel eigentlich messen (oder auslesen), wieviele Zyklen in der CPU Leerzyklen sind? Unter Windows gibt es ja diesen ominösen Leerlaufprozess, bei ich mich immer schon mal gefragt habe, was der eigentlich macht aber dann doch wieder zu faul zum recherchieren war :D.

Ganon
2018-06-01, 12:23:43
Der Leerlauf-"Prozess" ist kein Prozess in dem Sinne und tut auch nichts, sondern ist einfach nur die Zeit in die der Kernel Arbeit an CPUs geben könnte aber keine hat. Während der Zeit legt der Kernel halt CPUs schlafen, taktet sie runter oder was es sonst noch alles so für Stromspar-Maßnahmen gibt.

HisN
2018-06-01, 12:45:21
Unwahrscheinlich. Da ist ja folgendes Problem. Ich gebe der CPU ein Aufgabe, dieser führt sie aus und senkt dabei den CPU-Takt. Irgend was im Rechner muss ja ermitteln das die Aufgabe welche die CPU ausführen soll auch ohne Probleme mit dem kleineren Takt zu bewältigen ist.

Die CPU muss auf die Graka warten, die keine weiteren Befehle entgegennehmen kann, weil sie beschäftigt ist oder auf Sync (vsync) wartet.
Und schon greifen die Stromspar-Mechanismen von Windows und der CPU.
WER genau das jetzt macht .... kann ich Dir auch nicht sagen.

RaumKraehe
2018-06-01, 12:51:19
Die CPU muss auf die Graka warten, die keine weiteren Befehle entgegennehmen kann, weil sie beschäftigt ist oder auf Sync (vsync) wartet.
Und schon greifen die Stromspar-Mechanismen von Windows und der CPU.
WER genau das jetzt macht .... kann ich Dir auch nicht sagen.

In dem Fall war die Graka aber auh nur zu 50% belastet. Je nach dem ob man solchen Anzeigen nun glauben kann oder nicht.

Also GraKa bei 50%, CPU taktet auf 2,5 Ghz runter und in VR hatte ich trotzdem konstante 90 FPS.
Wahrscheinlich war einfach alles zu schnell und da V-Sync der Brille auf 90 FPS begrenzt hat musste der Rechner zu viel warten. Das wäre zumindest eine Erklärung.

MiamiNice
2018-06-01, 13:19:26
Ähm, die CPU Auslastung kannst Du nicht wirklich ermitteln. Es fängt doch schon damit an das unterschiedliche Software unterschiedlich viele Kerne nutzt.
Wenn wir jetzt eine Software starten die nur 4 Kerne nutzen kann und wir einen 8 Kerner im System haben ... zeigen quasi alle Orte an denen man die CPU Auslastung beobachten kann, mit Windows Boardmitteln, -> Müll an.

Ich mache das so unter VR:

Ich starte das Oculus Tray Tool und lasse mit das Overlay einblenden mit den FPS und den ASW, ATW Anzeigen. Wenn ich in der Software über 90 FPS habe -> wayne. Unter 90 FPS beobachte ich die Auslastung der GPU. Habe ich wenn ich unter 90 FPS falle nahe 100% Auslastung auf der GPU? Wenn ja, GPU Limit. Wenn nein, CPU Limit. Dem entsprechend in den Laden rennen und upgraden.

Rooter
2018-06-01, 13:25:26
Ich würde schätzen es wird die Zeit/sek genommen in der ein Programm tatsächlich Befehle an die CPU sendet.
Bei SMT/Multicore wird das dann noch durch die Zahl der Kerne möglichen Threads der CPU geteilt, daher zeigt es bei einem Quadcore, wenn nur 1 Kern voll ausgelastet ist, 25% an.

Jemand der sich auskennt kann ja mal in den Linux Quelltext schauen, da sollte ja erkennbar sein wie das abläuft. Mir fehlt dazu leider die Kompetenz. :redface:

Unter Windows gibt es ja diesen ominösen Leerlaufprozess, bei ich mich immer schon mal gefragt habe, was der eigentlich macht aber dann doch wieder zu faul zum recherchieren war :D.Im Wesentlichen führt der den HLT-Befehl auf der CPU aus, der den Kern schlafen legt was dann zum runtertakten und reduzierter Vcore führt.

MfG
Rooter

RaumKraehe
2018-06-01, 13:32:02
Im Wesentlichen führt der den HLT-Befehl auf der CPU aus, der den Kern schlafen legt was dann zum runtertakten und reduzierter Vcore führt.

MfG
Rooter

Das wäre doch aber ein erklärbarer Mechanismus. Wenn ich pro Zeiteinheit X 100% HLT Befehle habe dann ist die Auslastung bei 0%. Und umgekehrt.

SKYNET
2018-06-01, 14:28:50
Der Leerlauf-"Prozess" ist kein Prozess in dem Sinne und tut auch nichts, sondern ist einfach nur die Zeit in die der Kernel Arbeit an CPUs geben könnte aber keine hat. Während der Zeit legt der Kernel halt CPUs schlafen, taktet sie runter oder was es sonst noch alles so für Stromspar-Maßnahmen gibt.

wenn man das nicht will, stellt man im ernergieplan einfach bei CPU minimum leistung 100% ein, schon läuft die kiste die ganze zeit mit dem maximalmöglichem takt :)

aufkrawall
2018-06-01, 14:43:21
Nö, ab Skylake und Ryzen taktet die CPU intern selbstständig runter. Hab das schon mehrfach ausgeführt.

Fusion_Power
2018-06-01, 14:46:51
Ich frage mich immer, ob die Prozent Auslastungsangaben relativ oder absolut sind. Also, wenn eine auf 3GHz getaktete CPU zu 10% ausgelastet angezeigt wird und die CPU bei 1GHz auch zu 10%, dann ist die weniger ausgelastet? Der Takt schwankt ja permanent.

aufkrawall
2018-06-01, 14:50:06
Ist relativ. Wenn du SpeedStep ausschaltest, ist die gemeldete Auslastung bei geringer Last niedriger.

Rooter
2018-06-01, 15:53:06
Das wäre doch aber ein erklärbarer Mechanismus. Wenn ich pro Zeiteinheit X 100% HLT Befehle habe dann ist die Auslastung bei 0%. Und umgekehrt.Für die Gesamtlast geht das aber wie rechnet man es pro Prozess aus?

MfG
Rooter

Ganon
2018-06-01, 15:57:46
Für die Gesamtlast geht das aber wie rechnet man es pro Prozess aus?

Indem du ausrechnest wie lange der Prozess CPU-Zeit will und wie lange er schläft oder auf etwas anderes wartet.

PatkIllA
2018-06-01, 16:26:13
Indem du ausrechnest wie lange der Prozess CPU-Zeit will und wie lange er schläft oder auf etwas anderes wartet.
bei schlafen oder Warten auf IO wird der Scheduler den Prozess eh schlafen legen und die CPU was anderes machen lassen. Das braucht man für die Auslastung nicht besonders berücksichtigen. Zumindest wenn du übers OS gehst und nicht sowas wie spinlock machst. Da macht die CPU allerdings streng genommen auch was.

Ganon
2018-06-01, 17:13:07
bei schlafen oder Warten auf IO wird der Scheduler den Prozess eh schlafen legen und die CPU was anderes machen lassen.

Ja und somit ist die Auslastung des Prozesses 0% und darum ging es hier ja. Im Grunde ist ja alles nur "wie lange brauchte man CPU-Zeit im gewählten Zeitabschnitt".

Skysnake
2018-06-01, 20:04:07
Wie schon gesagt. Das ist sehr simpel. Also rein. Die Zeit die das OS an Software vergibt um etwas zu tun. Oft wird aber gerade beispielsweise Consumer Software nichts gemacht oder halt nur spinwaiting....

Wenn man wirklich wissen will ob die CPU etwas macht, dann muss man auf die Hardware Performance counter der CPU sczauen

Erdbeermayonnaise
2018-06-01, 20:27:18
Das ist durchaus dokumentiert: https://www.kernel.org/doc/Documentation/cpu-freq/


Jemand der sich auskennt kann ja mal in den Linux Quelltext schauen, da sollte ja erkennbar sein wie das abläuft. Mir fehlt dazu leider die Kompetenz. :redface:

RaumKraehe
2018-06-01, 22:28:12
Wenn man wirklich wissen will ob die CPU etwas macht, dann muss man auf die Hardware Performance counter der CPU sczauen

Und wie funktioniert so ein Counter? Was ermittelt der genau? Das ist ja hier die Frage.

Skysnake
2018-06-01, 23:42:56
Na der zählt das was der CPU-HERSTELLER implementiert...

Die counter muss man programmieren. Man kann also nicht alles gleichzeitig messen. Es gibt auch counter für Cores so um die 6 meist und dann noch uncore counter für l3 oder Speicherinterface z.b.

Einfach in die Intel Doku schauen. Da ist das für alle CPUS von denen im Detail dokumentiert

RaumKraehe
2018-06-02, 00:12:15
In Dokus schauen kann jeder. Ich hatte gehofft das es jemand mal schnell und verständlich erklären könnte.

Skysnake
2018-06-02, 06:25:00
Die Kurzfassung steht doch im mittleren Absatz. Wenn man es genauer wissen will muss man in die Doku schauen.

Du kannst sicherlich an die 50 Metriken in einer CPU messen. Und wenn du die Sachen aus dem OS dazu nimmst, wie bei Linux dann bist du bei um die 100. Was willst du jetzt also "einfach erklärt" haben?

Die 100 Metriken? Wie gesagt dafür gibt es Doku

cat
2018-07-07, 15:51:20
Bei der CPU-Auslastung finde ich den Ansatz mit der gesamt verfügbaren Rechenzeit "pro CPU" oder "logischem Kern" am einleuchtensten.
Klar sind wie in unserem Gehirn nie alle Teile im Kern gleichzeitig aktiv.
Ab Skylake hat jeder Kern glaub ich 7 Pipelines.

Bei der GPU wird es schon kniffliger das von "Anzeigetools her Offensichtliche" genau zu erklären woher die Prozent-Auslatung abgelesen werden.
Der GraKa-Treiber wird es vermutlich ans Betriebssystem melden.
Der Treiber könnte selbst auf mehrere interne Sachen achten:
- Register-Füllgrad
- Shaderrechenzeit-Budget
- ...
Und dann einen abstrahierten Wert ans System melden bzw. auslesbar machen.

Soweit mir bekannt sind GPU bis heute nicht als zur "CPU-gleichwertige" Bauteile ins Betriessystem integriert.
Der Hauptprozessor ist wie der Kaptain der das ganze Schiff steuert.

Der aktuelle Status ist eher ein Add-in Co-Prozessor, ohne selbstkoordienierten Off-Chip-Hardware-Zugriff zum Rest des Systems, abseits der VRAM-Zugriffe.

Im Software-Bewegtbild-Bereich gibt es dann z.B die Meldungen über die hier im Video detektiert werden kann, bzw. gut "geschätzt" wird "wann was limitiert".

- ab genau 15:26 wird auf die zu verfügung stehen den Daten eingegangen
- ab 19:25 wird erklärt wie die Daten interpretiert werden

https://youtu.be/c6sLiFIFd8o?t=948

wie schon vorher gesagt, nutzt VR eigentlich generell V-Sync, und das kann Rückstau in der Arbeitsabfolge verursachen, GPU-Mangelauslastung oder CPU-Wartezeit etc. bis hin zu Eingabeverzögerungen bei Rückstau.

Poook
2018-07-07, 17:02:23
Aus stackoverflow

PrevIdle = previdle + previowait
Idle = idle + iowait

PrevNonIdle = prevuser + prevnice + prevsystem + previrq + prevsoftirq + prevsteal
NonIdle = user + nice + system + irq + softirq + steal

PrevTotal = PrevIdle + PrevNonIdle
Total = Idle + NonIdle

# differentiate: actual value minus the previous one
totald = Total - PrevTotal
idled = Idle - PrevIdle

CPU_Percentage = (totald - idled)/totald

Also alle Zeiten welche nicht idle oder iowait ist, wird der Auslastung zugeschrieben.
Runtertakten und nicht ausgelastete Recheneinheiten scheinen nicht berücksichtigt zu werden.

Skysnake
2018-07-07, 19:13:58
Und daher ist der Wert auch absolut beschissen um irgendwelche Aussagen darüber zu sagen wie sehr die CPU wirklich gefordert wird. Man kann nur wirklich sagen wie viel sie nicht genutzt wird

Rooter
2018-07-07, 19:20:01
Und wenn man das von 100% abzieht kommt man nicht auf den gesuchten Wert!?

MfG
Rooter

Skysnake
2018-07-07, 20:29:07
Nein weil du nur eine Unterricht Schranke fürs nichts tun bekommst. Wenn 20% idle sich die macht die CPU definitiv 20% der Zeit nichts. Das heißt aber eben noch lange nicht, das sie nicht eigentlich 50% der Zeit nichts macht

gravitationsfeld
2018-07-08, 01:22:11
Die Diskussion koennen wir tagelang fuehren, es ist immer das selbe. Jeder hat seine eigene Definition von "sie macht etwas" und eine volle Auslastung aller Schaltkreise eines Kerns gibt es in der Praxis nicht.

Auslastung fuer mich ist, dass der (virtuelle) Kern nicht in einem Schlafzustand ist. Alles andere ist in der Praxis irrelevant.

Erdbeermayonnaise
2018-07-08, 11:56:06
Man kann sich natürlich auch dafür interessieren, in wie vielen der unhalted cycles die CPU tatsächlich arbeitet und in wie vielen sie nur auf Ressourcen wartet.

Mit einem Profiler kann man sich das anzeigen lassen, z.B. perf unter Linux.

Hier als Beispiel mit einem kurzen Program, dass naiv zwei 1000x1000 Matrizen multipliziert, ohne jegliche Optimierungen:

Auf einem Ryzen 5 1600:
perf stat -d -r 10 ./matrix

Performance counter stats for './matrix' (10 runs):

5050.689812 task-clock:u (msec) # 1.000 CPUs utilized ( +- 0.36% )
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
3,955 page-faults:u # 0.783 K/sec ( +- 0.01% )
18,381,019,075 cycles:u # 3.639 GHz ( +- 0.36% ) (49.95%)
8,972,196,138 stalled-cycles-frontend:u # 48.81% frontend cycles idle ( +- 3.58% ) (49.97%)
1,022,601,848 stalled-cycles-backend:u # 5.56% backend cycles idle ( +- 0.12% ) (50.00%)
42,108,575,071 instructions:u # 2.29 insn per cycle
# 0.21 stalled cycles per insn ( +- 0.03% ) (50.02%)
1,038,327,620 branches:u # 205.581 M/sec ( +- 0.30% ) (50.04%)
1,147,700 branch-misses:u # 0.11% of all branches ( +- 1.23% ) (50.05%)
25,559,563,160 L1-dcache-loads:u # 5060.608 M/sec ( +- 0.04% ) (50.03%)
6,319,719 L1-dcache-load-misses:u # 0.02% of all L1-dcache hits ( +- 32.30% ) (50.00%)
0 LLC-loads:u # 0.000 K/sec (49.98%)
0 LLC-load-misses:u # 0.00% of all LL-cache hits (49.96%)

5.051194938 seconds time elapsed ( +- 0.36% )

Die CPU scheint hier sehr gut "ausgelastet" zu sein, mit 2,29 Instruktionen pro Takt und sehr wenigen L1 Misses (auf den LLC musste gar nicht zurückgegriffen werden).

Auf einem Core i7-7600U:
perf stat -d -r 10 ./matrix

Performance counter stats for './matrix' (10 runs):

7090.857781 task-clock:u (msec) # 1.000 CPUs utilized ( +- 0.16% )
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
3,955 page-faults:u # 0.558 K/sec ( +- 0.01% )
27,487,990,502 cycles:u # 3.877 GHz ( +- 0.16% ) (49.96%)
42,116,604,769 instructions:u # 1.53 insn per cycle ( +- 0.02% ) (62.47%)
1,029,032,563 branches:u # 145.121 M/sec ( +- 0.11% ) (62.49%)
1,075,301 branch-misses:u # 0.10% of all branches ( +- 0.27% ) (62.52%)
22,062,090,516 L1-dcache-loads:u # 3111.343 M/sec ( +- 0.01% ) (62.54%)
1,191,545,360 L1-dcache-load-misses:u # 5.40% of all L1-dcache hits ( +- 0.02% ) (62.53%)
55,663,305 LLC-loads:u # 7.850 M/sec ( +- 0.89% ) (49.99%)
5,136,991 LLC-load-misses:u # 9.23% of all LL-cache hits ( +- 3.59% ) (49.97%)

7.093605877 seconds time elapsed

Hier musste die CPU deutlich mehr die Daten warten, der LLC wurde gebraucht und im L1 gab es erheblich mehr Misses. Insgesamt kamen damit nur 1,53 Instruktionen/Takt raus.

Poook
2018-07-08, 17:41:52
Eine wirklich genaue Anzeige würde auch zuviel Leistung schlucken. Wenn jedes Rechenwerk einen Wert übergeben müsste, wie lange und mit welcher Frequenz es benutzt wurde und dies dann an eine Matrix mit den verschiedenen Gewichtungen der einzelnen Rechenwerke übergeben werden müsste, wäre da wohl ein Viertel der CPU Leistung nur für die Auswertung der Auslastung verbrannt.

Skysnake
2018-07-08, 20:30:07
Die counter laufen mit nullkosten.

Nur das Auslesen braucht ein paar cycles. Wenn man das aber einmal in der Sekunde oder gar alle zwei macht, kannste den Overhead völlig vernachlässigen aufnehmen Desktop.

Selbst bei Clustern, bei denen man mit einigen hundert nodes an EINEM Problem rechnet ist es an sich egal.


Erst bei tausenden wird es dann nicht mehr egal.

Daher wie gesagt, auf dem Desktop völlig wurscht