Frage zu DualCore Kompatiblität für Spiele der Zukunft

[TITAN>Steel]

Hallo,

ich habe Fragen an Euch,

Ich habe gehört, dass DUAL CORE CPUs von Games unterstützt werden müssen
dh. sie müssen, ähnlich wie mmx, 3dnow, sse optimiert werden, außerdem
habe ich gehört, dass ein dual core cpu nicht kompatibel zu einen quad
oder oct cpu seien wird... Was nicht für Dual CPUs gillt, welche 2 sockel
bzw. 4, 8 oder 16 sockel auf dem Board haben, sondern nur für solche, die
4, 8, oder 16 Cores auf einem DIE haben...

Wenn diese Info stimmt, dann würde das bedeuten, wenn man davon ausgeht,
dass 4 Ghz pro core aufn DIE das maximum sind, die komplette Software,
welche, bekanntlich, eine gigantische Vielfalt, M$, bestitzt in den nächsten
drei jahren 4x angepasst werden müssen, nämlich für dualcore, für quadcore,
für Octcore usw....

Kann ja auch sein dass es eine Felinformation ist und damit hinfällig...


thx @ all,


mfg TITANsteel

[Muh-sagt-die-Kuh]

Damit ein Programm von 2 oder mehr CPU-Kernen profitiert, muss es multithreaded sein. Dies bedeutet, dass zwei oder mehr möglichst unabhängige Programmstränge parallel ablaufen. Parallelisierung von Code und Synchronisation von Thread sind aber trotz Frameworks kein leichtes Unterfangen und kosten bei der Entwicklung viel Zeit.

Die zweite Aussage verstehe ich so nicht. Ist Hardware- oder Software-Kompatibilität gemeint? Auf Software-Seite (Betriebssystem-Sicht) macht es auf jeden Fall keinen Unterschied, ob nun 4 Kerne in einem Sockel sitzen oder je 1 Kern in 4 Sockeln.

[HOT]

In Zukunft werden alle Multiplatformtitel von DualCore profitieren, da die neue Konsolengeneration auch mehrkernig ist. Auch PC Titel, die angekündigt sind werden Multithreaded entwickelt, z.B. Epic mit der neuen Unreal Engine und ihrem neuen UT. Auch zukünfitge MMORPGs werden Multithreaded sein, solche Sachen wie Flashpoint2 sicherlich auch.

[GloomY]

Aus Softwaresicht ist es einfach nur entscheidend, wie viele Threads das Programm zur parallelen Ausführung benutzt und wie viele Cores insgesamt zur Verfügung stehen. Ob diese Cores nun auf einem Die sitzen (Dual- oder Quad-Core etc.) oder auf mehreren Sockeln (Multiprozessorsysteme) ist hier egal.
Man verteilt Threads auf Cores. So einfach ist das ;)

[SentinelBorg]

Die Threads selbst verwaltet der Scheduler des Betriebssystems und verteilt sie dann auf die CPUs. Der Softwareentwickler selbst hat da nur begrenzt Einfluss darauf. Das macht die Sache äusserst kompleziert, da die Threads je nachdem immer wieder in unterschiedlicher Reihenfolge ausgeführt werden.

Habe ich also z.B. zwei Threads mit je 4 Anweisungen und nur einen Prozessor, dann kann die Reihenfolge des Ablaufs mal (T1/1, T1/2, T1/3, T2/1, T2/2, T1/4, T2/3, T2/4) oder auch mal (T1/1, T2/1, T2/2, T1/2, T1/3, T2/3, T2/4) sein.
Bei zwei Prozessoren können dann die Threads auch parallel laufen, aber dabei sind die Cores nicht wirklich fest zugeordnet. Der Scheduler teilt einfach immer den Threads Prozessorzeiten zu, bei mehreren Cores hat er dann halt mehrere Quelle für diese. So kann die erste Hälfte von Thread 1 durchaus auf Core 1 laufen und die zweite auf Core 2.
Das ganze ist für den Entwickler also kaum vorhersehbar, weil zich Faktoren hier Einfluss drauf haben. Zudem kann man den Arbeitsweise des Schedulers auch noch weitreichend konfigurieren.
Letztendlich muss man also enormen Aufwand für die Synchronisation des ganzen betreiben.

Sentinel

[BlackBirdSR]

Hallo,

ich habe Fragen an Euch,

Ich habe gehört, dass DUAL CORE CPUs von Games unterstützt werden müssen
dh. sie müssen, ähnlich wie mmx, 3dnow, sse optimiert werden, außerdem
habe ich gehört, dass ein dual core cpu nicht kompatibel zu einen quad
oder oct cpu seien wird... Kann ja auch sein dass es eine Felinformation ist und damit hinfällig...


thx @ all,


mfg TITANsteel

Da es jetzt mitunter doch recht verwirrend geworden sein könnte:

Spiele müssen Multithreaded programmiert sein. D.h der Entwickler muss vorsehen, dass verschiedene Teile des Programms aufgeteilt werden, so dass sie von verschiedenen Kernen gleichzeitig bearbeitet werden können.

In wieviele dieser sogenannten "Threads" ein Programmierer seine Engine zerlegt, ist ihm und seinem Können überlassen.
Sobald es auch nur 2 Threads gibt, profitieren alle CPUs mit mehr als einem Kern.
Das gilt auch für Quad und Octa Systeme. Allerdings können diese ihre maximale Leistung nur entfalten, wenn es genügend Threads gibt.

Ein Programm mit 2 Threads wird auch auf einer Quad CPU nur von 2 Kernen abgearbeitet werden können.

Man muss die Software also nicht neu anpassen um sie lauffähig zu halten.
Es ist aber im Interesse der Performance, mehr als nur 2 Threads zu erzeugen.
Der DualCore CPU schadet das nicht, solchen mit noch mehr Kernen hilft es aber.
CPUs mit nur einem Kern können ebenso mit diesen Spielen umgehen, der Performanceverlust sollte eher gering sein.

Schlagt mich, wenn ich Schmarn erzähle.

[Omnicron]

Wenn ich mir anschaue wieviele Threads eh schon am laufen sind, glaube ich nicht das ein paar zusätzliche Kontextwechsel viel Performance kosten.
Also das ein Spiel mit 4 Threads auf einem Singlecore nicht deutlich langsamer ist als wenn es mit einem Thread laufen würde.

Edit: Also wenn ich mich mal umgucke scheinen Spiele eh schon viele Threads zu benutzen, gerade getestet Vietcong2 demo hat 8, AOE3 15 Threads offen.

[SentinelBorg]

Die meisten Threads in den Games machen aber nicht viel. Meist sind es einfach Timer oder Actionhandler. Die wirkliche Arbeit des Games läuft meist noch single-threaded.

Die Leistung bei mehreren Threads geht auch nicht durch die Threadwechsel verloren, sondern durch die aufwändige Synchronisation der Threads. Sobald hier Daten ausgetauscht oder gemeinsam bearbeitet werden, wird es problematisch. Da muss dann z.B. Thread B warten bis Thread A fertig ist oder ähnliches.

Sentinel

[Coda]

Die beste Möglichkeit ist es den Render-Loop in Aufgaben aufzuteilen, die Abhängigkeiten zu definieren und einen Scheduler zu schreiben der z.Z. abzuarbeitende Dinge auf die Cores verteilt.

Dann beschränken nur noch die Abhängigkeiten die maximal genutzte Kernzahl.

[Demirug]

Gerade der Renderloop als solches ist kein dankbares Opfer. 3D-APIs sind aufgrund iherer Statemaschine Struktur nicht dafür ausgelegt von mehr als einen Thread angesprochen zu werden.

[Coda]

Renderloop war vielleicht das falsche Wort. Ich meinte damit alles was zwischen zwei Frames passiert.

[TITAN>Steel]

Ok, dass ist jetzt geballtes Fachwissen, dass ich erstmal verdauen muss :-)

Also ist es jetzt nicht so einfach, oder vielleicht auch nicht sinnvoll, wenn man beispielsweise ein CPU mit 4 cores auf einem Die, z.B. Core 1 mit der Physik, Core 2 mit der KI, Core 3 mit Sound und Core 4 mit der Verwaltung des "SoftwareOverheads" = (etwa Treiber, die zwischen BIOS und OS liegen, und im Gegensatz zum Harwarenahen AssemblerCode, meist in höheren Sprachen gigantische latenzen verursachen, was die Coder mit der unterstützung von 3dnow, mmx, sse unterstützung der Treibersoftware zu kompensieren versuchen, welche auf 32 bittigen OS heute schon mit 64 bit befehlen arbeitet können) beschäftigt...

sondern, die 4 CPUs zu als einen Einzigen definier über den Win sheduler?

Wie auch immer, ich habe gehört, die wenigsten Coder können Multithread coding... Im Moment läuft es etwa so ab, habe ich gelesen, normal programmiere coden, und ein programmierer der Multithreat coding beherrscht, überarbeitet sozusagen der sourcecode der unwissenden, sodass es zu herben zeit verlusten in der entwicklung kommt, weiterhin, habe ich gehört, das dass dazu führen wird, dass xbox360 usw. wohl erst nach ihrem gewinnbringenden Ableben von Multithreat Software profitieren könnten...

[BlackBirdSR]

, weiterhin, habe ich gehört, das dass dazu führen wird, dass xbox360 usw. wohl erst nach ihrem gewinnbringenden Ableben von Multithreat Software profitieren könnten...

Nein, das wird realtiv schnell gehen.
Nicht weil es einfach wäre, sondern weil es unbedingt nötig ist.
Ohne Software, die z.B die 3 Kerne der X360 richtig nutzen kann, würde man sehr viel Performance verschenken. Wahrscheinlich zu viel.

[SentinelBorg]

Jein, wie schon gesagt, kümmert sich der Softwareentwickler normal nicht darum, wieviele Cores ein Rechner hat. Man kann es rausfinden und dann eventuell einen anderen Pfad in der Software zur Laufzeit nutzen. Also das Game z.B. einmal auf single-Core optimiert und einmal auf multi-Core optimiert erstellen und dann beim Start zwischen diesen beiden Versionen wählen.
Auf welcher CPU dann aber bei einen multithreaded Anwendung die Threads letztendlich laufen, ist für den Entwickler normal unerheblich. Er erstellt nur Aufgabenhäppchen in Form der Threads. Der Scheduler vom Betriebssystem weisst dann diesen Threads CPU Zeit zu. Ob diese CPU Zeit nun von einem oder von mehreren Prozessoren stammt, ist erstmal unerheblich.
Diese Arbeit machen die heutigen Betriebssysteme auch recht gut, ich habe jetzt z.B. schon über 450 Threads bei nur 41 Prozessen im System laufen. Die meisten Threads existieren dabei aber nicht aus dem Grund der Leistungssteigerung, sondern nur aus dem Grund, dass der User Dinge (quasi) parallel tun kann.

Sentinel

[TITAN>Steel]

Ok, thx @all

mfg TITANsteel