Diskussion zu: News des 2./3. Oktober 2007

[Leonidas]

Link ins News-Archiv:
http://www.3dcenter.org/news/2007/woche40.php#2007-10-03

Schönen Nationalfeiertag für alle Bürger der Bundesrepublik Deutschland!

[Avalox/Gast]

Was id so alles tut und erzählt.

Man darf nicht vergessen, dass id eigentlich nur eines macht. Eine Engine entwickeln und vermarkten. Wenn nun id seine neue Engine auf 6 Core CPUs auslegt, dann werden sie sich freuen, denn dort ist ja automatisch eine Veralterung ihrer Engine eingebaut. Gute Benchmarkwerte heute, schlechte morgen. Zeit für die nächste Engine.

Woher soll denn die Motivation kommen von id, einen weiterführenden Ansatz zu schaffen?

Ich denke, das automatische Veralterung überhaupt eine der Entwicklungen ist, welche immer mehr in den Vordergund drängt.

[elianda]

Bei dem fortschrittlichen Gedanken von 80 Cores in einem Gaming-System sollte nicht ausser acht gelassen werden, dass da noch Aenderungen ins Haus stehen:

- bei 80 Cores werden die Kerne einfacher gestrickt sein als heutige, was vermutlich in geringerer Performance pro Core resultiert
- Bei den 80 Cores werden Spezialcores dabei sein, die zusaetzliche Recheneinheiten fuer bestimmte Aufgaben haben (oder nur diese speziellen ALUs haben)
- Hoeherer Einfluss des Caches.

Das verschaerft das Lastverteilungsproblem noch zusaetzlich. Ich kann mir gut vorstellen, dass eine multithreaded Engine dann bei einem System zuerst einen Load Balancing Run macht, um die optimale Lastverteilung herauszufinden.

[stav0815]

Link ins News-Archiv:
http://www.3dcenter.org/news/2007/woche40.php#2007-10-03

Schönen Nationalfeiertag für alle Bürger der Bundesrepublik Deutschland!
In den News ist ein Denkfehler mit drin. Wenn man viele kleinere Rechenaufgaben hat (also mehr Rechenaufgaben als Cores) kann man mehrere Rechenaufgaben einem Core zuweisen und die Rechenaufgaben so verteilen, dass die Cores möglichst effizient ausgelastet werden.

Das Problem beim Aufteilen von Rechenaufgaben ist also nicht deren Anzahl, sondern deren sinnvolle Verteilung.

[Bushwacker]

Ich sehe das so ähnlich.

Erstens sollte man nicht vergessen, dass Game Engine nicht davon ausgehen können, dass sie eine bestimmte Anzahl von CPU-Cores vorfinden, sondern höchstens eine Mindestanforderung an Rechenleistung haben. Ob diese letztendlich durch 1 oder n Cores abgearbeitet werden, ist genaugenommen auch egal.

Auch die Sprachregelung "die Engine unterstützt x Cores" ist Blödsinn. Entweder soll das heissen, dass die Engine aktiv in die Verteilung der Threads auf Cores eingreift und Threads fix bestimmten Cores zuweisst (gibt/gab es bei EQ2) oder eben maximal n Threads hat und somit evtl. Cores nicht ausgelastet werden.
Nun mag es aus Marketinggesichtspunkten sicher toll sein, wenn für einen Prozessor mit 80 Cores werben kann und dieser mag für bestimmte Aufgaben auch sinnvoll sein, aber eben nicht für jede Aufgabe. Mit zunehmender Aufteilung der Aufgaben wachsen eben auch die Aufwände für die Syncronisation der Einzelthreads. Nicht zu vergessen, dass diese Aufwände natürlich auch auf PCs mit weniger Cores als Threads auftreten und damit das Programm langsamer machen.

Die im Artikel genannten 25% (4 Cores) und 12,5% (8 Cores) Rechenleistung empfinde ich als unglückliche Formulierung. Die 100% sind nämlich in jedem der genannten Prozessoren eine andere Grösse. Anders herum wird ein Schuh daraus: Ein CPU-Kern mit einer bestimmten Leistung sind 100% und ein Prozessor mit n Cores gleicher Leistungsfähigkeit hat also max. n*100% Rechenleistung.

[Gast]

btw es heisst octAcore, nicht octOcore. Wortethymologie olé :-)

[Chatt]

In den News ist ein Denkfehler mit drin. Wenn man viele kleinere Rechenaufgaben hat (also mehr Rechenaufgaben als Cores) kann man mehrere Rechenaufgaben einem Core zuweisen und die Rechenaufgaben so verteilen, dass die Cores möglichst effizient ausgelastet werden.

Das Problem beim Aufteilen von Rechenaufgaben ist also nicht deren Anzahl, sondern deren sinnvolle Verteilung.

Aber es ging doch gar nicht um die Auslastung der Cores sondern um das explizite Beispiel einer Game Engine. Wenn die langsamste Komponente nun mal nur auf einem Kern berechnet werden kann und der Rest von eben dieser abhängig ist, KÖNNEN die anderen Kerne doch gar nicht ausgelastet werden weil sie erst auf das ergebnis dieses speziellen Threads warten müssen. Höchstens wäre es noch möglich die restliche Rechenpower dazu zu verwenden schon mal jedes mögliche Ergebnis des besagten Threads vor zu berechnen, quasi eine Softwaresprungvorhersage, was ich mir allerdings als nicht wirklich möglich vorstelle.
Achtung: Dieser Beitrag wurde von einem kompletten Laien verfasst, also seid gnädig mit mir wenn ich Blödsinn verzapft habe ;)

Chatt (der wo hofft nicht völlig daneben gegriffen zu haben)

[stav0815]

Aber es ging doch gar nicht um die Auslastung der Cores sondern um das explizite Beispiel einer Game Engine. Wenn die langsamste Komponente nun mal nur auf einem Kern berechnet werden kann und der Rest von eben dieser abhängig ist, KÖNNEN die anderen Kerne doch gar nicht ausgelastet werden weil sie erst auf das ergebnis dieses speziellen Threads warten müssen. Höchstens wäre es noch möglich die restliche Rechenpower dazu zu verwenden schon mal jedes mögliche Ergebnis des besagten Threads vor zu berechnen, quasi eine Softwaresprungvorhersage, was ich mir allerdings als nicht wirklich möglich vorstelle.
Achtung: Dieser Beitrag wurde von einem kompletten Laien verfasst, also seid gnädig mit mir wenn ich Blödsinn verzapft habe ;)

Chatt (der wo hofft nicht völlig daneben gegriffen zu haben)
Dann wiederum ist es aber auch vollkommen egal ob man die restlichen Rechenoperationen in einem Thread oder in 500 Threads hat.

[Chatt]

Dann wiederum ist es aber auch vollkommen egal ob man die restlichen Rechenoperationen in einem Thread oder in 500 Threads hat.

Nicht wenn diese wiederum in mehreren Threads schneller berechnet werden können und sonst NOCH mehr Rechenzeit bräuchten als der sonst langsamste Thread.
Der springende Punkt der News ist doch, dass eine Optimierung der Engine auf 3 oder 4 Kerne in Zukunft nichts mehr bringen wird. Die Multicore CPUs der Zukunft werden mit sowas lange nicht auslastbar sein. Insofern ist die geäußerte Krtik an id IMHO völlig gerechtfertigt.

Chatt (der wo nun den Nerd-Mode erst mal wieder abstellt)

[stav0815]

Nicht wenn diese wiederum in mehreren Threads schneller berechnet werden können und sonst NOCH mehr Rechenzeit bräuchten als der sonst langsamste Thread.
Der springende Punkt der News ist doch, dass eine Optimierung der Engine auf 3 oder 4 Kerne in Zukunft nichts mehr bringen wird. Die Multicore CPUs der Zukunft werden mit sowas lange nicht auslastbar sein. Insofern ist die geäußerte Krtik an id IMHO völlig gerechtfertigt.

Chatt (der wo nun den Nerd-Mode erst mal wieder abstellt)
Ähm, sorry aber ich glaub ich steh aufm Schlauch und versteh dich grad nicht. :confused:

[Chatt]

Oh, hier wurde ja nochmal geantwortet o\

Also. So wie ich das verstanden habe wird die nächste id Engine so ausgelegt, dass sie nicht so viele Threads wie möglich gleichzeitig bearbeitet, sondern explizit 3 bzw. 4 Kerne auslastet. Schon bei den 8-Kern CPUs sollte das dann keine weitere Performance mehr bringen, bei den in der Zukunft anstehenden Many-Core CPUs dann sowieso dann sowieso nicht mehr. Wenn ich allerdings nochmal darüber nachdenke sehe ich da dann doch nicht mehr wirklich ein Problem. Klar will id seine Engine verkaufen und sich nicht unnötig für die Zukunft selbst Konkurrenz machen indem man eine Engine entwickelt die mit den mittelfristig anstehenden CPUs quasi "zu gut" skaliert. Aber tatsächlich machen es die reinen Spieleentwickler ja auch nicht anders. Es wird auf vorhandene Hardware optimiert, und nicht auf das was künftig noch ansteht, tatsächlich wird ja meist auf den kleinsten gemeinsamen Nenner hin programmiert und vglw. wenig auf die jeweils neueste und quasi gar nicht auf die später anstehende HW. Eine Ausnahme bilden hier höchstens die Grafikchips bei denen gerne mal eine noch kaum verbreitete bzw. noch nicht wirklich genug leistungsfähige DX Version rangenommen wird, allerdings dann meist mit massivem Support eines Chipherstellers. Da es in dieser News allerdings ja nur um Prozessoren ging spielt das aber hier keine Rolle.

Chatt (der wo sich die ganze Tipparbeit also hätte sparen können :X )

[Leonidas]

In den News ist ein Denkfehler mit drin. Wenn man viele kleinere Rechenaufgaben hat (also mehr Rechenaufgaben als Cores) kann man mehrere Rechenaufgaben einem Core zuweisen und die Rechenaufgaben so verteilen, dass die Cores möglichst effizient ausgelastet werden.


Dieses Modell würde nur funktionieren, wenn man beliebig oft aufteilen kann, also üblicherweise eine höhere Anzahl an Rechenaufgaben als Cores hat, beispielsweise 20 Rechenaufgaben auf 4 Cores. Die kann man immer so verteilen, daß jeder Core genau gleich ausgelastet ist.

Allerdings kann man sich ja nicht nach Belieben Rechenaufgaben aufteilen. Aufteilbar ist nur, was unabhängig voneinander berechnet werden kann. Die Aufteilung von id Software in 6 Rechenaufgaben dürfte da schon nahe am besten sein, was sich diesbezüglich machen läßt. Man kann ja die Rechenaufgaben nicht einmal anhand deren Performancelast aufteilen, sondern immer nur daran, daß sie unabhängig voneinander berechenbar sind.

Die Ausgangslage ist also immer, daß man eine arg begrenzte Anzahl an aufteilbaren und sich nicht einander behindernden Rechenaufgaben hat. Und die rennen immer in ein Effizienz-Problem, wenn die Anzahl der Cores steigt.





Also. So wie ich das verstanden habe wird die nächste id Engine so ausgelegt, dass sie nicht so viele Threads wie möglich gleichzeitig bearbeitet, sondern explizit 3 bzw. 4 Kerne auslastet. Schon bei den 8-Kern CPUs sollte das dann keine weitere Performance mehr bringen, bei den in der Zukunft anstehenden Many-Core CPUs dann sowieso dann sowieso nicht mehr. Wenn ich allerdings nochmal darüber nachdenke sehe ich da dann doch nicht mehr wirklich ein Problem. Klar will id seine Engine verkaufen und sich nicht unnötig für die Zukunft selbst Konkurrenz machen indem man eine Engine entwickelt die mit den mittelfristig anstehenden CPUs quasi "zu gut" skaliert. Aber tatsächlich machen es die reinen Spieleentwickler ja auch nicht anders. Es wird auf vorhandene Hardware optimiert, und nicht auf das was künftig noch ansteht, tatsächlich wird ja meist auf den kleinsten gemeinsamen Nenner hin programmiert und vglw. wenig auf die jeweils neueste und quasi gar nicht auf die später anstehende HW.



Und so macht es ja auch Sinn. Die kommenden Prozessoren werden sowieso in irgendeiner Weise schneller sein, obwohl das Game trotzdem die gleichen Rechenpower-Anforderungen hat. Besser man optimiert für alte und aktuelle Hardware, weil man damit den Kreis der potentiellen Käufer erhöht. Käufer zukünftiger Hardware gehören da automatisch dazu, egal ob man für die optimiert oder nicht.







PS: OctaCore. Danke für den Hinweis.