Verhalten von Windows(XP) bei Multicore-Systemen

[BlackBirdSR]

Kann mir jemand auf die Sprünge helfen? Nehme auch gerne Dokumente und Artikel an.

Und zwar geht es darum, wie sich Windows verhält wenn mehrere CPUs/Kerne im System vorhanden sind.
Normalerweise würde ich erwarten, dass die Kerne verschiedene Aufgaben erledigen und zwar exklusiv. Also ein Kern erledigt meinetwegen das Spiel, der Andere erledigt was sonst noch anfällt.

Der Taskmanager und CPU-Auslastungsanzeigen stellen aber Anderes dar.
Egal welches Spiel/Programm, beide CPUs (X2) zeigen eine Auslastung von ca 40-60% an, während der Prozess als Solches auf 50% im Taskmanager steht.

Erst die Affinität auf einen Kern beschränkt, erzeugt 100% Last für diesen und nahezu Null beim Anderen. Wechselt Windows ständig zwischen den Kernen? Das würde doch zusätzlichen Performanceverlust erzeugen.
Oder spielt hier der Grafiktreiber mit?

Bin leider noch eine Null auf dem Gebiet von Microsoft und Multithreading.
Danke

[zeckensack]

Ich denke es wäre hilfreich wenn du sagst womit du getestet hast.
Wenn beide CPUs dauerhaft eine Grundlast anzeigen (Diagramme im Taskmanager, nehme ich an?) dann heißt das auch dass sie beide arbeiten. Entweder ist deine Applikation an sich schon signifikant multithreaded oder der Graka-Treiber hat einen Arbeitsthread auf der anderen CPU gestartet. Das machen NVIDIA- und ATI-Treibern nämlich seit ein paar Monaten.

Ich habe bei HyperThreading beobachtet dass XP SP2 einzelne Threads quasi zufällig und ohne erkennbaren Grund zwischen den beiden logischen Kernen hin- und herschiebt, und ja, ich halte das für kontraproduktiven Unsinn.

Allerdings ist da die vom Taskmanager angezeigte Summenlast immer 50%. Nie mehr. Bei dir schon, wenn ich dich richtig verstanden habe?

[Seraf]

Ist es nicht normal das der Scheduler die Tasks ständig zwischen den Kernen verschieben könnte? Selbst wenn ein Prozess alleine auf einem Kern läuft wird Windows irgendwann den Prozess unterbrechen (für ein paar ms/ns vielleicht). Wenn der Scheduler den Task wieder startet setzt er ihn dann auf einen anderen Kern fort, falls dort mehr Ressourcen zur Verfügung stehen.

Noch ein Gedanke. Falls noch andere Programme mit der selben Priorität läuft, sollte Windows wegen des Round Robin Verfahrens (Zeitscheibe) den Task immer mal kurzzeitig unterbrechen, damit sichergestellt ist das auch kleine Programme zum Zug kommen die ebenfalls auf dem einen Kern laufen könnten.

/edit
Korrigiert

[BlackBirdSR]

Ich denke es wäre hilfreich wenn du sagst womit du getestet hast.
Wenn beide CPUs dauerhaft eine Grundlast anzeigen (Diagramme im Taskmanager, nehme ich an?) dann heißt das auch dass sie beide arbeiten. Entweder ist deine Applikation an sich schon signifikant multithreaded oder der Graka-Treiber hat einen Arbeitsthread auf der anderen CPU gestartet. Das machen NVIDIA- und ATI-Treibern nämlich seit ein paar Monaten.

Ich habe bei HyperThreading beobachtet dass XP SP2 einzelne Threads quasi zufällig und ohne erkennbaren Grund zwischen den beiden logischen Kernen hin- und herschiebt, und ja, ich halte das für kontraproduktiven Unsinn.

Allerdings ist da die vom Taskmanager angezeigte Summenlast immer 50%. Nie mehr. Bei dir schon, wenn ich dich richtig verstanden habe?

Getestet habe ich mit Allem was mir so in die Finger gekommen ist.

Beispiel Prime95: Eine Instanz:
Der Taskmanager zeigt für den Prozess eine Auslastung von genau 50% an.
Ebenso bei Performance, die Verluafsgrafen zeigen aber sowohl hier als auch mit anderen Tools an, dass Kern 1 ca 70%, Kern 2 ca 30-40% Auslastung abbekommt. Im ständigen Zigzack, sinkt der eine, steigt der Andere.
Das sieht aus, als würde Windows den Thread ständig zwischen beiden Kernen hin und herschieben und entspräche damit dem Verhalten das du bei SMT beobachtet hast. (Sowohl bei Xp64 als auch XP)

Bei Spielen die garantiert single-threaded sind, ist es ähnlich. Hier könnte ja noch der Grafiktreiber hinzukommen. Aber stellt man die Affinität auf einen Kern, wird ja ausschließlich dieser mit 100% belastet.

@Seraf: klingt eigentlich logisch. Daran habe ich nicht gedacht.
Ich habe mal getestet: Setze ich den Prozess auf Realtime, dann wird nur ein Kern dauerhaft beansprucht. Unterhalb von Realtime wird weiter munter geswitcht.

Zwei Probleme: Eigentlich geht doch dabei Performance verloren, wenn ständig hin und her geschoben wird. Das passiert ja auch in Spielen und anderen Programmen.
Und was ist dann mit den Verlaufsgrafen die von manchen genutzt werden, um zu sehen ob ein Spiel MT nutzt oder nicht. Die wären dann verfälscht.

[zeckensack]

Ist es nicht normal das der Scheduler die Tasks ständig zwischen den Kernen verschieben könnte? Selbst wenn ein Prozess alleine auf einem Kern läuft wird Windows irgendwann den Prozess unterbrechen (für ein paar ms/ns vielleicht). Wenn der Scheduler den Task wieder startet setzt er ihn dann auf einen anderen Kern fort, falls dort mehr Ressourcen zur Verfügung stehen.Wenn nur ein Prozess "arbeitet" und alles andere nur "reagiert", dann ist es am effizientesten den arbeitenden Prozess nie zu unterbrechen. Für den Kleinkram steht ein komplett freier Kern zur Verfügung. Warum also ausgerechnet den arbeitenden Prozess unterbrechen, um zB ... äh ... Mauseingaben zu verarbeiten?
Noch ein Gedanke. Falls noch andere Programme mit der selben Priorität läuft, sollte Windows wegen des Round Robin Verfahrens (Zeitscheibe) den Task immer mal kurzzeitig unterbrechen, damit sichergestellt ist das auch kleine Programme zum Zug kommen die ebenfalls auf dem einen Kern laufen könnten.Dann ja. In dem Fall wäre es erstrebenswert wenn jeder arbeitende Thread seine eigene CPU bekommt. Erst wenn es mehr Arbeiter als CPUs gibt, muss gewechselt werden.

[Seraf]

Woher weiß der Scheduler das der Prozess "immer" (und nicht kurzzeitig) auf 100% läuft, und nicht unterbrochen werden muß?
Das unterbrechen dauert auch nicht ewig. Das macht Windows (und alle anderen multitasking fähigen Betriebssysteme) schon seit Jahren auf SingleCore Rechnern, "ohne" das man davon viel mit bekommt. Warum sollte es also auf MultiCore-Rechnern zu größeren Leistungsverlusten kommen?

Ohne CPU Affinität festzulegen wird man wohl keinen Rechenprozess dauerhaft "fest" an eine CPU binden können.

[zeckensack]

Woher weiß der Scheduler das der Prozess "immer" (und nicht kurzzeitig) auf 100% läuft, und nicht unterbrochen werden muß?Ganz simplistische "best fit"-Strategie.
Wenn man eine CPU sucht um einen aufwachenden Thread laufen zu lassen, nimmt man die freie CPU, falls vorhanden, und nur wenn gerade nichts mehr frei ist muss man Unterbrechungen einplanen.

Angenommen eine CPU von zweien hat Last, die andere nicht. Dann unterbricht man nicht diese Last, sondern nutzt die freie zweite CPU. Oder?
Dafür ist es nicht notwendig die "100% Last" erkennen zu können. Nur entweder Last, jetzt gerade im Moment, oder keine Last.
Das unterbrechen dauert auch nicht ewig. Das macht Windows (und alle anderen multitasking fähigen Betriebssysteme) schon seit Jahren auf SingleCore Rechnern, "ohne" das man davon viel mit bekommt.Ich glaube nicht ...
Es gibt genug Leute denen immer wieder hakeliges Verhalten auf Windows auffällt, wie zB Gedenkpausen wenn man mal eine CD einlegt oder sowas. Windows hat viele Scheduling-Probleme, und diese Probleme sind "by design" (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=124022).

Dazu noch ein Zusatz: Thread-Prioritäten können auf Windows nicht die Länge von Zeitscheiben beeinflussen.

[Seraf]

Dazu noch ein Zusatz: Thread-Prioritäten können auf Windows nicht die Länge von Zeitscheiben beeinflussen.

Ich hab gelehrt bekommen das bei Windows "jede" Prioritätsstufe eine eigene Zeitscheibe verwendet. Für Prozesse mit selber Priorität teilt Windows die Prozesszeit per Zeitscheibe auf. Bei Programmen mit verschiedenen Prioritäten gibts prioritätenbezogenes Scheduling.

Bei prioritätenbezogenem Scheduling sollten kleine schnelle Prozesse (Treiber, Kernel und Services z.B.), mit einer kurzen Prozesszeit, eine höhere Priorität haben als langsame große Programme, sonst bekommt man ein sehr unrund laufendes System.

Deshalb sollte ein großes Programm auf einem zweiten Kern auch unterbrechbar bleiben...

[Muh-sagt-die-Kuh]

Windows verwendet, wie eigentlich fast alle heutigen general-use Betriebsysteme, Multilevel Feedback Queues für das Scheduling. Gescheduled werden Threads, keine Prozesse. Es gibt für jede der 32 Prioritätsstufen (16 Realtime-Prio, 16 Standard) eine Warteschlange. Auf einer n-Prozessor Maschine werden dabei immer die n Threads mit den höchsten Prioritäten ausgeführt.

"Feedback" bedeutet bei Windows das kurzfristige Hochstufen der Threadpriorität, z.B. nach dem Warten auf I/O Geräte oder sonstige Ereignisse. Die Zeitscheiben sind fix, Standard ist 6 Zeiteinheiten auf einer Workstation Variante und 36 Zeiteinheiten auf einer Server-Variante von Windows. Die Länge einer Zeitscheibe ist immer konstant.

Was es dann noch bei SMP Kernels gibt ist "SoftProcessorAffinity" und "HardProcessorAffinity". SoftAffinity ist Standard, hier versucht der Kernel die Threads so gut wie möglich auf die verfügbaren CPUs zu verteilen. Wenn möglich wird nach einem Interrupt wieder die gleiche CPU zu verwendet, da der Cache hier voraussichtlich noch die nötigen Daten enthält. HardAffinity wird vom Benutzer bestimmt und lockt einen Prozess mit all seinen Threads auf eine oder mehrere bestimmte CPUs. SoftAffinity scheint aber noch einen Last-Ausgleichs Mechanismus zu beinhalten, der die CPUs gleichmässig auslasten möchte.

Die Frage ist halt, wie genau der Taskmanager die Last angibt....ich glaube z.B. nicht, dass der Thread bei jedem Clock-Interrupt oder einem anderen Interrupt auf die andere CPU geschoben wird.....der Leistungsverlust durch den Lastausgleiche dürfte, meiner Meinung nach, vernachlässigbar sein.

[Muh-sagt-die-Kuh]

Deshalb sollte ein großes Programm auf einem zweiten Kern auch unterbrechbar bleiben...Programme sind immer unterbrechbar, dafür sorgt der Timer-Interrupt.

[BlackBirdSR]

Ok, der leistungsverlust hält sich in Grenzen, die Sache ist normal für Windows.

Dann bleibt noch das Problem, dass Angaben über die Auslastung hinsichtlich Multithreading durch die Taskmanageranzeige für die Katz sind oder?

Wie erkennt man so etwas dann am besten? Und wie sieht die Sache prinzipiell bei einem MT-Titel aus?
Ich komme mir mit den Windowseigenen Boardmitteln ziemlich verarscht vor, zumal man sich zu dem Thema erstmal großflächig einlesen muss.

Ha da jemand was?

[Demirug]

Ich verstehe dein Problem nicht ganz. Der Taskmanager sagt dir doch das dein Spiel 50% der verfügbaren Prozessorleistung beansprucht. Was ein sicheres Zeichen für fehlende Multithread optimierung auf einer Dualcore Maschine its.

Wenn du es genauer brauchst musst du eben den Performance Monitor und nicht den Taskmanager nehmen. Der kann die CPU Zeit pro Thread aufzeichnen.

[BlackBirdSR]

Ich verstehe dein Problem nicht ganz. Der Taskmanager sagt dir doch das dein Spiel 50% der verfügbaren Prozessorleistung beansprucht. Was ein sicheres Zeichen für fehlende Multithread optimierung auf einer Dualcore Maschine its.

Wenn du es genauer brauchst musst du eben den Performance Monitor und nicht den Taskmanager nehmen. Der kann die CPU Zeit pro Thread aufzeichnen.

Es ging einfach darum, ob Performance verloren geht gegenüber der manuellen Einstellung der Affinität, und inwiefern der Taskmanager eingesetzt werden kann um Multithreading überhaupt nachzuweisen.
Viele zeigen Screenshots des Verlaufs der Auslastung und ziehen davon Rückschlüsse.

[HellHorse]

Ganz simplistische "best fit"-Strategie.
Wenn man eine CPU sucht um einen aufwachenden Thread laufen zu lassen, nimmt man die freie CPU, falls vorhanden, und nur wenn gerade nichts mehr frei ist muss man Unterbrechungen einplanen.
Mac OS X macht genau das (zumindest zeigt der Taskmanager oder wie das Ding heisst es genau so an).

[S3NS3]

Es ging einfach darum, ob Performance verloren geht gegenüber der manuellen Einstellung der Affinität, und inwiefern der Taskmanager eingesetzt werden kann um Multithreading überhaupt nachzuweisen.
Viele zeigen Screenshots des Verlaufs der Auslastung und ziehen davon Rückschlüsse.

Meiner Erfahrung nach ergibt das schon einen kleinen Performanceverlust. Aber der ist so gering das er völlig vernachlässigbar ist. Das festsetzen der Affinität auf CPU1 brachte glaube ich damals in HL2 127,4 FPS anstatt etwa 126,0FPS.

Habe bisher kein Tool gefunden mit dem man EINFACH und KOMPFORTABEL die Affinität von Programmen festlegen kann, daher lass ich grundsätzlich Windows machen was es will ;)

[registrierter Gast]

Angenommen eine CPU von zweien hat Last, die andere nicht. Dann unterbricht man nicht diese Last, sondern nutzt die freie zweite CPU. Oder?
Dafür ist es nicht notwendig die "100% Last" erkennen zu können. Nur entweder Last, jetzt gerade im Moment, oder keine Last.
Ich glaube nicht ...Kann man denn die Last des einen Kerns von einem anderen Kern aus bestimmen? :confused: Dachte diese Angabe kann man nur mit Hilfe des Kerns selbst machen. Wofür die gerade anstehende Arbeit natürlich unterbrochen werden müsste. :|

[stickedy]

Das Thema "EasyToolz" und damit zusammenhängende Beiträge finden sich nun hier: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=317643

[StefanV]

Hm. hab gestern mal ein 2 CPU System benutzt, auch garnicht so langsam/schlecht.
Ok, 512MB PC-400 RAM sind etwas wenig, da sollt ich noch die anderen beiden dazu kloppen...

Aber ansonsten konnt ich keinen Unterschied zu einem Single Core bemerken, irgendwie :|

[The_Invisible]

Hm. hab gestern mal ein 2 CPU System benutzt, auch garnicht so langsam/schlecht.
Ok, 512MB PC-400 RAM sind etwas wenig, da sollt ich noch die anderen beiden dazu kloppen...

Aber ansonsten konnt ich keinen Unterschied zu einem Single Core bemerken, irgendwie :|

für normales office ja auch overkill...

wennst aber so sachen machst wie eine cd brennen, im hintergrund derweil dateien en/dekodieren für die nächste cd und gleichzeitig ein bild bearbeitest oder was kompilierst sind 2 kerne sehr dankbar. da bei mir öfters sowas anfällt kann ich jedem nur mehr 2 kerne cpus empfehlen.

mfg

[BlackBirdSR]

Hm. hab gestern mal ein 2 CPU System benutzt, auch garnicht so langsam/schlecht.
Ok, 512MB PC-400 RAM sind etwas wenig, da sollt ich noch die anderen beiden dazu kloppen...

Aber ansonsten konnt ich keinen Unterschied zu einem Single Core bemerken, irgendwie :|

Merkst du ohne schwere Workloads auch nur in Situationen wo Windows z.B spinnt. Es wird ja sowieso ständig zwischen den Kernen und Prozessen hin und hergewechselt.

Netter nebeneffekt, gerade die K8 kommen somit selten auf die maximale Taktrate. Sie wechseln sich ab und bleiben je nach Einstellung 1-2 Powerstates darunter.

[Gast]

Das versteh ich jetzt nicht. Wenn das Program dauernd zwischen den zwei Kernen hin- und hergeschoben wird und das OS dann deshalb nicht mehr auf vollen Takt schaltet würde das eine Single-Thread-Applikation ja ziemlich einbremsen.

[StefanV]

Merkst du ohne schwere Workloads auch nur in Situationen wo Windows z.B spinnt. Es wird ja sowieso ständig zwischen den Kernen und Prozessen hin und hergewechselt.
Auch da hab ich nichts gemerkt...
Entweder war die Festplatte blockiert (IDE halt...) oder aber irgendwas anderes...
Auf 'nen Test mit SCSI hab ich gerad kein bock...

[Grestorn]

Das versteh ich jetzt nicht. Wenn das Program dauernd zwischen den zwei Kernen hin- und hergeschoben wird und das OS dann deshalb nicht mehr auf vollen Takt schaltet würde das eine Single-Thread-Applikation ja ziemlich einbremsen.

Da der Cache ja jetzt auch gemeinsam genutzt wird, wird nichts mehr von dem einen Core auf den anderen Core "verschoben". Es ist vollkommen egal, welcher Core die nächste Zeitscheibe für einen Thread ausführt.

Ein Wechsel von einem Core auf den anderen kostet - wenn ohnehin ein Kontextwechsel stattfindet - nichts extra.

[HellHorse]

Da der Cache ja jetzt auch gemeinsam genutzt wird, wird nichts mehr von dem einen Core auf den anderen Core "verschoben".
Gilt das auch für L1 oder nur L2?

[Grestorn]

Gilt das auch für L1 oder nur L2?

Ich denke nur der L2 Cache. Aber der L1 Cache ist so klein, dass er nach einem Kontextwechsel ohnehin keine Rolle mehr spielen dürfte.

[dexus]

Ich denke nur der L2 Cache. Aber der L1 Cache ist so klein, dass er nach einem Kontextwechsel ohnehin keine Rolle mehr spielen dürfte.
Wie Du schon schreibst gilt das mit dem gemeinsamen L2 nur für Intels Core Duo CPUs.
Dieses CPU-Wechselspiel macht XP auch bei "richtigen" zwei CPU Maschinen
(Xeons oder Dual SingelCore Opterons)
Da ist der Performanceverlust schon messbar (wenn auch nicht spürbar).
Das macht Windows aber schon seit NT 4.0 Zeiten.
Ich erinnere mich noch dass der OpenGL Bildschirmschoner auf einem P133 flüssig lief und auf einem Dual P200 total ruckelte weil ständig der Task von einem auf den anderen Prozessor verschoben wurde. ;D

dexus

[zeckensack]

Ich denke nur der L2 Cache.Bei AMD nicht.Aber der L1 Cache ist so klein, dass er nach einem Kontextwechsel ohnehin keine Rolle mehr spielen dürfte.Bei AMD nicht.
:usweet:

[ShadowXX]

Bei AMD nicht.
:usweet:
Intel hat beim Conroe den L1-Cache aber inzwischen auch ein ganzes Stück vergrößert (32+32).

Kommt zwar noch nicht an den A64 ran, aber gegen die P4s ist das auch fast das doppelte.

[Gast]

Ich denke nur der L2 Cache. Aber der L1 Cache ist so klein, dass er nach einem Kontextwechsel ohnehin keine Rolle mehr spielen dürfte.

spätestens für die quad-cores gilt das aber auch nicht mehr ;)

[Gast]

Intel hat beim Conroe den L1-Cache aber inzwischen auch ein ganzes Stück vergrößert (32+32).

Kommt zwar noch nicht an den A64 ran, aber gegen die P4s ist das auch fast das doppelte.

Bei Cache ist die Größe auch nur das eine. Die Assoziativität ist genauso wichtig.

[Gast]

Ich erinnere mich noch dass der OpenGL Bildschirmschoner auf einem P133 flüssig lief und auf einem Dual P200 total ruckelte weil ständig der Task von einem auf den anderen Prozessor verschoben wurde. ;D

Das lag ganz sicher nicht daran. Wahrscheinlich hat der Müll RDTSC als Zeitmessung verwendet.

[PatkIllA]

Wobei nen Dual P200 eh nicht der Bringer war. Ohne L2 Cache auf dem Die war das nicht optimal.
Auch die Celerons nachher waren in Dual Konfiguration deutlich langsamer als zwei gleichgetaktete Pentiums 3.
Und ich kann mich auch daran erinnern, dass es bei zwei rechenintensiven schneller war jede Anwendung einem Prozessor zuzuweisen. Das war aber unterer einstelliger Prozentbereich.

[StefanV]

Dazu muss auch gesagt werden, das der Cacheabgleich übern Bus muss, was nicht so prickelnd ist und auch Intel immer noch einige Probleme bereitet, da AMD seit dem K7 seperate Leitungen für L2 Cache Abgleich hat, was also nicht über den FSB muss...

PS: die Selleries hatten aber auch nur 66MHz FSB...