Archiv verlassen und diese Seite im Standarddesign anzeigen : Auslastung neuer Multi-Kerne ausgeglichener?
Hallo,
ich habe noch einen älteren DC Prozessor.
Nun ist mir in letzter Zeit aufgefallen, dass die Auslastung bei den neuen Multicore-Systemen auf alle Kerne gleichmäßiger verläuft.
Ein Kumpel hat ein i5. Dabei habe ich mehrere Programme ausprobiert.
Während bei meinem älteren DC meist ein Kern alleine ausgelastet wird, sind bei ihm die 4-Kerne gleichmäßiger ausgelastet, also ein Kern alleine nicht.
Das ist mir auch bei Programmen aufgefallen, die eher für Singelcore als Multicore programmiert worden sind.
Ich werde demnächst noch mal zu ihm hingehen und weitere Tests machen.
Welche Erfahrungen habt ihr mit den neuen Multicores gemacht?
könnte daran liegen das zumindest beim i5 die cores je nach auslastung unterschiedlich takten (-> Stromsparmechanismen)
PatkIllA
2010-02-03, 10:15:37
ob du jetzt einen Kern mit 100% oder vier mit 25% Auslastung hast ist Sache des Betriebssystems und nicht des Prozessors. Der Prozessor kann da bestenfalls noch ein paar Hinweise geben.
Der HeinZ
2010-02-03, 10:23:04
Oh, welche Programme hat er denn benutzt, das ist eine sehr wage Aussage.
Was bedeutet ausgeglichen, Task Manager beide 50 %? Das wäre grade bei den IX-Cores von Intel doch sehr sinnfrei, aufgrund des Turbo Modus.
Welches Betriebssystem wurde benutzt, WIN7 ist zum Beispiel "intelligenter" als XP, was die Belegung der Cores betrifft.
Allerdings kann ich dazu nicht viel sagen, ich habe kein WIN7.
Teste mal Video-Codierung zumindest mit einem X.264, divx reicht meist auch aus für Dualcores, da stehen beide auf 100 %. Desweiteren ist der Taskmanager eh eine kleiner Lügen bold. wenn da 100 % steht gibt es meistens noch reserven. Und beim Turbo Modus, wo der Prozzi dynamisch rauf und runter taktet, steht da dann eh nur Käse.
Und wenn dein Prozessor alleine zu 50 Prozent ausgelastet wird, dann wahrscheinlich weil es eine Singelthread-Anwendung ist und der Scheduler dann einfach auf beiden Kernen hin als auch her schiebt.
Da ist es sogar sinnvoll nur einen Core zu nutzen, sonst erzeugt der Scheduler von Windows nämlich Leistungseinbussen, da er munter hin und her schiebt, obwohl es unnötig ist.
Die Frage ist eigentlich viel zu pauschal. Es gibt da viel zuviele Software als auch Hardware technische Dinge, welche dieses "Ausgeglichen" beeinflussen.
Ich behaupte die Quadkerne reagieren da alle gleich, ob alt oder neu.
Ich weiß worauf du hinauswillst, aber ohne angabe der getesteten Programme ist das schon recht sinnfrei.
Denn das Fazit bleibt immer das gleiche, Singelthread bleibt immer (in etwa)bei der gleichen Leistung, wenn Quad, Tripple als auch Dualcore oder sogar Singelcore den selben Kern benutzen und gleiche Taktrate vorhanden ist (Z.B. Phenom Reihe), Multithread, durch welches die Last auf alle Kerne verteilt werden kann, steigert die Leistung in etwa um die Anzahl der Kerne.
(Verwaltungsaufwand verhindert die volle skalierung) Sehr schön zu sehen z.b. am Cinebench.
Gruß Matthias
Es geht um die verteilte Auslastung aller Kerne.
Ein Vergleich:
Ich benutze ein Programm, dass eher für Single-Core geschrieben ist.
Die Gesamtauslastung liegt auf einem älteren DC bei 50%, also ein Kern ist zu 100% ausgelastet, der andere kaum.
Das gleiche Programm lastet bei einem i5 alle 4 Kerne mit 100% aus. Ob er mit dem Takt runter geht, muss ich schauen.
Beide Systeme sind identisch und vom gleichen Hersteller (Intel).
@Heinz
Ich werde zu ihm (diese Woche) mit meinem DC-Notebook hingehen und gleiche Programme auf beide Systeme zeitgleich laufen lassen.
Es geht mir nicht um Leistung direkt, sondern um die gleichmäßige Auslastung aller Cores.
Es geht um die verteilte Auslastung aller Kerne.
Ein Vergleich:
Ich benutze ein Programm, dass eher für Single-Core geschrieben ist.
Die Gesamtauslastung liegt auf einem älteren DC bei 50%, also ein Kern ist zu 100% ausgelastet, der andere kaum.
Das gleiche Programm lastet bei einem i5 alle 4 Kerne mit 100% aus. Ob er mit dem Takt runter geht, muss ich schauen.
Beide Systeme sind identisch und vom gleichen Hersteller (Intel).
hwinfo32 zeigt mir bei meinem i5 ständig unterschiedliche multis für die cores an wenn nicht 4 cores komplett ausgelastet werden würden
im normalen desktopbetrieb geht der multi bis 9x runter (auf allen cores) und wenn eine singlecore anwendung gestartet wird geht nur der multi von einem core erstmal hoch (bis zu 24x) d.h. 3 cores bleiben zeitweise auf 1656Mhz und der 4. geht auf 4416Mhz
komischerweise verhält sich da aber prime mit 1 thread anders
hier wird im taskmanager 1 core komplett ausgelastet und die anderen gar nicht, aber alle cores laufen auf gleichem takt
Windows 7 kann effizienter mit Multicore umgehen als Vista oder XP.
Falls Kumpel also 7 hat und Du noch XP oder Vista, könnte das eine Erklärung sein.
Oder ein Teil der Erklärung...
Der HeinZ
2010-02-03, 11:38:51
Es geht um die verteilte Auslastung aller Kerne.
Ein Vergleich:
Ich benutze ein Programm, dass eher für Single-Core geschrieben ist.
Die Gesamtauslastung liegt auf einem älteren DC bei 50%, also ein Kern ist zu 100% ausgelastet, der andere kaum.
Das gleiche Programm lastet bei einem i5 alle 4 Kerne mit 100% aus. Ob er mit dem Takt runter geht, muss ich schauen.
Beide Systeme sind identisch und vom gleichen Hersteller (Intel).
Davon, das der Takt runter geht, gehe ich jetzt erstmal aus, denn ein Singelthread kann einen Multicore nicht 100 Prozent auslasten. Prüfe das mal nach!
Und wie gesagt das Betriebssystem hat auch einen (gewissen) Anteil.
Singelthread sollte WIN7 auf einen einizigen Kern schieben und da auch belassen, so die theorie im Groben, WINXP schiebt normalerweise mehr nach eigenem ermessen.(Lust und Laune :) ) Im Endergebniss müßte dann Win7 flotter sein, was aber wahrscheinlich schon in den Bereich der Messungenauigkeit fallen könnte.
...
Die Gesamtauslastung liegt auf einem älteren DC bei 50%, also ein Kern ist zu 100% ausgelastet, der andere kaum.
Das gleiche Programm lastet bei einem i5 alle 4 Kerne mit 100% aus. Ob er mit dem Takt runter geht, muss ich schauen.
Ich finde das extrem unlogisch und auch unwahrscheinlich. Wozu soll bei einer Anwendung die single Threaded ist, eine Verteilung auf alle Kerne erfolgen? Wenn sonst kein anderer Prozess die CPU beansprucht, wozu sollte der OS-Scheduler die Ausführung auf einem anderen Kern fortführen? Und wieso werden alle 4 Kerne zu 100% ausgelastet? Sie sollten wenigstens bei 25% stehen. Alles andere wäre total sinnbefreit und ineffizient. Aber vielleicht kann ja jemand hier im Forum diesen Voodoo-Zauber erklären.
Es geht um die verteilte Auslastung aller Kerne.
Ein Vergleich:
Ich benutze ein Programm, dass eher für Single-Core geschrieben ist.
Die Gesamtauslastung liegt auf einem älteren DC bei 50%, also ein Kern ist zu 100% ausgelastet, der andere kaum.
Das gleiche Programm lastet bei einem i5 alle 4 Kerne mit 100% aus. Ob er mit dem Takt runter geht, muss ich schauen.
Beide Systeme sind identisch und vom gleichen Hersteller (Intel).
Jaja, schon klar...
Doch für jene Verteilung ist ausschließlich der Thread-Scheduler des Betriebssystems verantwortlich. Egal ob Pentium-Dual Core oder Core i7.
Windows 7 soll derzeit allerdings den Besten unter Windows bieten.
Ich selbst hab 'nen E8500 unter XP x64 und bin mit der Lastenverteilung
eigentlich ganz zufrieden.
Der HeinZ
2010-02-03, 12:00:03
Ich finde das extrem unlogisch und auch unwahrscheinlich. Wozu soll bei einer Anwendung die single Threaded ist, eine Verteilung auf alle Kerne erfolgen? Wenn sonst kein anderer Prozess die CPU beansprucht, wozu sollte der OS-Scheduler die Ausführung auf einem anderen Kern fortführen? Und wieso werden alle 4 Kerne zu 100% ausgelastet? Sie sollten wenigstens bei 25% stehen. Alles andere wäre total sinnbefreit und ineffizient. Aber vielleicht kann ja jemand hier im Forum diesen Voodoo-Zauber erklären.
Das passiert in der Praxis schon sehr oft, dass ein Singelthread Programm alle Kerne "benutzt" und der Scheduler schiebt. Die gesamt auslastung ohne Stromsparen steht dann trotzdem so oder so auf 25 % in der Gesamtsumme aller Kerne.
Erklärung dafür würde ich mal so sehen, das das Programm verschiede Prozesse oder abfolgen (ich bin in den Bezeichnungen wirklich kein pro) startet, die in abhänigkeit von einander stehen, aber nicht parallel ausgeführt werden, da kein mulithread und der Scheduler einfach bei jeder Ausführung einen anderen Kern anspricht, das sollte Win7 nicht machen, aber der nutzen darin ist auch eher gering.
100 % halte ich auch für recht unwahrscheinlich, das würde zwar möglich sein, aber doch sehr viel intelligenz voraussetzen (gleichmäßiges verteilen einer Anwendung auf alle Cores inkl. nutzen der Stromspartaktung). Hier stand unlogischer Quatsch, den erst ein Kaffee aufdeckte!
Aber dieses ganze Thema wird eigentlich zu nix führen, außer man will ein bißchen auf der Turbo Modus von den neuen Intels oder der Taktsenkung bei Stromsparmodi und damit auf den Stromverbruach eingehen. Für alles andere eigentlich Irrelevant.
Es geht mir nicht um Singlethread. Es sollte klar sein, dass dies nicht auf alle Kerne verteilt werden kann.
Es geht mir eher um Programme, die nicht explizit für Multicore ausgelegt sind.
Es erscheint mir, dass solche Programme auf neuen Multicore besser verteilt werden.
Ich müsste dies mal genauer überprüfen.
PS: Beide Systeme sind mit Vista ausgestattet. W7 ist vom Kumpel bestellt, wird demnächst kommen.
Das passiert in der Praxis schon sehr oft, dass ein Singelthread Programm alle Kerne "benutzt" und der Scheduler schiebt.
Ist ja nicht so, dass es nicht möglich wäre, aber wozu sollte der Scheduler die Ausführung auf einen anderen Kern moven? Was passiert mit den Cache-Lines? Das Moven auf einen anderen Kern müßte ziemlich teuer sein. Wenn der Scheduler beispielsweise "sieht", dass momentan kein anderer Thread läuft, bzw. eine geringere Prio oder sonst was hat, dann sollte auch kein Context-Switch stattfinden, gerade weil dieser teuer ist. Im Prinzip ist das Moven auf einen anderen Kern quasi wie ein Context-Switch. Ich kann mich natürlich auch irren, aber erklären konnte bisher niemand so richtig diesen "mysteriösen" Umstand, warum bei W7 die Ausführung durch den Scheduler auf die einzelnen Kerne, bei einer Single-Threaded Anwendung, verteilt wird.
Ist ja nicht so, dass es nicht möglich wäre, aber wozu sollte der Scheduler die Ausführung auf einen anderen Kern moven? Was passiert mit den Cache-Lines? Das Moven auf einen anderen Kern müßte ziemlich teuer sein. Wenn der Scheduler beispielsweise "sieht", dass momentan kein anderer Thread läuft, bzw. eine geringere Prio oder sonst was hat, dann sollte auch kein Context-Switch stattfinden, gerade weil dieser teuer ist. Im Prinzip ist das Moven auf einen anderen Kern quasi wie ein Context-Switch. Ich kann mich natürlich auch irren, aber erklären konnte bisher niemand so richtig diesen "mysteriösen" Umstand, warum bei W7 die Ausführung durch den Scheduler auf die einzelnen Kerne, bei einer Single-Threaded Anwendung, verteilt wird.
Sehe ich auch so. Es ist doch vom Selbstverwaltungsaufwand her absolut nicht sinnvoll, die Ausführung permanent gleichmäßig auf die weiteren Kerne zu verteilen - zumindest so lange nicht, wie ein einzelner Kern noch Rechenkapazitäten zu Bewältigung frei hat. Das kostet ansonsten nämlich Ressourcen und Zeit.
Es geht mir nicht um Singlethread. Es sollte klar sein, dass dies nicht auf alle Kerne verteilt werden kann.
Es geht mir eher um Programme, die nicht explizit für Multicore ausgelegt sind.
Es erscheint mir, dass solche Programme auf neuen Multicore besser verteilt werden.
Was redest du da eigentlich? Ohne dir jetzt nahe treten zu wollen, aber wie schafft man es drei Sätze zu schreiben, die sich wie ein Widerspruch anhören und gleichzeitig doch auf die selbe Sache hinauslaufen? Es geht dir nicht um Single Threaded, aber Programme die nicht explizit für Multicore ausgelegt werden? Wer soll denn das verstehen? Entweder du hast ein Programm so geschrieben, dass es auf mehreren Cores läuft oder du hast es so geschrieben, dass nur auf einem Core läuft. Eine andere Unterscheidung gibt es nicht und das OS kann dir dabei auch nicht helfen und wird es wahrscheinlich auch niemals können.
Was soll also bitteschön ein Programm sein, dass "nicht explizit" auf Multicore ausgelegt ist. Aus meiner Sicht ist das immer noch ein Single Threaded Programm, also das, was in deinem ersten Satz steht.
Drück dich bitte etwas klarer aus.
Was redest du da eigentlich? Ohne dir jetzt nahe treten zu wollen, aber wie schafft man es drei Sätze zu schreiben, die sich wie ein Widerspruch anhören und gleichzeitig doch auf die selbe Sache hinauslaufen? Es geht dir nicht um Single Threaded, aber Programme die nicht explizit für Multicore ausgelegt werden? Wer soll denn das verstehen?
Von der Programmierung her bzw. Aufwand ist es möglich:
1. Singlethreaded
2. Multithreaded (meist nur auf 1 Kern/CPU ablaufend)
3. Multicore (auf mehrere Kerne bzw. CPUs verteilt)
Von Schritt 2 auf Schritt 3 war vor vielen Jahren mal sehr aufwendig auf mehrere CPUs zu verteilen (v.a. Windows)
Dann war vor paar Jahren genauso aufwendig Programme auf einem DualCore-CPU richtig aus zu lasten.
PS: Hast Du mal programmiert?
PatkIllA
2010-02-03, 14:50:04
Von der Programmierung her bzw. Aufwand ist es möglich:
1. Singlethreaded
2. Multithreaded (meist nur auf 1 Kern/CPU ablaufend)
3. Multicore (auf mehrere Kerne bzw. CPUs verteilt)
Von Schritt 2 auf Schritt 3 war vor vielen Jahren mal sehr aufwendig auf mehrere CPUs zu verteilen (v.a. Windows)
Dann war vor paar Jahren genauso aufwendig Programme auf einem DualCore-CPU richtig aus zu lasten.
PS: Hast Du mal programmiert?
Wirklich singlethreaded ist praktisch keine größere Anwendung. Meist laufen die rechenintensiven Sachen halt in einem Thread und ein Multicore bringt für das eine Programm fast nichts. Die Threads verteilen sich auch automatisch auf die Cores.
Und warum soll das in Windows gerade so schwer gewesen sein?
Wirklich singlethreaded ist praktisch keine größere Anwendung. Meist laufen die rechenintensiven Sachen halt in einem Thread und ein Multicore bringt für das eine Programm fast nichts. Die Threads verteilen sich auch automatisch auf die Cores.
Und warum soll das in Windows gerade so schwer gewesen sein?
Der Gast oben meint das sicherlich so, dass zwar eine Anwendung multithreaded sein kann, aber letztendlich nicht für Multicore optimiert ist. Das gibt es tatsächlich oft und zwar überall da, wo man z.B. asynchrone Methoden verwendet, um z.B. die GUI reaktionsfähig zu lassen oder um mal in der kurzen Zwischenzeit irgendetwas anderes zu machen und dann anschließend die Threads wieder synchronisiert, um das Ergebnis zu verwenden.
Aber solche Programme brauchen i.d.R. auch gar nicht alle Kerne. Denn Programme mit Multicoreoptimierung, die tatsächlich absolute Leistung brauchen, gibt es ja auch schon seit Ewigkeiten.
PS: Hast Du mal programmiert?
Wenn 16 Jahre Erfahrung im Profibereich dir nicht genügen (und ja auch diverse Multithreaded Anwendungen, bzw. Aufteilung einer Aufgabe auf mehrere Threads, wenn man es richtig spezifizieren will), dann weiss ich auch nicht.
Von Schritt 2 auf Schritt 3 war vor vielen Jahren mal sehr aufwendig auf mehrere CPUs zu verteilen (v.a. Windows)
Autsch, mir wird echt übel, wenn ich Leute wie dich höre. Unterstellen anderen Inkompetenz, beweisen aber gleichzeitig, dass sie selbst von nichts eine Ahnung haben. Vorallem auf Windows war es nie notwendig Aufgaben auf mehrere CPU's zu verteilen, weil Windows einzelne Threads schon immer selbst auf die einzelnen Cores verteilt hat.
Meine Güte, was hier einige für einen Müll schreiben. Ich glaube das Internet mach doch blöd.
Aber ich will hier ja nicht nur rumätzen.
Also, was ist die Grundvoraussetzung für Multithreading/Multicore-Support?
Multithreading:
Man kann diverse Aufgaben parallel Ausführen, die nicht in einem direkten Zusammenhang stehen. Das haben hier ja einige Gäste schon richtig geschrieben. Windows hat solche Threads, liefen sie denn in einem gleichen Zeitfenster ab, schon immer auf mehrere Kerne verteilt. Was hat das jetzt mit der Fragestellung: "Auslastung neuer Multi-Kerne ausgeglichener" zu tun?
Antwort: Die Frage ist obsolet, weil Windows das schon immer ausgeglichen hat. Bzw., was ist die Steigerung von "ausgeglichen"?
Multicore-Support:
Stellt man fest, dass man einen Algorithmus parallelisieren kann, so kann man diesen in mehrere Threads aufteilen, wobei die Anzahl der Threads der Anzahl der Kerne entsprechen sollte. Hätte man mehr Threads als Anzahl der Kerne, wäre das kontraproduktiv. Was muss man jetzt unter Windows spezielles machen? Nichts, man started einfach, genau wie bei Multithreading, die Anzahl der gewünschten Threads. Den Rest erledigt Windows.
Und nun kann sich glaube ich jeder selbst vorstellen, was mit der Frage des Thread-Starters anzufangen ist.
(del)
2010-02-03, 15:44:05
Windows 7 kann effizienter mit Multicore umgehen als Vista oder XP.Ah? Es gibt, sei es realitätsfremde synthetische Benchmarks, 32bit Programme die auf dem gleichen Rechner unter Win7 schneller arbeiten als unter XPsp3?
Oder was meinst du mit "effizienter"?
PatkIllA
2010-02-03, 16:08:11
Windows 7 respektiert so Sachen wie TurboMode und Abschalten/Heruntertakten einzelner Kerne und schiebt nicht mehr so oft zwischen den Cores hin und her, um ständiges Umtakten und Aufwahen/Schlafenlegen der Kerne zu verhindern.
Zusammen mit Hyperthreading kommt es angeblich auch nicht mehr zu Leistungsinbußen wie teilweise bei XP/Vista.
Windows 7 respektiert so Sachen wie TurboMode und Abschalten/Heruntertakten einzelner Kerne und schiebt nicht mehr so oft zwischen den Cores hin und her, um ständiges Umtakten und Aufwahen/Schlafenlegen der Kerne zu verhindern.
Zusammen mit Hyperthreading kommt es angeblich auch nicht mehr zu Leistungsinbußen wie teilweise bei XP/Vista.
Genau, diese Aussage hat Sinn. Ich frage mich nur, wieso der Threadstarter genau das Gegenteil beobachtet haben will? Allerdings traue ich ihm auch nicht. (Dazu muss man den Thread komplett lesen ;))
Der HeinZ
2010-02-03, 21:01:32
Was redest du da eigentlich? Ohne dir jetzt nahe treten zu wollen, aber wie schafft man es drei Sätze zu schreiben, die sich wie ein Widerspruch anhören und gleichzeitig doch auf die selbe Sache hinauslaufen? Es geht dir nicht um Single Threaded, aber Programme die nicht explizit für Multicore ausgelegt werden? Wer soll denn das verstehen? Entweder du hast ein Programm so geschrieben, dass es auf mehreren Cores läuft oder du hast es so geschrieben, dass nur auf einem Core läuft. Eine andere Unterscheidung gibt es nicht und das OS kann dir dabei auch nicht helfen und wird es wahrscheinlich auch niemals können.
Was soll also bitteschön ein Programm sein, dass "nicht explizit" auf Multicore ausgelegt ist. Aus meiner Sicht ist das immer noch ein Single Threaded Programm, also das, was in deinem ersten Satz steht.
Drück dich bitte etwas klarer aus.
Haha!! Genau das wollt ich auch schreiben... Aber da ist mir die Arbeit dazwischen gekommen. Ja die Ausdrucksweise ist recht kompliziert, man versteht leider nicht genau was der TS genau möchte.
Edit:Nochmal auf die Anspielung mit dem Scheduler... ich hab ihn leider nicht erfunden, ich beobachte aber und ich sehe das da nicht konstant auf einen Kern bei älteren Anwendungen, welche nicht für Dualcores oder auch Quadcores, verteilt wird. Frage mich natürlich auch warum, aber ich kenne die Erklärung leider nicht. Wer hat Sie? Und wieso ist das jetzt bei WIN 7 anders?
Windows 7 respektiert so Sachen wie TurboMode und Abschalten/Heruntertakten einzelner Kerne und schiebt nicht mehr so oft zwischen den Cores hin und her, um ständiges Umtakten und Aufwahen/Schlafenlegen der Kerne zu verhindern.
Zusammen mit Hyperthreading kommt es angeblich auch nicht mehr zu Leistungsinbußen wie teilweise bei XP/Vista.
Das ist die vernünftigste Erklärung, neben dem, was manche gesagt haben.
So wie es ausschaut, werden unter Vista die Threads mehr auf die einzelnen Cores verteilt.
Demnächst werde ich auf W7 (legal) umsteigen. Mal sehen, wie es dort ausschaut.
(del)
2010-02-03, 22:01:07
Windows 7 respektiert so Sachen wie TurboMode und Abschalten/Heruntertakten einzelner Kerne und schiebt nicht mehr so oft zwischen den Cores hin und her, um ständiges Umtakten und Aufwahen/Schlafenlegen der Kerne zu verhindern.
Zusammen mit Hyperthreading kommt es angeblich auch nicht mehr zu Leistungsinbußen wie teilweise bei XP/Vista.Ich kenne die Werbebroschüren, aber die waren in meinem Beitrag nicht gemeint.
Eigentlich verstehe ich erstmal nicht was an meinem Beitrag unverständlich war...
backfisch
2010-02-03, 22:07:37
Windows 7 respektiert so Sachen wie TurboMode und Abschalten/Heruntertakten einzelner Kerne und schiebt nicht mehr so oft zwischen den Cores hin und her, um ständiges Umtakten und Aufwahen/Schlafenlegen der Kerne zu verhindern.
Zusammen mit Hyperthreading kommt es angeblich auch nicht mehr zu Leistungsinbußen wie teilweise bei XP/Vista.Ich hab vor ein paar Tagen mal mit Prime95 rumgespielt weil mich das interessierte. Bei Windows XP x64 fand ich es immer unsinng, dass Prime95 mit einem Thread immer über die Cores "hüpft" bzw. mehrere Kerne nutzt. Der Phenom 2 sollte die Kerne ja auch unabhängig voneinader takten können und ich wollte mal sehen ob dies denn unter Windows 7 funktioniert. Allerdings "verteilt" auch Win7 den Prozess auf alle vier Kerne. Will heißen: Ich habe bei einem Thread nicht einen Kern bei 100% Auslastung und 3GHz sondern vier Kerne bei +/- 25% Auslastung und dabei alle Kerne bei 3GHz. :confused:
PatkIllA
2010-02-03, 22:11:35
Mir kam es schon so vor als ob win7 dass etwas weniger macht.
Muss das noch mal in Ruhe schauen. Wobei meine CPU sich auch nur gesamt hoch und runterschalten kann.
backfisch
2010-02-03, 22:23:58
Ich werd's morgen noch mal testen, hab hier nur meinen Laptop.
Gewundert hat mich das Verhalten allerdings schon, grade weil immer verkündet wurde, dass Windows 7 sich da besser verhalten würde. Aber vielleicht ist das ja von der Leistung her auch kein Nachteil und ist nur für die Stromsparmechanismen problematisch. Wobei ich es als Laie für Sinnvoller halten würde, wenn sich ein Thread auf einen Kern beschränkt. Um das zu beurteilen, habe ich von der Materie aber viel zu wenig Ahnung. :D
PatkIllA
2010-02-03, 22:26:22
Wobei ich gerade beim Googlen noch gefunden habe, dass man core Parking wohl noch extra aktivieren muss.
y33H@
2010-02-03, 22:38:47
What?! SMT & Core Parking sind immer aktiv imho.
Ich habe noch kein W7. (demnächst)
Bei Vista werden die Threads verteilt. Egal ob nun 1 Thread oder 4 Threads.
Ich hatte den Eindruck, dass bei i5 die Threadverteilung stärker ausgeprägt als bei meinem älteren DC-Prozessor ist.
Habe es gestern Abend noch einmal ausprobiert. Bei i5 scheint es ähnlich betroffen zu sein.
Nur mit dem Unterschied, dass beim i5 die Takteinstellungen Core-Unabhängiger sind und beim alten DC die Cores die gleiche Frequenzen haben.
Dabei ist die Auslastung-Kurve vom Taskmanager nicht mehr zuverlässig.
Gibt es eine andere Möglichkeit, um Auslastung und Taktfrequenz aller Cores gemeinsam anzuzeigen?
Bei Windows Server R2 bzw. W7 ist Core Parking aktiv:
http://blogs.technet.com/mattmcspirit/archive/2009/05/07/seeing-core-parking-in-action.aspx
(Unter W7/W2008R2 + Resourcenmonitor sichtbar)
Mal ne Frage dazu:
Ist Core-Parking auch für alle (auch ältere DC) Prozessoren gültig?
Um Core-Parking unter W7 zu deaktivieren: (gefunden, keine Gewähr)
http://forum.cakewalk.com/tm.aspx?m=1861804
In short, here is the better method from sky60234:-
- Go to Regedit
- Find this key:- " 0cc5b647-c1df-4637-891a-dec35c318583 "
- Within this key, there is a value called: " ValueMax "
- This value represents the % number of cores the system will park - the default 100% ie: all Cores are potentially park-able
- Change the value from 64 to 0 so the " ValueMin " and " ValueMax " are both zero
- You will have to find the key a few times and repeat the process for each time it is found - the number of instances will depend on the number of power profiles in your system [ in my DAW it was only found twice ]
- Do a full shutdown and power-off and cold-re-start
Was ich vergessen habe:
Der Grund warum bzw. wann man Coreparking deaktivieren sollte:
http://forum.cakewalk.com/tm.aspx?high=&m=1852473&mpage=1#1852473
Core Parking is VERY bad for DAW's - great for non-DAW Laptops - but very bad for us in the DAW world.
...
Without the following " fix " you will see massive CPU spiking in Sonar and Windows Task Manager - some CPU cores will be "turned off" / "parked" depending on load and they will be dynamically turned on or off and dynamically loaded up or down as the system deems necessary - the scope for glitchs / pops / clicks / droputs etc.... in such an environment is simply enormous.
Zu DAW: http://de.wikipedia.org/wiki/Digital_Audio_Workstation
Also:
Bei Core-Parking gibt es Probleme bei einer als DAW genutzten Rechnern.
Man darf dabei auch ein's nicht vergessen. Auf einem aktuellen System laufen sehr viele Threads. Auch wenn viele nicht gescheduled sind, werden es immer noch genügend sein, um praktisch eine konstante Ausführung auf einem 2/4 Kerne System zu verhindern. Da spielen auch sehr viele Faktoren eine Rolle. So pauschal kann man das auch nicht sagen, dass es schlecht wäre, wenn der Thread über die Cores geschoben wird. Letztendlich ist es ja besser, dass der Thread schnellstmöglich auf einem freien Kern ausgeführt wird anstatt zu warten, bis ein anderer Thread fertig ist, nur um der Affinitäts Willen wegen.
Da spielen noch viel mehr Faktoren eine Rolle, die das Verhalten beeinflussen können.
Gummikuh
2010-02-04, 09:02:37
Der Phenom 2 sollte die Kerne ja auch unabhängig voneinader takten können und ich wollte mal sehen ob dies denn unter Windows 7 funktioniert. Allerdings "verteilt" auch Win7 den Prozess auf alle vier Kerne. Will heißen: Ich habe bei einem Thread nicht einen Kern bei 100% Auslastung und 3GHz sondern vier Kerne bei +/- 25% Auslastung und dabei alle Kerne bei 3GHz. :confused:
Kannst ja auch mal das ganze mit SuperPi testen.Man darf hier aber nicht das geänderte C&Q des Phenom II vergessen, ein Phenom I verhält sich hier doch etwas anders.
Es gab von AMD doch mal ein Projekt bei dem Singlecore-Anwendungen per Hardware von Multicore profitieren sollten. Aber dieses Projekt wurde wohl eingestellt, da es nicht so einfach zu realisieren war.
Haha!!
....
Edit:Nochmal auf die Anspielung mit dem Scheduler... ich hab ihn leider nicht erfunden, ich beobachte aber und ich sehe das da nicht konstant auf einen Kern bei älteren Anwendungen, welche nicht für Dualcores oder auch Quadcores, verteilt wird. Frage mich natürlich auch warum, aber ich kenne die Erklärung leider nicht. Wer hat Sie? Und wieso ist das jetzt bei WIN 7 anders?
Ich hab vor ein paar Tagen mal mit Prime95 rumgespielt weil mich das interessierte. Bei Windows XP x64 fand ich es immer unsinng, dass Prime95 mit einem Thread immer über die Cores "hüpft" bzw. mehrere Kerne nutzt. Der Phenom 2 sollte die Kerne ja auch unabhängig voneinader takten können und ich wollte mal sehen ob dies denn unter Windows 7 funktioniert. Allerdings "verteilt" auch Win7 den Prozess auf alle vier Kerne. Will heißen: Ich habe bei einem Thread nicht einen Kern bei 100% Auslastung und 3GHz sondern vier Kerne bei +/- 25% Auslastung und dabei alle Kerne bei 3GHz. :confused:
Deswegen meine Frage bzw. dieses Thema!
Theoretisch sollte es es so sein, dass bei "geringerer" Last ein Core ausgelastet werden sollte und die anderen Cores "geparkt" bzw. kaum ausgelastet werden.
Real ist es aber so, dass die Threads (auch einer) mehr auf alle Cores verteilt werden. Unter Vista ist es "schlimmer" als unter XP. (So mein erster Eindruck)
So wie es ausschaut, ist es unter W7 genauso.
Kann es auch sein, dass die CPU selber auch hier die Threadverteilung begünstigt?
PS:
Hat einer mal geschaut, ob man Core-Parking unter W7, wie ich oben beschrieben habe, deaktivieren kann? (Habe kein W7)
Wie ist da die Threadverteilung auf die Cores?
Theoretisch sollte es es so sein, dass bei "geringerer" Last ein Core ausgelastet werden sollte und die anderen Cores "geparkt" bzw. kaum ausgelastet werden.
Unter dem Gesichtspunkt Energieeinsparung wäre das vielleicht hilfreich. Ich weiß es aber auch nicht genau. Vielleicht wäre es auch effizienter, wenn in dem Szenarion trotzdem alle Kerne arbeiten, aber eben heruntergetaktet etc.
Real ist es aber so, dass die Threads (auch einer) mehr auf alle Cores verteilt werden. Unter Vista ist es "schlimmer" als unter XP. (So mein erster Eindruck)
So wie es ausschaut, ist es unter W7 genauso.
Das ist zumindest unter dem Gesichtspunkt Performance auch die bessere Lösung. Es wäre vielleicht mal interessant zu erfahren, ob es hier Unterschiede gibt, wenn man die Energie Presets in Windows ändert.
backfisch
2010-02-04, 14:13:05
Wenn ich von der Uni zurück bin werde ich das ganze noch mal testen mit Windows 7 und Phenom 2. Dann kann ich auch mit SuperPi testen.
@Gast
Die Infortmationen zu Core Parking bei Windows 7 sind irgendwie ziemlich widersprüchlich. Von dem was ich bisher gefunden habe, muss Core Parking bei Windows 7 sogar noch aktiviert werden.
edit:
Mit den hier (http://forum.notebookreview.com/showthread.php?t=438883) aufgeführten Keys hat man schon mal Zugriff auf die zusätzlichen erweiterten Energieinstellungen bei Prozessorenergieverwaltung. Aktiviert wird Core Parking dadurch, wie oft behauptet, wohl nicht. Man hat einfach Zugriff auf die Einstellungen.
Das ist zumindest unter dem Gesichtspunkt Performance auch die bessere Lösung. Es wäre vielleicht mal interessant zu erfahren, ob es hier Unterschiede gibt, wenn man die Energie Presets in Windows ändert.
Threads von Core zu Core zu moven, ist garantiert keine performante Lösung.
Threads von Core zu Core zu moven, ist garantiert keine performante Lösung.
Ich würde dir recht geben, wenn ein Thread inmitten eines Quantums preempted wird, weil z.B. ein IRQL irgend eine Routine auslöst. Wenn aber der Quantum normal beendet wird und der Scheduler einen neuen Thread scheduled, ist ein Contextswitch sowieso sehr wahrscheinlich. Dann ist es auch egal, ob der Thread das nächste mal auf einem andren Kern gescheduled wird. Es ist zumindest effektiver anstatt du warten bis der andere Thread auf dem anderen Kern beendet wird und den einen Kern in der Zwischenzeit brach liegen zu lassen.
Ah? Es gibt, sei es realitätsfremde synthetische Benchmarks, 32bit Programme die auf dem gleichen Rechner unter Win7 schneller arbeiten als unter XPsp3?
Oder was meinst du mit "effizienter"?
Windows 7 scheduled erst zwei Threads auf einen Core mit SMT erst wenn alle anderen Cores was zu tun haben. Das ist nicht nur synthetisch ein Vorteil.
Aber auch sonst gab es wohl Änderungen. Gerade in den letzten Jahren hat sich da in der Forschung viel bewegt. Das kann man sehr gut am Linux-Kernel verfolgen ;)
http://www.pcpress.info/download/Intel/IDF/IDF09-32nm-Westmere-Products-Overview-eng.pdf
Windows 7 & Westmere: Better Together
• Idle Core: When the OS scheduler has a new thread to assign to a core, it will now check to see if an idle core is available, and if so, assign the new thread to that idle core.
• Quantum End: a time-slice for executing tasks. At the end of that time-slice the OS scheduler will look at threads in flight, and see if an idle core has become available. If so, a thread being executed on an HT core will be migrated over to the idle physical core to accelerate its execution.
• SMT Parking & Core Parking:
– SMT Parking: keeps HT cores parked until physical cores are busy to the point that the HT cores are needed.
– Core Parking: OS scheduler will “park” entire cores that aren’t being used, and those cores are then put into a deep-sleep state called C6. Used only in servers.
Unterschied SMT-Parking und Core Parking
Laut der Folie, wie ich verstanden habe:
SMT-Parking bei Kernen innerhalb gleicher CPU und Core Parking ganzer CPUs?
Oder doch nur Reale Kerne? Warum nur unter Server?
Video: Shiv Kaushik (Intel) und Mark Russinovich (MS) erklären Core Parking
http://intelstudios.edgesuite.net/idf/2009/sf/ti/day1/ss/f.htm
Folie: https://intel.wingateweb.com/us09/scheduler/catalog/catalog.jsp -> SPCS003 (etwas unten)
ab 6. Minute Core Parking in Hardware
ab 11. Minute Core Parking - Einführung
ab 13. Minute Core Parking - Timer -> Periodic Timer: Vista constant alle ~15 ms, unter W7 "tolerable delay"
ab 19. Minute: Funktionsweise Core Parking
ab 23. Minute: Dauer des Idles unter W7 besser als unter Vista
ab 24:30 Minute: Vergleich WS2003 und WS2008R2 unter Workload -> Bei 95% Workload 63W Ersparnis
ab 26. Minute Idle Power Vergleich WS2008SP2 und WS2008R2 >30% weniger
ab 27:10 Minute SMT-Hypterthreading
ab 31. Minute HT unter W7 -> 23% mehr Leistung für Windows Medica Coder zwischen W7 und Vista
ab 33. Minute SMT Parking für QuadCore
ab 35. Minute AES Cryption Acceleration
ab 38. Minute Scalapility
ab 43:30 Minute 64 Logical Processor
ab 45:30 Minute Removed Dispatcher Lock
ab 47:20 Minute Scale from 128 to 256 Logical Processor (QuadCore mit HT = 8 Logical Processor => 16 to 32 Quad-Cores mit HT)
Unterschied Fiber und Thread ???
ab 49. Minute Error-Fehler im Speicher -> Fehlertabelle
backfisch
2010-02-04, 21:41:10
Okay, ich hab's jetzt zum laufen bekommen. Man kann einstellen, dass immer nur ein Prozessor pro Kern geparkt wird. Das ist auch die Standardeinstellung. Beim Phenom ohne SMT kann so natürlich überhaupt kein Kern geparkt werden. Bei CPU's mit SMT sollte das ganze also funktionieren, ohne das man da was umstellen muss. Müsste mal ein User mit Core ix mit HT überprüfen.
Bei mir werden die Kerne jetzt geparkt. Sowohl Superpi als auch Prime95 scheren sich allerings nicht wirklich darum und nutzen meistens 2 Kerne. Vorher waren es allerdings alle vier. SuperPi ist dabei mit Core Parking tendenziel sogar etwas langsamer als ohne.
Zumindest bei meinem Phenom 2 System bietet das ganze aber auch keine Vorteile beim Verbrauch da die Kerne nicht unabhängig voneinander getaktet werden. Auch wenn ich Prime 95 fest an einen Kern binde takten alle hoch. Das hatte ich irgendwie anders in Erinnerung. Weiß da jemand was zu? THG schreibt hier (http://www.tomshardware.com/de/phenom-x2,testberichte-240342-11.html) was dazu. Wurde wohl deaktiviert. :|
Bei mir werden die Kerne jetzt geparkt. Sowohl Superpi als auch Prime95 scheren sich allerings nicht wirklich darum und nutzen meistens 2 Kerne. Vorher waren es allerdings alle vier. SuperPi ist dabei mit Core Parking tendenziel sogar etwas langsamer als ohne.
In dem obigen Video hat Mark Russinovich gesagt, dass das OS die Prozessorauslastung überwacht und aufgrund dessen entscheidet, ob nun geparkt wird oder aber die Threads auf mehrere Kerne verteilt werden.
Um es mal in Bildern zu zeigen:
Ich habe MEncoder per Befehlszeile gestartet, und jeweils in 1, 2, 3, 4 und 6 Threads nur mit x264 das gleiche Video encodieren lassen (ohne Sound und Filter).
Hier sind die Resultate:
1 Thread:
http://img524.imageshack.us/img524/4200/i5mex2641thread.th.jpg (http://img524.imageshack.us/i/i5mex2641thread.jpg/)
2 Thread:
http://img8.imageshack.us/img8/685/i5mex2642thread.th.jpg (http://img8.imageshack.us/i/i5mex2642thread.jpg/)
3 Thread
http://img229.imageshack.us/img229/2397/i5mex2643thread.th.jpg (http://img229.imageshack.us/i/i5mex2643thread.jpg/)
4 Thread
http://img138.imageshack.us/img138/3414/i5mex2644thread.th.jpg (http://img138.imageshack.us/i/i5mex2644thread.jpg/)
6 Thread
http://img502.imageshack.us/img502/5549/i5mex2646thread.th.jpg (http://img502.imageshack.us/i/i5mex2646thread.jpg/)
Außerdem habe ich Toast laufen lassen:
http://img222.imageshack.us/img222/7923/i5toast1mal.th.jpg (http://img222.imageshack.us/i/i5toast1mal.jpg/)
Wie man sehen kann, wird ein Thread auf 2 Cores mit ~25% verteilt;
Bei 2 Threads auf 4 Cores zu ~50%; bei 3 Thread zu ~75%, bei 4 Threads zu über ~98%, bei 6 Cores zu ~100%.
Toast wird auf 2 Cores verteilt und die beiden anderen Cores teilweise.
Bei anderen Programmen läuft es ähnlich.
Nun meine Frage:
Warum wird nicht ein Core alleine bei 1 Thread genutzt, um es übertakten zu lassen (Turbo-Boost)? Genauso bei 2 Threads?
Ok, SMT/Core-Parking funktioniert unter Vista nicht, aber die Threads werden dennoch mehr verteilt.
Ein Positives hat es: Die Cores laufen eim i5 einzeln mit unterschiedlichen Frequenzen.
Okay, ich hab's jetzt zum laufen bekommen. Man kann einstellen, dass immer nur ein Prozessor pro Kern geparkt wird. Das ist auch die Standardeinstellung. Beim Phenom ohne SMT kann so natürlich überhaupt kein Kern geparkt werden. Bei CPU's mit SMT sollte das ganze also funktionieren, ohne das man da was umstellen muss. Müsste mal ein User mit Core ix mit HT überprüfen.
Bei mir werden die Kerne jetzt geparkt. Sowohl Superpi als auch Prime95 scheren sich allerings nicht wirklich darum und nutzen meistens 2 Kerne. Vorher waren es allerdings alle vier. SuperPi ist dabei mit Core Parking tendenziel sogar etwas langsamer als ohne.
Zumindest bei meinem Phenom 2 System bietet das ganze aber auch keine Vorteile beim Verbrauch da die Kerne nicht unabhängig voneinander getaktet werden. Auch wenn ich Prime 95 fest an einen Kern binde takten alle hoch. Das hatte ich irgendwie anders in Erinnerung. Weiß da jemand was zu? THG schreibt hier (http://www.tomshardware.com/de/phenom-x2,testberichte-240342-11.html) was dazu. Wurde wohl deaktiviert. :|
Meinst du mit einstellen, über den Taskmanager den entsprechenden Core auswählen?
Also beim i5 takten die Kerne unabhängig voneinander. (Siehe leicht oben die Bilder mit TMonitor) Die Threads werden etwas besser verteilt. Müsste mal schauen, ob es am Scheduler von Vista liegt.
Zu deinem Bemerkung von fester Taktfrequenz beim Phenom II:
Wie ich im weiter oberen Link angemerkt habe, wird im Forum von cakewalk/Roland empfohlen Core-Parking bei DAW zu deaktivieren.
Kann sein, dass AMD deswegen dazu alle Cores mit gleicher Frequenz laufen lässt. Dann sollte DAW besser laufen.
Die Threadverteilung sollte dann bei Phenom besser laufen, um mit der Frequenz runter zu gehen.
In dem obigen Video hat Mark Russinovich gesagt, dass das OS die Prozessorauslastung überwacht und aufgrund dessen entscheidet, ob nun geparkt wird oder aber die Threads auf mehrere Kerne verteilt werden.
Das macht der Scheduler. Aber wie sind die Kriterien?
backfisch
2010-02-04, 22:28:34
Langsam steige ich bei den Gast Kommentaren nicht mehr durch, wer jetzt wer ist. :D
Ja ich habe über den Taskmanager Prime95 und Superpi probeweise an einen einzelnen Kern gebunden um zu sehen, ob dann nur dieser hoch taktet. Ich hatte ja vermutet, dass Core Parking ähnliches macht.
Das mit dem DAW klingt logisch. Allerdings sollen solche Sachen wie Core Parking und Ideal Core ja grade diese Problematik beheben, wenn ich das richtig verstanden habe.
Hier noch was dazu.
Würde mich wirklich mal interessieren, wie das bei Core ix Usern und Windows 7 aussieht. Kann mal jemand gucken, ob da Kerne geparkt werden? Zeigt der Ressourcenmonitor ja an.
Warum wird nicht ein Core alleine bei 1 Thread genutzt, um es übertakten zu lassen (Turbo-Boost)? Genauso bei 2 Threads?
Weil Windows ein preemptives Multitasking System ist und eine ganze Menge mehr Threads laufen als nur dein Encoder. Werfe doch mal den Sysinternals Prozessexplorer an und wähle als Spalte Context Switch oder Context Switch Delta (das sind die Switches/Sekunde) und schau dir das mal für die ganzen Prozesse an. Dann sollte deine Frage geklärt sein, warum das Windows nicht so leicht machen kann und es auch unsinnig wäre.
Außerdem musst du es vielleicht gerade anders herum sehen. Selbst wenn man bei deinem 1 Thread Bsp. mal die Last von allen vier Kernen zusammenrechnet ergibt das im Schnitt 100%. Das ist natürlich voll am Anschlag und das OS wird deswegen die Threads aufgrund der Gesamtlast verteilen, um besser zu skalieren. Das ist ja auch voll ok. Außerdem glaube ich bei dem 1 Thread Bsp. nicht, dass alle Kerne nur durch den Encoder ausgelastet werden. Wie gesagt, schau dir's im Process Explorer an.
Weil Windows ein preemptives Multitasking System ist und eine ganze Menge mehr Threads laufen als nur dein Encoder.
Von den Threads die gerade im System laufen, sind aber nur ganz wenige im running mode und erzeugen in der Regel eine geringe Last. Wenn ich jetzt ein Single-Threaded Programm starte, welches einen Kern zu 100% belastet, dann sollte dieser Thread auf ein und dem selben Kern bleiben. Der Scheduler kann dieses sogar leicht erkennen. Jedenfalls verhält sich Windows XP so. Bei einer Dual Core CPU, steht genau ein Kern auf 100%. Warum sollte jetzt die Last auf beide Kerne unter W7 verteilt werden? Ich bin immer noch der Meinung, dass dies langsamer ist.
naja imho wäre es ganz sicher cleverer den prozess gar nicht zu switchen wenn eine singlethreaded applikation >50% eines Cores ausnutzt
hätte man sowas nicht als regel implementieren können?
(del)
2010-02-05, 12:20:02
Windows 7 scheduled erst zwei Threads auf einen Core mit SMT erst wenn alle anderen Cores was zu tun haben.Klar ein Vorteil.
Das ist nicht nur synthetisch ein Vorteil.Deswegen hab ich auch gefragt, ob ich das mal irgendwo sehen kann ;)
Von den Threads die gerade im System laufen, sind aber nur ganz wenige im running mode und erzeugen in der Regel eine geringe Last.
So wenig Threads sind es nicht. Es laufen genügend Threads, die um ein Vielfaches die Anzahl von vier Kernen übersteigen. Das werden locker 40 Threads sein, die pro Sekunde gescheduled werden, wahrscheinlich noch viel mehr. Dann darfst du auch nicht die ganzen System Prozesse vergessen.
Wenn ich mir hier einige Prozesse wie Notes oder Firefox oder Visual Studio anschaue, dann machen die schon jeweils über tausend Context Switches pro Sekunde (und die sind nicht aktiv im Vordergrund). Bei den System Prozessen geht es, da macht nur der Anmeldedienst und der Session Dienst einige hundert C Switches pro Sekunde.
Ob die Threads nun Last erzeugen, spielt erst mal keine Rolle. Viele werden gar keine Last erzeugen, sondern nur irgend etwas pollen. Aber sie werden gescheduled.
So wenig Threads sind es nicht. Es laufen genügend Threads, die um ein Vielfaches die Anzahl von vier Kernen übersteigen. Das werden locker 40 Threads sein, die pro Sekunde gescheduled werden, wahrscheinlich noch viel mehr. Dann darfst du auch nicht die ganzen System Prozesse vergessen.
Darum geht es doch gar nicht. Die Frage ist eigentlich, wie sich der Scheduler verhält, wenn es einen oder mehrere Threads gibt, die eine hohe Last erzeugen. Die Threads die sonst so im System vor sich herdümpeln interessieren doch gar nicht. Der Scheduler sollte erkennen, dass ein Thread mit hoher Last möglichst einen Kern exklusiv erhält, also auch keine Context-Switch benötigt, der Rest kann sich um den anderen Kern kloppen, es sei denn die Anzahl der Threads mit hoher Last steigt. In diesem Falls wird die Strategie des Schedulers für die Zuweisung eines Threads an einen Kern, sicherlich eine andere sein. Soweit ich weiss, wird der Scheduler die Threads mit hoher Last sofort wieder reschedulen. Was auch heißen kann, dass andere Threads, die wenig zu tun haben, "verhungern" können.
Ob die Threads nun Last erzeugen, spielt erst mal keine Rolle.
Doch, tut es aber.
Viele werden gar keine Last erzeugen, sondern nur irgend etwas pollen. Aber sie werden gescheduled.
Ich weiss nicht wie es jetzt in W7 ist, aber eigentlich kommen Threads mit niedriger CPU Last nicht mehr an die Reihe, wenn es einen Thread gibt, der eine hohe Last erzeugt. Aussnahmen bilden natürlich Threads mit höherer Priorität und IRQs.
Es ist def. so, dass nur Threads gescheduled werden die auch "wach" sind. Bei meinem Linux-Server zeigt top z.B. normalerweise an, dass nur top selber läuft, wenn kein Traffic stattfindet.
Das ist auch bei einem Desktop-System nicht viel anders. Alles was im Task-Manager 0% Prozessor braucht kommt gar nicht erst an die Reihe.
Sieht man auch schön, wenn man "CPU Time" einblendet. Die Sidebar hat seit ich gebootet habe genau 1s CPU gesehen ;)
Doch, tut es aber.
Aber eine hohe Last sagt nicht zwangsweise etwas darüber aus, dass der Thread auch am wichtigsten/kritischsten ist. Wenn jetzt plötzlich jedes Popelprogramm, dass durch schlechte Programmierung eine hohe Last erzeugt, irgendwelche anderen wichtigen System Theads ausbremst (die z.B. regelmäßig gescheduled werden müssen, auch wenn sie keine hohe Last erzeugen), wäre das in meinen Augen eine schlechte Strategie und würde die Gesamtperformance und Reaktionsfähigkeit des Systems deutlich verschlechtern. Eine gewisse Neutralität und Fairness muss der Scheduler ja schon haben.
Außerdem - wie du ja selbst gesagt hast - können nun mal irgendwelche Kernel Threads, die mit Realtime Priorität laufen den aktuellen Thread preempten. Und das wird auch rech häufig passieren, weswegen Context Switches unausweichlich sind.
Ich denke mal das ganze ist schon viel viel komplizierter als es auf den ersten Blick vielleicht scheint. Wenn es leicht wäre, hätten die das in Windows schon eingebaut.
Rolsch
2010-02-05, 20:49:20
Nun meine Frage:
Warum wird nicht ein Core alleine bei 1 Thread genutzt, um es übertakten zu lassen (Turbo-Boost)? Genauso bei 2 Threads?
Ok, SMT/Core-Parking funktioniert unter Vista nicht, aber die Threads werden dennoch mehr verteilt.
Als bei XP wurde mir dieses Verhalten so erklärt: Die Prefetcher ALLER Kerne versuchen nonstop die nächsten Aktionen zu erraten, hat einer richtig geraten übernimmt dieser Kern. Auf gut deutsch: bessere Performance durch weniger Cache misses.
Als bei XP wurde mir dieses Verhalten so erklärt: Die Prefetcher ALLER Kerne versuchen nonstop die nächsten Aktionen zu erraten, hat einer richtig geraten übernimmt dieser Kern. Auf gut deutsch: bessere Performance durch weniger Cache misses.
Der Prefetcher bzw. der Kern spielt hierbei eine entscheidende Rolle auf die Verteilung der Threads bzw. mind. eines einzelnen Thread.
Bei W7 und ix soll dies besser zusammen funktionieren. Nur wird nicht genau eingegangen nach welchen Regeln dies abläuft und wann der Kern zum SMT-Parking geschickt wird.
Ohne W7(=Kontrolle) scheint der i5 die Threads besser bzw. verstärkt auf die Kerne zu verteilen. (So mein Eindruck)
Man müsste auf i5 XP, Vista und W7 (mit/ohne SMT-Parking) installieren, ausprobieren und vergleichen.
Ohne W7(=Kontrolle) scheint der i5 die Threads besser bzw. verstärkt auf die Kerne zu verteilen. (So mein Eindruck)
Man müsste auf i5 XP, Vista und W7 (mit/ohne SMT-Parking) installieren, ausprobieren und vergleichen.Das wird vielleicht schwierig. Ich behaupte mal rotzfrech, daß XPsp3 den Prefetcher und Scheduler aus dem 32bit Server2003 R2 bekommen hat.
Das wird vielleicht schwierig. Ich behaupte mal rotzfrech, daß XPsp3 den Prefetcher und Scheduler aus dem 32bit Server2003 R2 bekommen hat.
Könnte sein, jedenfalls die gleichen Source-Codes.
Im Video wurde gesagt, dass Windows Media Coder unter W7 23% mehr Leistung hat als unter Vista (und den neuen Prozessoren).
Ich sage mal aufgrund meiner Beobachtungen, dass der ix-Prozessor zum einen besser verteilt als die älteren Kerne und der OS-Scheduler vom W7 dies besser steuert.
Nur müsste man dies anhand von Benches unter verschiedenen OS nachprüfen.
Im Video wurde gesagt, dass Windows Media Coder unter W7 23% mehr Leistung hat als unter Vista (und den neuen Prozessoren).Als sinnvolles Beispiel nur wenn vorausgesetzt, daß es dann nicht am Media Coder selbst liegt ;)
Der HeinZ
2010-02-11, 11:52:52
Um es mal in Bildern zu zeigen:
Ich habe MEncoder per Befehlszeile gestartet, und jeweils in 1, 2, 3, 4 und 6 Threads nur mit x264 das gleiche Video encodieren lassen (ohne Sound und Filter).
Hier sind die Resultate:
1 Thread:
http://img524.imageshack.us/img524/4200/i5mex2641thread.th.jpg (http://img524.imageshack.us/i/i5mex2641thread.jpg/)
2 Thread:
http://img8.imageshack.us/img8/685/i5mex2642thread.th.jpg (http://img8.imageshack.us/i/i5mex2642thread.jpg/)
3 Thread
http://img229.imageshack.us/img229/2397/i5mex2643thread.th.jpg (http://img229.imageshack.us/i/i5mex2643thread.jpg/)
4 Thread
http://img138.imageshack.us/img138/3414/i5mex2644thread.th.jpg (http://img138.imageshack.us/i/i5mex2644thread.jpg/)
6 Thread
http://img502.imageshack.us/img502/5549/i5mex2646thread.th.jpg (http://img502.imageshack.us/i/i5mex2646thread.jpg/)
Außerdem habe ich Toast laufen lassen:
http://img222.imageshack.us/img222/7923/i5toast1mal.th.jpg (http://img222.imageshack.us/i/i5toast1mal.jpg/)
Wie man sehen kann, wird ein Thread auf 2 Cores mit ~25% verteilt;
Bei 2 Threads auf 4 Cores zu ~50%; bei 3 Thread zu ~75%, bei 4 Threads zu über ~98%, bei 6 Cores zu ~100%.
Toast wird auf 2 Cores verteilt und die beiden anderen Cores teilweise.
Bei anderen Programmen läuft es ähnlich.
Nun meine Frage:
Warum wird nicht ein Core alleine bei 1 Thread genutzt, um es übertakten zu lassen (Turbo-Boost)? Genauso bei 2 Threads?
Ok, SMT/Core-Parking funktioniert unter Vista nicht, aber die Threads werden dennoch mehr verteilt.
Ein Positives hat es: Die Cores laufen eim i5 einzeln mit unterschiedlichen Frequenzen.
Wenn ich das da jetzt richtig sehe, schaltet der Turbo Modus auch bei einem Thread doch recht selten hoch oder? Deine Ergebniss waren jetzt aus Vista... JETZT interessieren mich Ergebnisse von Win7 noch mehr bei dem gleichen Programm. Es macht ja keinen Sinn, das der Turbo Modus nur so sporadisch genutzt wird. Ähnlich verhält es sich ja mit den Sparfunktionen, also runtertakten. Schiebt der Scheduler, takten die Kerne rauf und runter, das kostet doch auch energie oder?
Die Auslastung der Kerne kann man sich besser mit Perfmon anschauen, da sieht man doch eher eine reale Auslastung, beim Taskmanager ist das alles doch sehr schwammig. Kannste ja nebei auch noch laufen lassen
Gruß Matthias
Wenn ich das da jetzt richtig sehe, schaltet der Turbo Modus auch bei einem Thread doch recht selten hoch oder? Deine Ergebniss waren jetzt aus Vista... JETZT interessieren mich Ergebnisse von Win7 noch mehr bei dem gleichen Programm. Es macht ja keinen Sinn, das der Turbo Modus nur so sporadisch genutzt wird. Ähnlich verhält es sich ja mit den Sparfunktionen, also runtertakten. Schiebt der Scheduler, takten die Kerne rauf und runter, das kostet doch auch energie oder?
Die Auslastung der Kerne kann man sich besser mit Perfmon anschauen, da sieht man doch eher eine reale Auslastung, beim Taskmanager ist das alles doch sehr schwammig. Kannste ja nebei auch noch laufen lassen
Gruß Matthias
Wie gesagt, ist es nicht mein Rechner. W7 kommt demnächst (legal) drauf.
Da bin ich auch gespannt, wie das System dann reagiert.
Das rauf und runter takten kostet kaum Energie, eher dass der Core mit einer höheren Taktfrequenz läuft. (Höhere Taktfrequenz, höhere CPU-Spg, höhere Leakströme, höhere Verluste usw.)
Beim Review vom neuem Intel Core i7-980x 6 Kerner ist die Thread-Verteilung vom Vista negativ aufgefallen.
http://www.golem.de/1003/73762-8.html
Intels Desktop-Direktor Steve Peterson bestätigte im Gespräch auf der Cebit 2010 diese Effekte: Durch den veralteten Thread-Scheduler von Vista steht sich das Betriebssystem oft selbst im Weg. Es verlagert öfter Threads auf Kerne, die schon belastet sind - deren Threads müssen dann wieder auf andere portiert werden.
...
Darum hat Intel für Windows 7 zusammen mit Microsoft die Funktion des "SMT Parking" entwickelt.
...
Die HyperThreading-Bremse von Vista trat mit den bisherigen Core i7 nicht so massiv auf wie beim 980X, da bisher nur acht Threads zu verwalten waren..
...
An 12 Threads auf dem Desktop dachte vor drei Jahren, als die Entwicklung von Vista abgeschlossen wurde, bei Microsoft offenbar noch niemand.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.