Archiv verlassen und diese Seite im Standarddesign anzeigen : Lastverteilung bei Dual Cores - wie läuft das in der Praxis?
Hallo!
Ich hab schon Forensuche benutzt, aber nix passendes gefunden.
Meine Frage ist, wie läuft das eigentlich bei einem DC in der Praxis mit der Lastverteilung? Nehmen wir an ich will eine DVD encodieren und gleichzeitig Prey spielen, muss ich dann manuell den Applikationen einen eigenen Core zuweisen oder läuft das automatisch?
Weil wenn das manuell gemacht werden muss wäre das für mich ein Anti-DC Argument, aber dafür frage ich hier ja :)
Zephyroth
2006-11-22, 11:48:26
Tatsächlich läuft die Lastverteilung automatisch im Hintergrund. Es ist sogar so, das die Applikationen zwischen den Cores herumgeschoben wird.
Spielt man nun einen Singlecoreanwendung so wird sie in der Regel beide Cores zu je 50% auslasten, jedoch nicht mehr....
Dieses Herumschieben kann jedoch bei gewissen Spielen ein Problem sein, dann ist eine manuelle Zuweisung notwendig. Bei mir war das nur bei "The Longest Journey" (aus dem Jahr 1999) notwendig, alle anderen Spiele kommen mit dem DualCore ohne Probleme klar.
Du kannst also tatsächlich nebenher Encodieren und Spielen, bei aktueller Software stellt dies in der Regel kein Problem da....
Grüße,
Zeph
Expandable
2006-11-22, 12:54:13
Spielt man nun einen Singlecoreanwendung so wird sie in der Regel beide Cores zu je 50% auslasten, jedoch nicht mehr....
Das ist völlig bescheuert. Würde man eine CPU zu 100% auslasten, wäre es (wenn auch nur geringfügig) schneller und hätte keinerlei Nachteile. Wird das mit Vista eigentlich besser?
Das ist völlig bescheuert. Würde man eine CPU zu 100% auslasten, wäre es (wenn auch nur geringfügig) schneller und hätte keinerlei Nachteile. Wird das mit Vista eigentlich besser?
Wie meinen?
The_Invisible
2006-11-22, 14:05:14
Tatsächlich läuft die Lastverteilung automatisch im Hintergrund. Es ist sogar so, das die Applikationen zwischen den Cores herumgeschoben wird.
Spielt man nun einen Singlecoreanwendung so wird sie in der Regel beide Cores zu je 50% auslasten, jedoch nicht mehr....
Dieses Herumschieben kann jedoch bei gewissen Spielen ein Problem sein, dann ist eine manuelle Zuweisung notwendig. Bei mir war das nur bei "The Longest Journey" (aus dem Jahr 1999) notwendig, alle anderen Spiele kommen mit dem DualCore ohne Probleme klar.
Du kannst also tatsächlich nebenher Encodieren und Spielen, bei aktueller Software stellt dies in der Regel kein Problem da....
Grüße,
Zeph
ähm, ja, unter windows ist es so, aber es gibt auch noch VIELE andere betriebssysteme
mfg
Wie meinen?Ganz einfach: Wenn ein Thread immer wieder von einem Core zum anderen wechselt, dann ist das nicht so gut für die Performance. Die Caches sind beim neuen Core noch nicht warm und wenn es eine Architektur ist, die Hardware-loaded TLBs verwendet, dann sind diese ebenso noch nicht warm. Das führt dazu, dass die Ausführungsgeschwindigkeit kleiner ist als wenn der Thread die ganze Zeit auf dem gleichen Core bleiben würde.
Dieses Herumschieben kann jedoch bei gewissen Spielen ein Problem sein, dann ist eine manuelle Zuweisung notwendig. Bei mir war das nur bei "The Longest Journey" (aus dem Jahr 1999) notwendig, alle anderen Spiele kommen mit dem DualCore ohne Probleme klar.Das Problem ist hier wohl, wenn sich ein Programm auf den TimeStamp Counter des Prozessors für die Zeitmessung verlässt. Da aber nicht garantiert wird, dass diese auf verschiedenen Cores die gleichen Werte oder zumindest eine hinreichend kleine Differenz aufweisen, kann es hierbei zu Problemen beim Timing kommen.
Dazu kommt, dass Windows hierbei auch nicht hilfreich ist, weil für die per WinAPI angebotene Zeitmessung auch nur der TimeStamp Counter ausgelesen wird, wenn mehrere Prozessoren vorhanden sind. :bonk: Dabei hätte man mit dem im Chipsatz integrierten Timer eine unabhängige Zeitquelle. Deren Auflösung ist mit wenigen MHz zwar nicht so genau wie der TSC, aber für die meisten Anwendungen reicht das locker aus.
Diese Probleme sind also einerseits durch ungeschickte Programmierung von Anwendungen als auch durch verkorkstes OS-Design von Microsoft hervorgerufen. Da gab's mal einen interessanten Thread hierzu im Forum. Ich bin aber gerade zu faul zum Suchen.
GloomY
oliht
2006-11-22, 18:49:12
Interessant wird ja die Lastverteilung ab ja erst bei mehreren Threads. Zum Beispiel bei 4 Cores und 4 Threads die theoretisch zu 100 % parallelisiert sind und 100s brauchen. Dabei ist dann die Frage was ist günstiger jeden Core einen Thread geben und alle sind nach 100s fertig, oder alle Cores an einem Thread arbeiten lassen, so dass der erste nach 25s fertig ist der zweite nach 50s usw..
Ich hatte da mal an der Uni ein paar Graphen gesehen wo bei einem voll ausgelasteten System parallele Anwendung deutlich langsamer wurden, als wenn man sie sequentiell ausgeführt hätte. Unser Prof. hat dann auf die miesen Scheduler geschimpft und dass diese Probleme bis heute nicht vollständig gelöst sind.
Würde mich mal interessieren wie das ganze unter Windows aussieht
Ganz einfach: Wenn ein Thread immer wieder von einem Core zum anderen wechselt, dann ist das nicht so gut für die Performance. Die Caches sind beim neuen Core noch nicht warm und wenn es eine Architektur ist, die Hardware-loaded TLBs verwendet, dann sind diese ebenso noch nicht warm. Das führt dazu, dass die Ausführungsgeschwindigkeit kleiner ist als wenn der Thread die ganze Zeit auf dem gleichen Core bleiben würde.
zumindest mit dem core2 duo ist das kein problem mehr.
Ganz einfach: Wenn ein Thread immer wieder von einem Core zum anderen wechselt, dann ist das nicht so gut für die Performance. Die Caches sind beim neuen Core noch nicht warm und wenn es eine Architektur ist, die Hardware-loaded TLBs verwendet, dann sind diese ebenso noch nicht warm. Das führt dazu, dass die Ausführungsgeschwindigkeit kleiner ist als wenn der Thread die ganze Zeit auf dem gleichen Core bleiben würde.
In der Realität sind aber nicht nur ein oder zwei Threads vorhanden, sondern hunderte oder tausende und es können Threads mit unterschiedlichen Prioritäten gescheduled werden. Ich bin mir nicht sicher, ob das schlau wäre bei "allen" Threads mit festen Affinitäten zu arbeiten. Wenn Threads mit hohen Prios gescheduled werden und eine feste Affinität hätten und erst Threads unterbrechen müssten, weil die auch gerade die selbe Affinität haben, wäre das ebenfalls sehr ungünstig.
Das Problem ist hier wohl, wenn sich ein Programm auf den TimeStamp Counter des Prozessors für die Zeitmessung verlässt. Da aber nicht garantiert wird, dass diese auf verschiedenen Cores die gleichen Werte oder zumindest eine hinreichend kleine Differenz aufweisen, kann es hierbei zu Problemen beim Timing kommen.
Nicht nur da, sondern auch dann, wenn der Prozessor Stromsparmechanismen hat und sich runtertaktet.
Dazu kommt, dass Windows hierbei auch nicht hilfreich ist, weil für die per WinAPI angebotene Zeitmessung auch nur der TimeStamp Counter ausgelesen wird, wenn mehrere Prozessoren vorhanden sind. :bonk: Dabei hätte man mit dem im Chipsatz integrierten Timer eine unabhängige Zeitquelle. Deren Auflösung ist mit wenigen MHz zwar nicht so genau wie der TSC, aber für die meisten Anwendungen reicht das locker aus.
QueryPerformanceCounter tut genau das, sofern auf dem Motherboard ein high resolution Timer installiert ist.
Zephyroth
2006-11-23, 15:08:54
Das ist völlig bescheuert. Würde man eine CPU zu 100% auslasten, wäre es (wenn auch nur geringfügig) schneller und hätte keinerlei Nachteile. Wird das mit Vista eigentlich besser?
Nicht unbedingt, ich habe irgendwo gelesen, das es durchaus vorkommt, das bei einer ja/nein Entscheidung der eine Core "Ja" und der andere "Nein" in die Pipeline bekommt und diese abarbeitet und je nach Ergebnis dann der Core mit der richtigen Antwort weiterverwendet wird, davon kommt auch dieses "Gehopse"...
Grüße,
Zeph
Wurschtler
2006-11-23, 15:20:28
Also, wie das ganze funktioniert bzw. den Sinn von dieser Lastverteilung hab ich auch noch nicht genau verstanden.
Hier mal ein Pic von meinem Kentsfield, wenn zwei Programm laufen, die je eine CPU voll beanspruchen:
http://s3.bilder-hosting.de/tbnl/7DN62.png (http://www.bilder-hosting.de/show/7DN62.html)
Ich hab auch mal einige Benchmarks gemacht, die dann jeweils nur einen bestimmten Kern zugewiesen bekommen haben und dann mal mehrere oder alle.
Dort habe ich aber keine Performanceunterschiede feststellen können. (alles innerhalb der Messungenauigkeit)
Zephyroth
2006-11-23, 16:21:17
Das einzige mal, wo ich wirklich 2x100% hatte, war mit zwei Prime95-Instanzen, die dann wirklich jeden Core voll auslasteten.
Beim MP3 Encodieren schaffe ich ca. 100% und 30%-50% am zweiten Core. Dies liegt wahrscheinlich daran, das der zweite Core durchaus auf Ergebnisse aus dem ersten warten muß.
Grüße,
Zeph
Muh-sagt-die-Kuh
2006-11-23, 16:31:26
Interessant wird ja die Lastverteilung ab ja erst bei mehreren Threads. Zum Beispiel bei 4 Cores und 4 Threads die theoretisch zu 100 % parallelisiert sind und 100s brauchen. Dabei ist dann die Frage was ist günstiger jeden Core einen Thread geben und alle sind nach 100s fertig, oder alle Cores an einem Thread arbeiten lassen, so dass der erste nach 25s fertig ist der zweite nach 50s usw.. Das ist eine unsinnige Überlegung, da ein Thread eine unteilbare Einheit darstellt.
Armaq
2006-11-23, 17:03:13
2x100% habe ich bisher auch nur in Prime gesehen. Wobei man ohne manuelles zuweisen sogar 51% und 49% hat. Scheint ein kleiner Trick zu sein.
OHNE Zuweisung kann ich noch Programme starten (CPUZ, Speedfan) und sie laden halbwegs vernünftig. MIT Zuweisung rattert er ne Weile länger.
oliht
2006-11-23, 18:56:23
Das ist eine unsinnige Überlegung, da ein Thread eine unteilbare Einheit darstellt.
Ok mein Fehler meine Prozesse.
Den Test den man mal mit einen Dualcore Prozessor machen müsste ist eine Anwendung die sowohl Multithreaded ist als auch nur mit einem Thread arbeiten kann laufen lassen. Wobei natürlich die Anwendung bei 2 Threads möglichst halb so lang braucht als wenn nur ein Thread arbeitet. Würde diese Anwendung z.B. 100s mit n=1 Thread brauchen sollte sie mit n=2 Threads annährend 50 s brauchen. Wenn ich nun diese Anwendung für n=1 Thread 2mal laufen lasse wird mein System 100s voll ausgelastet. Wenn ich die gleiche Anwendung 2mal für n=2 Threads laufen lasse würde idealerweise nach 50 sekunden der erste Prozess fertig sein und nach 100s der zweite. Ich vermute aber mal, dass das ganze System deutlich länger als 100 s braucht.
Seraf
2006-11-23, 19:35:17
ähm, ja, unter windows ist es so, aber es gibt auch noch VIELE andere betriebssysteme
mfg
Genau, andere Betriebssysteme verhalten sich total anders *lol*
http://lists.suse.com/archive/suse-linux/1999-Sep/0049.html
Ist zwar von 99, aber trotzdem sollte sich an diesem Verhalten nichts geändert haben, da es das normale Verhalten sein sollte. Kein Programm läuft dauerhaft auf einem Core. Es ist auch nicht unnatürlich das Windows ein Programm unterbricht. Das machen alle Betriebssysteme die einen Task Scheduler haben irgendwann. Und wenn das Programm wieder laufen darf wird es eben auf dem Prozessor laufen gelassen der gerade frei ist.
Muh-sagt-die-Kuh
2006-11-23, 22:05:52
Wenn ich die gleiche Anwendung 2mal für n=2 Threads laufen lasse würde idealerweise nach 50 sekunden der erste Prozess fertig sein und nach 100s der zweite. Ich vermute aber mal, dass das ganze System deutlich länger als 100 s braucht.Nein, dann sind beide Prozessinstanzen nach geringfügig mehr als 100 s fertig (gleiche Priorität vorausgesetzt). Der Overhead durch Task-Switching ist allgemein sehr gering.....ansonsten könnte man mit einem Single-Core System mit vielen parallelen Anwendune nicht gescheit arbeiten ;)
SentinelBorg
2006-11-23, 22:14:47
Genau, andere Betriebssysteme verhalten sich total anders *lol*
http://lists.suse.com/archive/suse-linux/1999-Sep/0049.html
Ist zwar von 99, aber trotzdem sollte sich an diesem Verhalten nichts geändert haben, da es das normale Verhalten sein sollte. Kein Programm läuft dauerhaft auf einem Core. Es ist auch nicht unnatürlich das Windows ein Programm unterbricht. Das machen alle Betriebssysteme die einen Task Scheduler haben irgendwann. Und wenn das Programm wieder laufen darf wird es eben auf dem Prozessor laufen gelassen der gerade frei ist.
Und diese "Programmunterbrechungen" passieren im Nanosekundentakt ...
Sentinel
Und diese "Programmunterbrechungen" passieren im Nanosekundentakt ...
ns halte ich für etwas übertrieben, aber ms dürften es schon sein.
Seraf
2006-11-23, 22:39:57
Es dauert nur ein paar µs.
The released Windows NT kernel has a minimum context switch time of 8.4µs, with a median of 10.6µs
http://research.microsoft.com/~mbj/papers/tr-99-59/tr-99-59.html
Dort findet man noch etwas nettes:
3.5.3 Multiprocessor Issues
We initially considered pinning scheduling plans to processors by manipulating the affinity masks of RT threads. Affinity masks are attributes of Windows NT threads that restrict them to be scheduled only on a subset of the available CPUs. However, pinning RT threads to a single CPU would prevent them from opportunistically using free time on other processors.
ich hätte gedacht, daß ist abhänging vom prozessortakt.
windowsNT ist schon bischen alt.
macht das xp oder vista nicht ein bischen schneller?
Neomi
2006-11-24, 00:07:22
Es dauert nur ein paar µs.
Lies dir den Text auf deiner verlinkten Seite nochmal genau durch, du hast da nämlich was durcheinandergewürfelt. Die angegebenen 8,4 µs (Minimum) bzw. 10,6 µs (Durchschnitt) sind nicht der Intervall, sondern die Dauer (also quasi der Overhead) für einen Kontextwechsel. Die Zeitscheiben sind mindestens 1 ms lang, das steht sogar direkt hinter deiner gequoteten Stelle.
oliht
2006-11-24, 00:12:20
Nein, dann sind beide Prozessinstanzen nach geringfügig mehr als 100 s fertig (gleiche Priorität vorausgesetzt). Der Overhead durch Task-Switching ist allgemein sehr gering.....ansonsten könnte man mit einem Single-Core System mit vielen parallelen Anwendune nicht gescheit arbeiten ;)
Obwohl eine Anwendung nach 50s fertig sein könnte. Und warum soll ich dann parallelisieren wenn ich langsamer werde. Ich würde ja Prozess 1 nach 60s und Prozess 2 nach 120s akzeptieren, da hat man wenigstens von einem schon die Antwort schneller als ohne Parallelisierung.
Wie schnell sind denn dann 4 Anwendungen mit je 2 Threads auf einem DualCore 400s oder 200s??
Seraf
2006-11-24, 09:48:34
Lies dir den Text auf deiner verlinkten Seite nochmal genau durch, du hast da nämlich was durcheinandergewürfelt. Die angegebenen 8,4 µs (Minimum) bzw. 10,6 µs (Durchschnitt) sind nicht der Intervall, sondern die Dauer (also quasi der Overhead) für einen Kontextwechsel. Die Zeitscheiben sind mindestens 1 ms lang, das steht sogar direkt hinter deiner gequoteten Stelle.
Ich meinte auch die Dauer eines Kontextwechsels und nicht die Dauer einer Zeitscheibe. Das ist ja der Vorgang der das Programm unterbricht (speichert oder zurückschreibt). Und der kostet fast keine Zeit.
Aber ich hab mich natürlich verlesen. Die Frage war mit welcher Taktrate Kontextwechsel ausgeführt werden.
The_Invisible
2006-11-24, 10:40:11
Genau, andere Betriebssysteme verhalten sich total anders *lol*
http://lists.suse.com/archive/suse-linux/1999-Sep/0049.html
Ist zwar von 99, aber trotzdem sollte sich an diesem Verhalten nichts geändert haben, da es das normale Verhalten sein sollte. Kein Programm läuft dauerhaft auf einem Core. Es ist auch nicht unnatürlich das Windows ein Programm unterbricht. Das machen alle Betriebssysteme die einen Task Scheduler haben irgendwann. Und wenn das Programm wieder laufen darf wird es eben auf dem Prozessor laufen gelassen der gerade frei ist.
1999 gabs noch keinen 2.6er kernel, und da wurde der scheduler mächtig überarbeitet -> http://www-128.ibm.com/developerworks/linux/library/l-scheduler/index.html . also komm nicht mit so uralten zeugs daher...
mfg
Seraf
2006-11-24, 11:05:30
Nach 200ms kann es dir trotzdem passieren das der Scheduler deinen Task auf eine andere CPU setzt:
To maintain a balanced workload across CPUs, work can be redistributed, taking work from an overloaded CPU and giving it to an underloaded one. The Linux 2.6 scheduler provides this functionality by using load balancing. Every 200ms, a processor checks to see whether the CPU loads are unbalanced; if they are, the processor performs a cross-CPU balancing of tasks.
A negative aspect of this process is that the new CPU's cache is cold for a migrated task (needing to pull its data into the cache).
...
It's unfortunate, but keeping the CPUs busy makes up for the problem of a CPU cache being cold for a migrated task.
Obwohl eine Anwendung nach 50s fertig sein könnte. Und warum soll ich dann parallelisieren wenn ich langsamer werde. Ich würde ja Prozess 1 nach 60s und Prozess 2 nach 120s akzeptieren, da hat man wenigstens von einem schon die Antwort schneller als ohne Parallelisierung.
Das andere Extrem: Du hast zwei Threads die du auf einer CPU ausführen willst (oder vier auf zwei, usw.). Thread A braucht 5 s wenn er alleine auf einer CPU läuft, B braucht 60 s. Das Betriebssystem kennt die Laufzeiten der Threads natürlich im Voraus nicht. Würde es jetzt nacheinander erst A, dann B ausführen, hättest du das erste Ergebnis nach 5 s, das zweite nach 65 s. Andersrum bekommst du das erste Ergebnis aber erst nach 60 s.
Werden die Threads abwechselnd in Zeitscheiben auf der CPU ausgeführt, bekommst du das erste Ergebnis immer nach 10 s, was im Schnitt deutlich besser ist.
Am Besten ist es natürlich wenn die Anwendung so viele "Worker-Threads" anlegt wie CPU-Kerne vorhanden sind und dann die Verteilung der Arbeit selbst nach den eigenen Bedürfnissen vornimmt. Dem OS fehlt hier einfach das entsprechende Wissen.
Wenn der Anwender mehrere Programme gleichzeitig bei gleicher Priorität laufen lässt, fordert er ja explizit parallele Ausführung, und das Betriebssystem sollte dann keinem Programm mehr Zeit zugestehen damit es schneller fertig ist.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.