__RDTSC und Intrsuctions
-
Danke für die Antwort!
Wie kann ich sonst die Auslastung der CPU(s) sinnvoll messen?
Ich kann ja immerhin schon alle möglichen MSRs der Prozessoren auslesen!
Wie zB Instructions retired -> da muss man doch irgendwie auf die Auslasung kommen?
uops retired gibts ja auch -> aber die anzahl der uops ist ja abhängig von der instruktion!
Bitte um tipps

-
Ich weiss nun irgendwie immer noch nicht, was du unter "Auslastung der CPU" genau verstehst. Allgemein wuerde ich campers Andeutungen folgen.
Dh. IMHO also nicht so viel mit irgendwelchen internen Stats der CPU herumwirbeln, sondern wenn du in einem Betriebssystem wie Windows programmierst, selbiges befragen (waere ein Thema fuer WinAPI), oder wenn du selbst mit deinem Programm das System stellst (meist zB. auch in DOS der Fall), zB. mit einem timer abpassen, welche Zeitanteile dein Code im "idle-block" laeuft.
Da gibt es aber je nach Anwendung/Anforderungen verschiedenste Moeglichkeiten und die wenigsten bedienen sich an CPU-Stats. Ehrlich gesagt koennte ich gerade ueberhaupt kein Beispiel aus dem Aermel schuetteln, das sich an MSRs orientiert.
-
Naja aber wenn ich die Prozessorauslastung genauer haben will, aloso wirklich die Zeit wo die CPU auch "irgendwas" rechnet!
wenn ich mit der WinAPI (siehe TaskManager) die "auslastung" messen möchte -> bekomm ich doch auch Wartezeiten bei SPeicherzugriffen o.ä. als 100%ige Auslastung präsentiert!
-
Ich kenne zumindest kein Interface fuer die Messung der Zeit, die eine CPU durch I/Os komplett blockiert ist, falls du das meinst.
-
Pro Takt (gezaehlt mit dem TSC-Register) koennen je nach Prozessor 3 oder 4 MicroOps ausgefuehrt werden.
Damit laesst sich das Maximum bestimmen.Ist dies korrekt? Ich weiß das auf ner CPU pro Takt max 4 UOPS ausgeführt werden können -> demnach kann ich die Auslastung in % ermitteln!
d.h. ich weiß die anzahl der ausgeführten uops und die anzahl des takte (rdtsc)
Ist das so richtig? Oder seh ich das komplett falsch?
-
welche Auslastung?
-
Also wenn ich das richtig verstanden habe, definiert hmmm2 "Auslastung" hier als (Delta_µOps)/(Max_µOps*Delta_TSC). Wenn er weiss, wie er an diese Werte kommen kann, spricht auch nichts dagegen, dass das irgendwas liefern koennte.
... Was das bringen soll ist dann noch eine andere Frage... Um tatsaechlich nutzbare Ressourcen der CPU zu bestimmen ist diese Methode IMHO eher unpraktisch.
-
Insbesondere wird diese Auslastung dann besonders niedrig sein, wenn die CPU grade mit komplexen transzendenten Berechnungen zu tun hat.
-
Ja ihr seht schon mal richtig was ich bereits in meinem hirn plane

Auf die PerformanceCounter hab ich zugriff.......... über nen selbstgeschriebenen Treiber der die rdmsr und wrmsr Befehle aufruft!
Mein Problem ist, dass ich nicht genau weiß, wie ich die Auslastung der CPU messen soll!
WAS ist die Auslastung/Performance genau? Wie mess ich die halbwegs sinnvoll? Also wieviel die CPU tatsächlich arbeitet.......
Instructions retired oder uops retired sind ja schöne PerformanceWerte....... jedoch was sagen sie mir wie effizient zB mein programm arbeitet oder wie sinnvoll die ressourcen genutzt werden ohne sinnlose wartezeiten der CPU!
-
Nobuo T schrieb:
Also wenn ich das richtig verstanden habe, definiert hmmm2 "Auslastung" hier als (Delta_µOps)/(Max_µOps*Delta_TSC). Wenn er weiss, wie er an diese Werte kommen kann, spricht auch nichts dagegen, dass das irgendwas liefern koennte.
... Was das bringen soll ist dann noch eine andere Frage... Um tatsaechlich nutzbare Ressourcen der CPU zu bestimmen ist diese Methode IMHO eher unpraktisch.Wie kann ich den den FETT gedruckten teil sonst ermitteln?
-
camper schrieb:
sinnvoll ist etwa: der Anteil der Zeit, während der der Prozessor sich nicht in einem Halt- oder Schlafzustand befindet und ggf. nicht den Scheduler ausführt - das hat aber dann nichts direkt mit der Abarbeitung von Befehlen zu tun.
Letztendlich ist doch einzig wirklich wichtig, wie lange dein Code fuer eine Aufgabe insgesamt braucht. Was die CPU sonst intern dabei treibt ist bei solch einer Performancebetrachtung erstmal doch reichlich nebensaechlich, wenn du mich fragst.
-
Nobuo T schrieb:
camper schrieb:
sinnvoll ist etwa: der Anteil der Zeit, während der der Prozessor sich nicht in einem Halt- oder Schlafzustand befindet und ggf. nicht den Scheduler ausführt - das hat aber dann nichts direkt mit der Abarbeitung von Befehlen zu tun.
Letztendlich ist doch einzig wirklich wichtig, wie lange dein Code fuer eine Aufgabe insgesamt braucht. Was die CPU sonst intern dabei treibt ist bei solch einer Performancebetrachtung erstmal doch reichlich nebensaechlich, wenn du mich fragst.
Im Regelfall. Jedenfalls gibt es keine direkte Möglichkeit festzustellen, wie weit ein bestimmter Codeabschnitt von der optimalen Implementation entfernt ist (logisch: andernfalls wäre Optimierung ja auch trivial). Auch eine optimale Implementierung führt nie zu 100%er Auslastung aller Funktionseinheiten einer CPU. Ein klein wenig einschränken würde ich das Ganze dahingehend, dass von 2 Implementationen, die in der gleichen Zeit ausgeführt werden können, natürlich die vorzuziehen ist, die zu geringerer Auslastung der CPU führt. Einerseits spart das Strom, andererseits führt es (wenigstens tendenziell) zu einer geringeren Ausbremsung im Fall vom Hyperthreading (wobei man hier eigentlich immer alle Threads gleichzeitig betrachten muss). Abgesehen von der Zeit gibt es ja noch anderer Resourcen die begrenzt sind, insbesondere natürlich Speicherverbrauch etc. aber so etwas ist ja wiederum einfach zu bestimmen.
-
Natürlich läuft das ganze im Endeffekt auf die benötigte Zeit hinaus!
Jedoch wenn ich Code optimieren will bzw. bestimmte sachen untersuchen will und einige PerformanceWerte von der CPU dabei auslesen kann, kann ich auch herausfinden ob Codeumstellungen o.ä. sich auf erhöhte Performance auswirken!erhöhte Performance (mehrere Instr. pro Zyklus, mehr µops, weniger cache misses, usw.) -> führt ja beinahe unweigerlich zu erhöhter programmabarbeitung?
-
Das wuerde ich so generell nicht behaupten.
Und wozu ueberhaupt dieser riesen Aufwand - letztendlich ist fuer mich immer noch nicht plausibel, was du mit diesen ganzen Ueberlegungen ueberhaupt bezweckst.
Wie du selbst schreibsthmmmm22 schrieb:
Natürlich läuft das ganze im Endeffekt auf die benötigte Zeit hinaus!