Archiv verlassen und diese Seite im Standarddesign anzeigen : Dual-Cores: Vorteil der parallelität dahin, sobald software angepasst ist???
es wird ja ständig herausposaunt, dass man mit dualcores 2 belastende tasks laufen lassen kann, ohne dass die leistung allzusehr einbricht
wie wird das aussehen, sobald ensprechend angepasste software weit verbreitet ist?
dann wird doch ein spiel/task beide cores benutzen - ist dann der oben erwähnte vorteil dahin?!?
Demirug
2005-04-30, 20:35:46
Wenn die Anpassung gut ist Ja weil dann der eine "Task" beide Cores in Beschlag nimmt.
StefanV
2005-04-30, 20:37:14
Jap, dann wird dieser Vorteil schwinden, sofern beide Kerne stark ausgelastet sind.
GloomY
2005-04-30, 20:39:33
es wird ja ständig herausposaunt, dass man mit dualcores 2 belastende tasks laufen lassen kann, ohne dass die leistung allzusehr einbricht
wie wird das aussehen, sobald ensprechend angepasste software weit verbreitet ist?
dann wird doch ein spiel/task beide cores benutzen - ist dann der oben erwähnte vorteil dahin?!?Ein Prozess hat mindestens einen (Kernel-Level-) Thread (*), eventuell auch mehr. Zwei Prozesse haben somit mindestens zwei KLTs. Bei genau zweien kann man diese dann auf die zwei Prozessoren verteilen und diese mit voller Geschwindigkeit (jeweils eines Cores) ausführen.
Wenn man nun einen Prozess hat, welcher aus mehr als einem Thread besteht (z.B. zwei), kann man diese beiden Threads eben auch auf die beiden Prozessoren verteilen und damit die Berechnung eines einzigen Prozesses beschleunigen. Wenn du dann noch einen zweiten Prozess (mit mindestens einem Thread) dazunimmst, hast du mindestens drei Threads, die berechnet werden sollen. Das geht bei zwei Prozessoren nicht mit voller Geschwindigkeit. Um genau zu sein, wird dann die Benutzung der CPU nach einem Zeitmultiplex-Verfahren aufgeteilt.
(*) vorausgesetzt der Kernel unterstützt überhaupt Threads
Jap, dann wird dieser Vorteil schwinden, sofern beide Kerne stark ausgelastet sind.
Dafür wird dieser eine Task aber deutlich schneller ablaufen, als auf nur einem Core...
Oblivion
2005-05-01, 10:35:15
es wird ja ständig herausposaunt, dass man mit dualcores 2 belastende tasks laufen lassen kann, ohne dass die leistung allzusehr einbricht
wie wird das aussehen, sobald ensprechend angepasste software weit verbreitet ist?
dann wird doch ein spiel/task beide cores benutzen - ist dann der oben erwähnte vorteil dahin?!?
Dafür werden dann 4 Kerne in einem gegeben und danach 8 usw. :biggrin:
Dafür werden dann 4 Kerne in einem gegeben und danach 8 usw. :biggrin:
Auch Parallelisierung kennt ihre sinnvollen Grenzen.
Die Frage ist natürlich, bei welcher Anzahl Cores diese für die Mehrzahl an Software liegen wird.
Jap, dann wird dieser Vorteil schwinden, sofern beide Kerne stark ausgelastet sind.Jain. Der Scheduler von Win XP ist einfach beschissen. Da hilft ja auch schon HTT sehr viel um die Latenzen zu verkürzen, obwohl nicht viel mehr an Leistung da ist eigentlich.
Oblivion
2005-05-01, 12:51:59
Auch Parallelisierung kennt ihre sinnvollen Grenzen.
Die Frage ist natürlich, bei welcher Anzahl Cores diese für die Mehrzahl an Software liegen wird.
Tja - ich werd mal meine Kristallkugel holen :wink:
aber ich denk mal, wenn die DC kommen werden sie dafür programmieren wenn 4 Cores kommen dann für 4 usw., da wirds keinen "Standart" geben
damit machen sie ja keinen schlechten Gewinn :wink:
Standard
Und wenn man ein Program für Threads anpasst, dann macht man es gleich so dass man beliebig viele laufen lassen kann.
Standard
Und wenn man ein Program für Threads anpasst, dann macht man es gleich so dass man beliebig viele laufen lassen kann.
Das ganze findet seine Grenzen wenn die ganzen Sachen voneinander abhängig sind. Solange das nicht so ist, kann man nach Herzenslust neue Threads machen. Das ganze wird aber schon in dem moment Arg, wenn nicht mehr frei aufteilen kann. Ein Beispiel wäre ein Shooter der die AI auf die 2te CPU auslagert. Ansich ne coole Sache, aber wenn auf der 2ten CPU irgendein fetter Prozeß (transskodieren/rendern)läuft dann hat man die Ar...-Karte gezogen.
Ich muß allerdings sagen, das diese Probleme wenig relevant sind. Ein Video kann ich auch dann trankodieren, wenn ich nicht am Rechner bin und ich würde mal schätzen das normalerweise ein Rechner mindestens 12 Stunden am Tag nicht beschäftigt ist. Man muß nur etwas planen, wann was laufen soll.
Bei Spielen läuft normalerweise nur Kleinkram im Hintergrund: Teamspeak und vieleicht noch ein e-mule, icq und e-mail, firewall, und Virenscanner. Das sind alles nicht die Leistungsfresser. Damit steht praktisch die volle Leistung dem Spiel zur Verfügung.
Die Dualcore Vorteile nutzen meist nur Progger (kompilieren im Hintergrund) und Leute die Video und Grafik Sachen machen (rendern im Hintergrund).
BTW: kann man nicht Prozesse sozusagen auf einer CPU "einsperren". Der Läuft dann langsamer, aber bei Hintergrundprozessen ist Geschwindigkeit ja eh nicht die höchste Priorität.
mapel110
2005-05-01, 15:05:17
Dafür werden dann 4 Kerne in einem gegeben und danach 8 usw. :biggrin:
Jo, und das vorallem bevor es breitflächig Dual/Multi-Core-fähige Software gibt.
GloomY
2005-05-01, 23:14:06
Dafür werden dann 4 Kerne in einem gegeben und danach 8 usw. :biggrin:Auch ThreadLevel Parallismus hat irgendwo seine Grenzen. Je nach Anwendung kann das sehr unterschiedlich sein.
Davon abgesehen wird man die Rechenzeit bei n Cores nie mit 2*n Cores auf exakt die Hälfte drücken können, weil a) Synkronisationsaufwand und b) quasie immer ein kleiner Anteil an nicht parallel ausführbarem Code vorhanden ist.
Das führt nach Amdahl's Law dazu, dass der Speedup mit zunehmender Anzahl an Cores nicht linear ansteigt. Irgendwann ist dann die Skalierung so schlecht, dass es sich kaum noch lohnt.
Wann dieser Punkt allerdings erreicht wird, ist eine ganz andere Frage.
SentinelBorg
2005-05-02, 11:27:16
Ich beschäftige mich auch gerade beruflich mit Multithreading. Und naja, das ist echt die Hölle. Zuerst einmal musst du überhaupt was haben, was brauchbar parallel laufen kann. Ok, solange der Thread dann nur alleine vor sich hin dudelt, bis er dann irgendwann mal fertig ist und nen Callback aufruft, ist alles noch einfach. Schlimm wirds dann, wenn Threads auf gleiche Objekte zugreifen oder gar mehrere Threads die gleiche Funktion nutzen. Dann musst du das ganze überwachen, Synclocks setzen, wieder freigeben, weitergeben usw...
Und dabei bekommst du immer weniger brauchbare Informationen vom Debugger. Denn solange ein Programm schön seriell läuft, kannst du den Code gut nachvollziehen und Fehler leicht finden. Aber wenn dann an jeder Ecke was anderes parallel läuft und das bei jedem Durchgang, je nachdem wie der Scheduler den Threads grad Prozessorzeit zuweisst, auch noch in unterschiedlicher Reihenfolge (wenn man überhaupt von Reihenfolge sprechen kann), da verliert man ganz schnell den Überblick.
Lest euch mal das hier durch: The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software (http://www.gotw.ca/publications/concurrency-ddj.htm)
Da sieht man schön, dass man sich von dem Gedanken, Dual-Core = doppelte Leistung einer Applikation, wirklich verabschieden kann. In vielen Fällen ist dies einfach nicht sinnvoll umzusetzen.
Dennoch hat so eine DC natürlich schon seine Vorteile, vor allem wenn man auch zweie Monitore hat :D Da läuft dann auf dem einen z.B. WoW und auf dem anderen die DVD-S Software mit einem HDTV Kanal :P
Sentinel
mapel110
2005-05-02, 11:36:09
viel Text
Sind Debugger eigentlich ausgereift, was parallelen Code angeht?! Dürfte wohl der Fall sein, weil es ja schon sehr lange Dual CPU-Systeme gibt. Oder gibts da noch größere Unterschiede zu Dual Core-CPUs?
StefanV
2005-05-02, 11:41:47
Nein, der Unterschied zwischen einem SMP System und einer Dual Core CPU ist äußerst gering, beim K8.
Beim P4 ists das gleiche, nur die Verpackung ist unterschiedlich...
SentinelBorg
2005-05-02, 12:09:25
Sind Debugger eigentlich ausgereift, was parallelen Code angeht?! Dürfte wohl der Fall sein, weil es ja schon sehr lange Dual CPU-Systeme gibt. Oder gibts da noch größere Unterschiede zu Dual Core-CPUs?
Ob das OS die Threads dann auf einer oder auf zwei oder mehr CPUs laufen lässt, davon bekomm ich jetzt zumindest in .NET nicht viel mit. Und ob HT, Dual-Core oder zwei echte CPUs, ist für den Programmierer prinzipiell auch lang wie breit. Das meiste in Sachen Multithreading passiert ja sowieso auf Betriebssystemebene, wobei selbst das OS nicht zwischen Dual-Core und zwei CPUs unterscheiden muss und je nachdem auch nicht kann. HT ist da wieder bissel spezieller.
Aber mit VisualStudio gehts schon so halbwegs, ich kann im Debugger zwischen den Threads wechseln und mir dann anschauen was er macht. Nur wenn dann zich Threads laufen und du das noch verfolgen willst, da platzt dir dann irgendwann der Schädel :P
Sentinel
Bei Spielen läuft normalerweise nur Kleinkram im Hintergrund: Teamspeak und vieleicht noch ein e-mule, icq und e-mail, firewall, und Virenscanner. Das sind alles nicht die Leistungsfresser. Damit steht praktisch die volle Leistung dem Spiel zur Verfügung.
e-mule frisst ne ganze menge ....mein xp 2400 packt das jedenfalls nicht, gleichzeitig noch ein spiel laufen zu lassen ...
dafür wär dualcore schon cool
GRiNSER
2005-05-08, 18:29:26
e-mule frisst ne ganze menge ....mein xp 2400 packt das jedenfalls nicht, gleichzeitig noch ein spiel laufen zu lassen ...
dafür wär dualcore schon cool
da läuft aba schon wenig was verkehrt? bei mir stören hintergrundprogramme überhaupt net...
da läuft aba schon wenig was verkehrt? bei mir stören hintergrundprogramme überhaupt net...
meinte auch nur emule ...alle andern stören nicht. Dein System ist auch etwas schneller ...
Emule verursacht bei mir ca. 10% CPU-Last ....der rest ist wohl für ein flüssiges Zocken eines aktuellen Games zu wenig...
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.