News Vista: Bescheidene Multithreading-Fähigkeiten
- Ersteller Parwez
- Erstellt am
- Zur News: Vista: Bescheidene Multithreading-Fähigkeiten
baal666
Ensign
- Registriert
- März 2001
- Beiträge
- 217
1. Fähigkeiten
2. Aufwand/Kosten
Fazit: lohnt nicht für 08/15 Programme, außer der Aufwand wird drastisch reduziert. Mit Gewohnheit hat dies in der Regel also überhaupt nichts zu tun. Hyperthreading und "64Bit-Performance", das sind Dinge die man eben Kiddies für gutes Geld verscherbeln kann, im Profi-Bereich muß es schon wirkliche Leistung sein und auch nur dort ist man bereit dafür die entsprechenden Kosten zu tragen. Wer davon träumt in naher Zukunft seine Spiele tatsächlich *optimiert* auf mehreren CPUs laufen zu sehen, der ist noch nicht wirklich erwachsen. Dies wird erst passieren, wenn der Aufwand dafür gen 0 geht, sprich die Kosten nicht mehr der Rede wert sind. Ansonsten wäre es schlicht ein massives Verlustgeschäft, das sich bei der Schnelllebigkeit des Markts nicht rentiert, allenfalls mit der Zeit bei Konsolen. Grundproblem der kaufwilligen Spielen "sie glauben etwas zu bemerken", sie *wissen* es jedoch nicht. Wissen kann man es nur, kennt man a) den Quellcode und hat b) Ahnung von der Materie was unterhalb von mind. BA computer science hier wohl nicht zu erwarten ist.
Es ist immer wieder amüsant zu sehen, wie das Forum und der Rest allmählich den Bach runter gehen. Dabei hatte Tommy damals mal wirklich gute Ansätze. Das Gros der Leute liest heute nicht von ungefähr lieber bei der ausländischen *Presse*.
tochan01
Rear Admiral
- Registriert
- Mai 2007
- Beiträge
- 5.157
langsam geht es ja los das einige spiele 2cores + benutzen werden. grad die großen studios die durch den lizensverkauf der engine geld machen wollen, können es sich nicht wirklich erlauben die enigne nicht dahin zu optmieren / programmieren. dazu zählt die Unreal 3 engine, die Crysis engine und auch die neue / angepasste source engine soll die CPU mehr / besser nutzen.
grad bei von der unreal engine könnte man einiges erhoffen da diese auch für den CELL angepasst wird und dieser hat je bekannter maßen 7 CPU kerne. Allen Awake oder wie das nochma heißt ist sogar das "vorzeigespiel" von intel wenn es um mehr kern power bei games geht. langsam geht los. heutzutage kann sich kaum ein keines studio erlauben eine eigene engine zu coden wenn die spiele mit den großen mithalten sollen. das geht meist nur über lizenz und da wollen die anbieter der konkurenz ja nix schenken.
grad bei von der unreal engine könnte man einiges erhoffen da diese auch für den CELL angepasst wird und dieser hat je bekannter maßen 7 CPU kerne. Allen Awake oder wie das nochma heißt ist sogar das "vorzeigespiel" von intel wenn es um mehr kern power bei games geht. langsam geht los. heutzutage kann sich kaum ein keines studio erlauben eine eigene engine zu coden wenn die spiele mit den großen mithalten sollen. das geht meist nur über lizenz und da wollen die anbieter der konkurenz ja nix schenken.
@baal666
Im Bezug auf Spiele sei anzumerken, dass die Entwickler der jeweiligen Engine die Hauptarbeit zu leisten haben. Beispielsweise hat Valve bereits Mehrkernunterstützung für die kommende Source Engine angekündigt, was somit für darauf basierende Projekte selbige Unterstüzung ohne Mehraufwand mitbringt.
Inwieweit Entwickler das Mehr an verfügbarer Leistung schlussendlich umzusetzen wissen, müssen wir wohl abwarten. Schliesslich braucht es Zeit, neue Features in die Entwicklung einfliessen zu lassen. Ausserdem werden Spiele auf Plattformen ausgelegt, die breit verfügbar sind, sodass Systeme mit Doppel- und Vierkernprozessoren erst eine entsprechende Marktdurchdringung erreichen müssen.
Als Spieler muss man aber keinesfalls den Sourcecode kennen oder Fachkenntnisse mitbringen. Ein schlichter Benchmarkvergleich zeigt, ob ein Spiel tatsächlich von mehreren Kernen profitiert und ob es sinnvoll ist, auf entsprechende Prozessoren zu wechseln. Ebenso zeigt sich ja hierdurch, wie effektiv kommende Spiele DirectX 10 zu nutzen wissen.
Deine Anmerkung im Bezug auf die Forenqualität ist übrigens überflüssig. Wenn Du so umfassend ausgebildet und mit Kenntnissen ausgestattet bist, hast Du es bestimmt nicht notwendig, die vielen interessierten Leser so herabzusetzen, die sich in den Foren tummeln. Bei der 'ausländischen Presse' sieht das sicher nicht anders aus.
Im Bezug auf Spiele sei anzumerken, dass die Entwickler der jeweiligen Engine die Hauptarbeit zu leisten haben. Beispielsweise hat Valve bereits Mehrkernunterstützung für die kommende Source Engine angekündigt, was somit für darauf basierende Projekte selbige Unterstüzung ohne Mehraufwand mitbringt.
Inwieweit Entwickler das Mehr an verfügbarer Leistung schlussendlich umzusetzen wissen, müssen wir wohl abwarten. Schliesslich braucht es Zeit, neue Features in die Entwicklung einfliessen zu lassen. Ausserdem werden Spiele auf Plattformen ausgelegt, die breit verfügbar sind, sodass Systeme mit Doppel- und Vierkernprozessoren erst eine entsprechende Marktdurchdringung erreichen müssen.
Als Spieler muss man aber keinesfalls den Sourcecode kennen oder Fachkenntnisse mitbringen. Ein schlichter Benchmarkvergleich zeigt, ob ein Spiel tatsächlich von mehreren Kernen profitiert und ob es sinnvoll ist, auf entsprechende Prozessoren zu wechseln. Ebenso zeigt sich ja hierdurch, wie effektiv kommende Spiele DirectX 10 zu nutzen wissen.
Deine Anmerkung im Bezug auf die Forenqualität ist übrigens überflüssig. Wenn Du so umfassend ausgebildet und mit Kenntnissen ausgestattet bist, hast Du es bestimmt nicht notwendig, die vielen interessierten Leser so herabzusetzen, die sich in den Foren tummeln. Bei der 'ausländischen Presse' sieht das sicher nicht anders aus.
1
1668mib
Gast
Kann mir einer sagen, warum man hier direkt eine (ab)wertende Überschrift verwenden muss, anstatt wie die Quelle eine neutrale? In Computerbase sieht es ja fast nach Vergangenheitsbewältigung aus, die Quelle wirft den Blick in die Zukunft, was auch aus meiner Sicht deutlich sinnvoller ist.
Ach btw: Glückwunsch, nen 5 Tage alten Artikel nochmals ausgegraben zu haben...
Ach btw: Glückwunsch, nen 5 Tage alten Artikel nochmals ausgegraben zu haben...
kabe1brand
Lt. Junior Grade
- Registriert
- März 2007
- Beiträge
- 362
kann dem zustimmen dass sich zukünftige versionen unterscheiden müssen. hatte bei dieser news meinen allerersten (nicht auf dummheit selbst erzeugten) bluescreen mit meinem system seit ich es habe (3 moante), weil ich bei winamp auf play gedrückt habe und nach 2 sekunden musik "bluescreen"...
soviel multithreading sollte windows doch verkraften oder ?
soviel multithreading sollte windows doch verkraften oder ?
Tronx
Captain
- Registriert
- Okt. 2002
- Beiträge
- 3.417
Newstitel schlecht ausgewählt, zum Glück haben aber einige hier schon beschrieben wo das Problem zu suchen ist, Vista wird und kann mit mehr als 8 Kernen sehr gut umgehen. Die Frage stellt sich, wie gut sind die Coder am werke um die Last auch gut zu Verteilen, das wird nicht unbedingt die Aufgabe von Vista selbst sein, sofern es nur ein Programm ist. Wenn man nun z.B. 20 Programme anmachen würde und man nutzt 16 Kerne, lediglich da könnte Vista ein Problem haben die Lasten richtig zu verteilen.
Kein Problem= ein Programm das seinen eigenen Scheduler bringt
Problem(könnte, muss aber nicht)=wenn ich 20 mal Photoshop anmache und alle Rechnen lasse
und zuletzt, alles ist optimierbar durch SP-x von MS
Niemand brauch im privaten Bereich, in den nächsten 4 Jahren, mehr als 8 Kerne, alles andere wäre nur im Sinne der Hersteller um Geld zu machen.
Kein Problem= ein Programm das seinen eigenen Scheduler bringt
Problem(könnte, muss aber nicht)=wenn ich 20 mal Photoshop anmache und alle Rechnen lasse
und zuletzt, alles ist optimierbar durch SP-x von MS
Niemand brauch im privaten Bereich, in den nächsten 4 Jahren, mehr als 8 Kerne, alles andere wäre nur im Sinne der Hersteller um Geld zu machen.
Zuletzt bearbeitet:
Rasemann
Banned
- Registriert
- Juli 2006
- Beiträge
- 2.760
Jetzt sollen erst einmal Anwendungen(SPIELE!) Dualcore ordentlich unterstützen.
Was kann das BS dafür wenn die Software das nicht kann?
Außerdem laufen eh zig Programme gleichzeitig.
Virenscanner, diverse Treiber, Internet,....da wird keinem Kern fad.
Was kann das BS dafür wenn die Software das nicht kann?
Außerdem laufen eh zig Programme gleichzeitig.
Virenscanner, diverse Treiber, Internet,....da wird keinem Kern fad.
katanaseiko
Lt. Commander
- Registriert
- Feb. 2006
- Beiträge
- 1.485
Also ich hätte nicht mal etwas dagegen, wenn Windows selbst und ein paar kleinere Programme mal nur einen der Kerne nutzen würden und bei mir der zweite bzw. irgendwann auch mehrere komplett für leistungshungrigere Anwendungen zur Verfügung stünden... Bisher ist es aber so, dass Windows selbst einen ganzen Haufen Arbeit für das Aufteilen der Threads aufwendet, und dabei dann auch von diesen beiden Cores Leistung abzweigt...
Fällt mir jetzt nur eines zu ein: ACH NE! Für 2 Cores braucht man noch gar kein Multithreading für eine deutliche Leistungssteigerung, hier reicht es, den die Leistung beanspruchenden Prozess auf einen und alles andere auf den anderen Core zu verfrachten - so profitieren selbst Steinzeit-Programme. Bei 4 Cores wird es dann schon schwieriger, dass einige Spiele sogar langsamer werden, sollte aber nicht sein, sondern spricht für ein schlecht optimiertes Betriebssystem, dessen eigener Rechenaufwand offenbar schneller steigt, als die Zahl der Kerne. Bei 8 Kernen sage ich mit Gewissheit voraus, dass vorerst KEIN Spiel gegenüber einen Quadcore einen noch so winzigen Vorteil haben wird, nicht einmal welche bei denen Grafik und KI unabhängige Threads sind! Erst noch wesentlich weitere Aufteilungen - die den Aufwand bei der Programmierung dann massiv erhöhen - werden davon profitieren. Mit anderen Worten: Dualcore macht immer Sinn, Quadcore wenn die Spiele darauf angepasst sind (bisher nahezu nie), mehr wohl nur mit _wesentlichen_ Änderungen im Entwicklungskonzept.
Anders sieht es natürlich bei Aufgaben auf, die per se Multithreading machen - das sind Rendering-Programme (hier übernimmt jeder Thread einen Bildteil - auf Spiele kaum übertragbar, da dort ja alle zugleich fertig sein müssten) und Server-Anwendungen (jeder Thread bedient einen "Kunden"). Übrigens rechnet man bei Server-Systemen (auch Linux oder MacOS [BSD-Kern!]), dass etwa jeder 32ste (!) Kern für Verwaltungsaufwand für das SMP drauf geht...
Anders sieht es natürlich bei Aufgaben auf, die per se Multithreading machen - das sind Rendering-Programme (hier übernimmt jeder Thread einen Bildteil - auf Spiele kaum übertragbar, da dort ja alle zugleich fertig sein müssten) und Server-Anwendungen (jeder Thread bedient einen "Kunden"). Übrigens rechnet man bei Server-Systemen (auch Linux oder MacOS [BSD-Kern!]), dass etwa jeder 32ste (!) Kern für Verwaltungsaufwand für das SMP drauf geht...
Ich kann "Thek" und "Voyager10" nur zustimmen (vielleicht auch noch einige andere, laß nicht alle Threads :-) )
Vorallem sollte man sich einmal die Gedanken machen, wie schwer man im PC-, Home-Bereich 8 Kerne oder mehr handlen kann. Beziehungsweise welchen Sinn sollte es ergeben die einzelnen Threads auf mehr als 4 oder von mir aus 8 Kernen aufzuteilen? Für Office und Spiele ziemlich sinnlos. Außer man bevorzugt für jeden Prozess einen eigenen Kern (Für die Windows Update Funktion würde ich dann aber überhaupt zwei Kerne empfehlen *gg*)
Auch für semiprofessionelle Videobearbeitung ist die Leistung der heutigen CPUs mehr als ausreichenend.
Vorallem kann man den PC in seiner Funktion ansich nicht mit irgendwelchen Clusterservern oder Großrechnern vergleichen. Nicht einmal mit Workstations, wo ja die Multicore Architektur sinnvoll eingesetzt werden kann...
Vorallem sollte man sich einmal die Gedanken machen, wie schwer man im PC-, Home-Bereich 8 Kerne oder mehr handlen kann. Beziehungsweise welchen Sinn sollte es ergeben die einzelnen Threads auf mehr als 4 oder von mir aus 8 Kernen aufzuteilen? Für Office und Spiele ziemlich sinnlos. Außer man bevorzugt für jeden Prozess einen eigenen Kern (Für die Windows Update Funktion würde ich dann aber überhaupt zwei Kerne empfehlen *gg*)
Auch für semiprofessionelle Videobearbeitung ist die Leistung der heutigen CPUs mehr als ausreichenend.
Vorallem kann man den PC in seiner Funktion ansich nicht mit irgendwelchen Clusterservern oder Großrechnern vergleichen. Nicht einmal mit Workstations, wo ja die Multicore Architektur sinnvoll eingesetzt werden kann...
Microarchitekt
Lieutenant
- Registriert
- Juli 2006
- Beiträge
- 517
Hier scheinen einige verschiedene Aspekte und Umgebungen durcheinander zu bringen. Das Problem des echten Multitasking bzw. -threading teilt sich in zwei Bereiche auf. Zum einen der Bereich des Betriebssystem mit seinem Kernel und den darauf aufbauenden Anwendungsprogrammen.
Betriebssystem / Kernel:
Diesem ist eigentlich weitgehend egal, wieviele Threads ein Anwendungsprogramm erzeugt. Für den Scheduler des Kernel ist es nur in soweit von Bedeutung, dass dieser die Rechenleistung der verschiedenen Kerne optimal auf alle Threads verteilt. Wichtig ist für den Scheduler noch, dass keine blockierten Threads, die auf Ergebnisse anderer Threads warten, in den aktuellen Verteilzyklus kommen. Schreibt man nun einen Scheduler für Multikernprozessoren, so müssen dort mehr Informationen bereitgestellt werden als bei einem Einzelkernprozessor. Man will ja eine optimale Lastverteilung. Dies führt aber zu mehr durchzuführenden Entscheidungen, weshalb der Scheduler mehr Zeit benötigt. Da der Scheduler aber eine der zentralen Bestandteile eines Kernel ist, bemerkt man einen langsameren Scheduler auch bei der Abarbeitung der Anwendungsprogramme.
Anwendungsprogramm:
Dies kann man nicht einfach auf Multithreading umschreiben, nur weil man auf einmal mehrere Prozessorkerne zur Verfügung hat. Das Programm muss auch dafür geeignet sein. Es wurde hier ja schon auf Bild- und Videobearbeitung hingewiesen. Dies sind Gebiete, wo man sehr gut parallelisieren kann. Aufteilen auf mehrere Threads lassen sich vor allem Schleifen in den Programmen. Wo man bisher z.B.
int irgendwas()
{
for(unsigned int i = 0;i < 2^30;i++)
// Irgendetwas
}
geschrieben hat, kann man nun
int irgendwas()
{
#pragma omp parallel for
for(unsigned int i = 0;i < 2^30;i++)
//Irgendetwas
}
schreiben. Wenn die Schleife ohne if-Anweisungen abläuft halbiert sich die Abarbeitung etwa. Bei Spielen sollte man die Hoffnung auf schnellere Programme nicht zu hoch setzen. Die Interaktion erfolgt linear. Da kommt eigentlich nur der Bereich der Kollisionskontrolle in Betracht, sofern dies nicht von der GPU gemacht wird.
Betriebssystem / Kernel:
Diesem ist eigentlich weitgehend egal, wieviele Threads ein Anwendungsprogramm erzeugt. Für den Scheduler des Kernel ist es nur in soweit von Bedeutung, dass dieser die Rechenleistung der verschiedenen Kerne optimal auf alle Threads verteilt. Wichtig ist für den Scheduler noch, dass keine blockierten Threads, die auf Ergebnisse anderer Threads warten, in den aktuellen Verteilzyklus kommen. Schreibt man nun einen Scheduler für Multikernprozessoren, so müssen dort mehr Informationen bereitgestellt werden als bei einem Einzelkernprozessor. Man will ja eine optimale Lastverteilung. Dies führt aber zu mehr durchzuführenden Entscheidungen, weshalb der Scheduler mehr Zeit benötigt. Da der Scheduler aber eine der zentralen Bestandteile eines Kernel ist, bemerkt man einen langsameren Scheduler auch bei der Abarbeitung der Anwendungsprogramme.
Anwendungsprogramm:
Dies kann man nicht einfach auf Multithreading umschreiben, nur weil man auf einmal mehrere Prozessorkerne zur Verfügung hat. Das Programm muss auch dafür geeignet sein. Es wurde hier ja schon auf Bild- und Videobearbeitung hingewiesen. Dies sind Gebiete, wo man sehr gut parallelisieren kann. Aufteilen auf mehrere Threads lassen sich vor allem Schleifen in den Programmen. Wo man bisher z.B.
int irgendwas()
{
for(unsigned int i = 0;i < 2^30;i++)
// Irgendetwas
}
geschrieben hat, kann man nun
int irgendwas()
{
#pragma omp parallel for
for(unsigned int i = 0;i < 2^30;i++)
//Irgendetwas
}
schreiben. Wenn die Schleife ohne if-Anweisungen abläuft halbiert sich die Abarbeitung etwa. Bei Spielen sollte man die Hoffnung auf schnellere Programme nicht zu hoch setzen. Die Interaktion erfolgt linear. Da kommt eigentlich nur der Bereich der Kollisionskontrolle in Betracht, sofern dies nicht von der GPU gemacht wird.
Microarchitekt schrieb:
Das ist genau das Problem von SMP. Da es keinen eigentlichen "Master" Kern gibt müssen alle Kerne synchronisiert werden. Das gilt für den Sheduler ebenso wie für die Resourcen. Bei "wenig" Kernen (bis ca .8 ) ist das noch nicht so tragisch, aber dann wird es immer problematischer.
AMP ist bei mehr Kernen (ab 8 Kerne) einfach wesentlich performanter.
gozoc
Ensign
- Registriert
- Okt. 2004
- Beiträge
- 133
Wenn M$ doch mal endlich mal echtes Multitasking könnte ... geht nämlich seit Win95 nicht ... weder bei Vista, noch Longhorn ...
Wer echtes preemtives Multitasking will, muss Linux, Unix, OS/2 (schon Mitter der 90er konnten die das) oder Novell nehmen ... eben echte Betriebssysteme .... :-)
Traurig, ist aber eben so ...
Wer echtes preemtives Multitasking will, muss Linux, Unix, OS/2 (schon Mitter der 90er konnten die das) oder Novell nehmen ... eben echte Betriebssysteme .... :-)
Traurig, ist aber eben so ...
MountWalker
Fleet Admiral
- Registriert
- Juni 2004
- Beiträge
- 14.368
@ gozoc
Die Windows-NT-Reihe konnte schon immer echtes präemptives Multitasking und zwar seit sie sich von OS/2 abgespalten hat, also seit ihrer Geburt als Forschungsprojekt 1991. Die Endprodukte Windows NT 3.x, Windows NT 4.0, Windows 2000 (NT 5.0), Windows XP (NT 5.1), Windows Server 2003 (NT 5.2) und Windows Vista (NT 6.0) können alle echtes präemptives Multitasking.
Die Windows-NT-Reihe konnte schon immer echtes präemptives Multitasking und zwar seit sie sich von OS/2 abgespalten hat, also seit ihrer Geburt als Forschungsprojekt 1991. Die Endprodukte Windows NT 3.x, Windows NT 4.0, Windows 2000 (NT 5.0), Windows XP (NT 5.1), Windows Server 2003 (NT 5.2) und Windows Vista (NT 6.0) können alle echtes präemptives Multitasking.
Zuletzt bearbeitet:
Jeder, der programmiert, wird mir wohl zustimmen, wenn ich sage, dass es gar nicht so einfach ist mit mehreren Threads zu arbeiten. Ein großteil der Arbeiten lässt sich einfach nur bescheiden parallelisieren. Deshalb finde ich es auch nicht verwunderlich, dass viele Programme einfach nur mit einem Thread arbeiten. Aufwand/Nutzen ist einfach zu schlecht.
tha_specializt
Cadet 3rd Year
- Registriert
- Feb. 2007
- Beiträge
- 32
nö ... Threads sind sehr leicht einzubacken, ich starte selbst in meinem kleinem CMS mehrere gleichzeitig .... klappt wunderbar und war auch schnell erledigt. Viel komplexer war da schon die gewollte Kontinuität von TCP-Verbindungen, ich habs dann mit einem schlafenden Thread gelöst. In Version 2 werden sich die Threads gegenseitig aufwecken und schlafen legen, aber zuerst muss ich mal OOP anwenden und im Quelltext ordentlich aufräumen. Offensichtlich bist du kein Programmierer, denn Threads und co sind mit das leichteste, die PARALLELISIERUNG selbiger ist ein _ganz_ anderes Thema, was du offensichtlich nicht weisst ;-). Aber auch das stelle ich mir _machbar_ vor, man müsste eben einen Scheduler hochziehen ... werd ich unbedingt mal testen, aber dafür brauch ich erstmal einen MultiCore-CPU o.0
Zuletzt bearbeitet:
