Out-of-Order CPU vs. In-Order CPU ... was können Xbox 360 und PS3

[Konsolenfreund]

Durch dieses Posting http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3121221&postcount=454 von RLZ initiiert, der die Xbox 360 und PS3 CPU als extrem langsam einschätzt, frage ich mich, ob man dieser Aussage glauben schenken darf, die er verlinkt hat:
This means that your new fancy 2 plus gigahertz CPU, and its Xenon, is going to run code as slow or slower than the 733 megahertz CPU in the Xbox 1. The PS3 will be even worse.
http://www.gamespot.com/news/2005/03/18/news_6120449.html

Nun, ich weiß, dass bei in-Order CPUs, die stark parallel aufgebaut sind, entprechende Probleme bei der Abarbeitung von befehlen auftreten können. Wie sieht das bei der Xbox 360 und besonders beim Cell aus. Gibt es da Lösungsansätze für? Stimmt die Ausssage von oben, dass die Codeverarbeitung von der X360 oder PS3 CPU langsamer ist, als bei einem 733Mhz Celeron/Pentium? :|

Obwohl ich ein marktingverseuchter Laie bin, kann ich es mir eigentlich nicht vorstellen, dass der Herr da oben den Durchblick hat, wenn er sowas behauptet. :rolleyes:

Konsolenfreund

[Coda]

Ich hab hier schon oft genug geschrieben, dass die Dinger nicht wirklich effizient sind. Aber schneller als ein 733Mhz P3 sollten sie schon noch sein pro Core.

Sie können ja mit einem Thread gerade mal 1Op/Cycle ausführen, selbst ein Pentium 1 konnte bei entsprechendem Instruction pairing schon 2. Das geht bei den PPCs nur per SMT, was nicht gerade immer einfach ist.

Alles in allem finde ich das ziemlich enttäuschend. Gerade Cell ist ziemlich aufgeschmissen mit nur einem PPE wenn man die SPEs nicht verwenden kann bei nicht-threadbarem Code.

[Demirug]

Die Leistungsfrage hat hier aber weniger etwas mit In-Order bzw Out-of-Order zu tun.

Um zu beurteilen was die neuen Consolenchips leisten bräuchte man eine Liste mit allen Befehlen, wie lange sie brauchen und welche Seiteneffekte es dabei gibt. Sony hat sowas zumindestens in Aussicht gestellt von MS habe ich noch nichts entsprechendes gehört.

In-Order vs. Out-of-Order ist bei Konsolen weniger ein Problem. Da man dort nur für eben genau ein System compiliert kann der Compiler die beste Reihenfolge erzeugen. Beim PC müssen die neuen CPUs auch mit Programmen klar kommen die schon kompiliert wurden als es diese noch gar nicht gab. Da zudem die Programme auf verschiedenen CPUs laufen müssen kommt es bei der Codeerzeugung zu Kompromissen. Aus diesem Grund braucht man hier Out-of-Order CPUs die sich den Code selbst passenden umsortieren können. Es macht also durchaus Sinn für Konsolen In-Order CPUs zu nutzen um sich die Transitoren zu sparen.

[RLZ]

Ich halte sie nicht für extrem langsam.
Nur werden sie für Durchschnittscode wohl nicht der Überbringer.

Das Hauptproblem besteht darin, dass die Logik, die man im CPU eingespart hat in den Compiler einbauen muss.
Also soll der Compiler alle Möglichkeiten voraussehen. Da die Daten aber ja nicht statisch kann er das garnicht.
Nun gibts ein paar Tricks, dass man zB den Compiler den Code umsortieren lässt und mehrere mögliche Verzweigungen berechnet, wovon einer dann hinterher weggeschmissen wird.
Eine andere Sache ist, dass der Programmierer möglichst Fallunterscheidungen vermeidet (sollte man eh...). Allerdings ist dies oft nicht möglich und in vielen Bereichen garnicht sinnvoll machbar (zB KI, Spiellogik).

[RLZ]

Die Leistungsfrage hat hier aber weniger etwas mit In-Order bzw Out-of-Order zu tun.
Die Erfahrungen die ich mit dem Itanium gemacht habe sind aber anders.
Hier hat Intel ja auch hier ihren eigenen Compiler (und keine 10 verschiedenen Prozessoren...).
Und normaler Code machte performancemässig ziemlich wenig her.

Erst nachdem man im Code extrem dahingehend nachgebessert hat erhielt man eine vernünftige Leistung.

[Demirug]

Die Erfahrungen die ich mit dem Itanium gemacht habe sind aber anders.
Hier hat Intel ja auch hier ihren eigenen Compiler (und keine 10 verschiedenen Prozessoren...).
Und normaler Code machte performancemässig ziemlich wenig her.

Erst nachdem man im Code extrem dahingehend nachgebessert hat erhielt man eine vernünftige Leistung.

Einen Itanium würde ich hier nicht unbedingt als Referenz nehmen. Der hat ja so einige Eigenheiten.

[RLZ]

Einen Itanium würde ich hier nicht unbedingt als Referenz nehmen. Der hat ja so einige Eigenheiten.
Stimmt auch wieder.
Was aber nichts dran ändert, dass dem Compiler in vielen Fällen einfach die Hände gebunden sind, weil er schliesslich kein Hellseher ist.
Er kann auch nur das ändern, was zur Compilezeit vorhersehbar ist. (+ einiger Vorsichtsmaßnahmen)
Alles andere wird mehr oder weniger wahrscheinlich schiefgehen und Performance kosten.

[Gast]

Ich halte sie nicht für extrem langsam.
Nur werden sie für Durchschnittscode wohl nicht der Überbringer.
Wer benutzt denn auf den NextGen Konsolen Durchnittscode? Ist klar, dass die Konsolen ihr volles Potenzial nicht zeigen mit 08/15 Apps, die auf alle Plattformen gleich geschustert werden.

In dem besagten Thread haben wir wohl davon gesprochen, was die Konsolen leisten können mit entsprechend angepassten Spielen und Du hast gesagt, dass die neuen Konsolen sowieso nicht so toll sind, weil sie in-Order den Coe abarbeiten. Da scheint es ja durchaus auch andere Meinungen zu geben. Und dein Zitat, dass die X360 CPU oder die PS3 CPU so schnell sind wie ein 733MhzPentium, ist wohl mal völliger Unsinn.

Und das Multicoreproblem und das in-oder Problem hängen irgendwie schon zusammen, was Du ja in dem anderem Thread bestritten hast. Denn die Codereihenfolge muss nicht nur in einem Thread, sondern auch über mehrer Hardwarethreads synchronisiert werden. Beide Probleme umgeht man mit mit ensprechender Compilierung, die voll auf die entsprechende CPU angepasst wird.

Und einen Itanium, der nun wirklich einen sehr seltsamen Aufbau hat, mit einerm Cell Chip zu vergleichen, der immerhin über Jahre in Hinsicht auf die PS3 entwickelt wurde, ist wohl auch etwas weit hergeholt.

Konsolenfreund

[Coda]

Es ist wie gesagt auch nicht In-Order vs. Out-of-Order das Problem sondern der Durchsatz. Und der ist wirklich ziemlich niedrig für eine moderne CPU...

[RLZ]

Und dein Zitat, dass die X360 CPU oder die PS3 CPU so schnell sind wie ein 733MhzPentium, ist wohl mal völliger Unsinn.
Ist es nicht weil extra dabeistand, dass es für bestimmt Code gilt.
Durchschnittscode werden auch die neuen Konsolen nehmen müssen, weil alles andere zuviel Zeit kosten würde.

Beide Probleme umgeht man mit mit ensprechender Compilierung, die voll auf die entsprechende CPU angepasst wird.
Du scheinst ja viel Erfahrung mit Compilerbau zu haben, wenn du alles einfach damit löst. Nur dumm, dass grade diejenigen die sich auf Compilerbau spezialisiert haben das anders sehen...

Und einen Itanium, der nun wirklich einen sehr seltsamen Aufbau hat, mit einerm Cell Chip zu vergleichen, der immerhin über Jahre in Hinsicht auf die PS3 entwickelt wurde, ist wohl auch etwas weit hergeholt.
Wenigstens hab ich Gegensatz zu dir Erfahrung mit InOrder Cpus.
Ob der Vergleich soweit her geholt ist wird man noch sehen, wenn man mehr über den Befehlssatz und das Verhalten der CPU´s weiss.

[Quasar]

Könnte man spekulativ den Compiler die sieben wahrscheinlichsten Alternativen als unterschiedliche Threads auf den SPUs des Cell laufen lassen und dann am Ende den nehmen, der sich als richtig herausgestellt hat?

[Gast]

Ist es nicht weil extra dabeistand, dass es für bestimmt Code gilt.
Durchschnittscode werden auch die neuen Konsolen nehmen müssen, weil alles andere zuviel Zeit kosten würde.
Na, das sehe ich aber anders. Mit Konsolengames ist mehr Geld zu verdienen, dewegen gibt es überhaupt so viele plattfomgebundenen Konsolenspiele, die extrem aufwendig (teuer) produziert werden. Auf den nextGen Kosnolen werden überwiegend hoch angepasste Spiele erscheinen, nicht zuletzt wegen den guten Entwicklungstools von Microsoft und Sony/nVidia. Sogar EA entwickelt die Spiele nun speziell für PS3, X360 und Revolution, weil es sich die Investion einfach lohnt. Von den anderen TopStudios, die schon immer speziell für Konsolen entwickelt haben, wollen wir da garnicht erst sprechen.

Du magst dich mit CPUs besser auskennen, aber weniger mit dem Aufwand der betrieben wird, und insbesondere betrieben werden wird, was Konsolenspiele angeht.

Du scheinst ja viel Erfahrung mit Compilerbau zu haben, wenn du alles einfach damit löst. Nur dumm, dass grade diejenigen die sich auf Compilerbau spezialisiert haben das anders sehen...
Die Meinungen gehen da wohl auseinander, mal abgesehen von meiner Laienmeinung. Jedenfalls scheinst Du Microsoft und Sony schon ganz schön tief einzuschätzen, wenn Du meinst die verbauen Multicore in-Order CPUs, wenn diese nicht effizient wären für Spiele. Ist ja auch nur ein Milliardengeschäft, da macht man sich solche Gedanken nicht. :rolleyes:

Wenigstens hab ich Gegensatz zu dir Erfahrung mit InOrder Cpus.
Ob der Vergleich soweit her geholt ist wird man noch sehen, wenn man mehr über den Befehlssatz und das Verhalten der CPU´s weiss.
:massa:

Konsolenfreund

[Coda]

Du scheinst ja viel Erfahrung mit Compilerbau zu haben, wenn du alles einfach damit löst. Nur dumm, dass grade diejenigen die sich auf Compilerbau spezialisiert haben das anders sehen...Nay, da hat Demirug schon recht. Was die CPU just-in-time umsortieren kann kann der Compiler schon lange...

[Gast]

@Konsolenfreund: die Multicores kann man eh nicht so weit auslasten, wie's auf dem Papier aussieht. Aber verkaufen werden sie sich gut, weil Marketing ist alles und der Käufer braucht/bekommt eindrucksvolle Zahlen (Stichwort "gesunder Verstand", 2 CPUs=doppelte Power).

Das diese Einschätzung richtig ist, zeigt ja auch wieviele den X2 als die zur Zeit ultimative CPU ansehen.

[Gast]

@Konsolenfreund: die Multicores kann man eh nicht so weit auslasten, wie's auf dem Papier aussieht. Aber verkaufen werden sie sich gut, weil Marketing ist alles und der Käufer braucht/bekommt eindrucksvolle Zahlen (Stichwort "gesunder Verstand", 2 CPUs=doppelte Power).

Das diese Einschätzung richtig ist, zeigt ja auch wieviele den X2 als die zur Zeit ultimative CPU ansehen.
Klar kann man das marketingtechnisch gut auschlachten. Aber im Endeffekt hat man sich bei Sony und Microsoft ja nicht wegen dem Marketing für Multicore entschieden. Es wird so oder so kein weg an massiven Multithreads CPUs, ob PC oder Konsole, vorbeiführen. Das zeichnet sich ja schon lange ab. Parallelisierung ist die Zukunft, weil alles andere ne Sackgasse ist.

Konsolenfreund

[RLZ]

Nay, da hat Demirug schon recht. Was die CPU just-in-time umsortieren kann kann der Compiler schon lange...
Wie willst du denn etwas durch den Compiler umsortieren, wenn es zur Compilezeit garnicht nicht feststeht?

[Coda]

Was steht da nicht fest? :|
Die Reihenfolge der Befehle sicherlich und um was anderes geht es bei Out-Of-Order nicht...

[Demirug]

In Verbindung mit einer Branch prediction ist es möglich bei einem Chip der mehr als eine Anweisung pro Takt starten kann eine Out-of-Order Einheit noch etwas rausholen kann. Deswegen soll man ja einem In-Order Compiler bei Branches Tipps geben was der normalerweise ausgeführte Zweig ist. Alternativ kann man den Compiler auch mit Profiler ergebnissen trainieren wenn er das unterstützt.

[RLZ]

Was steht da nicht fest? :|
Die Reihenfolge der Befehle sicherlich und um was anderes geht es bei Out-Of-Order nicht...
Wenn die Reihenfolge immer fest wäre bräuchten wir gar kein Out-of-Order. :|

[Jesus]

Wenn die Reihenfolge immer fest wäre bräuchten wir gar kein Out-of-Order. :|

Ich denke ihr redet aneinander vorbei :|

[RLZ]

In Verbindung mit einer Branch prediction ist es möglich bei einem Chip der mehr als eine Anweisung pro Takt starten kann eine Out-of-Order Einheit noch etwas rausholen kann.
Dieses etwas ist aber soviel, dass es offenbar lohnt dafür eine Menge Chipfläche zu investieren.
Deswegen soll man ja einem In-Order Compiler bei Branches Tipps geben was der normalerweise ausgeführte Zweig ist.
Das hat afaik zumindest beim Intelcompiler schon implizit durch die Reihenfolge auch für "normale" Cpu´s.
Alternativ kann man den Compiler auch mit Profiler ergebnissen trainieren wenn er das unterstützt.
Naja ist aber auch nicht sehr praktikabel und ändert in vielen Fällen auch nichts an den entweder vielen Stalls oder zuviel berechneten Daten.
Dann muss man noch an die Teile der Spiele denken, die auf einer VM laufen.
Soll man die auch profilen?


Ich denke ihr redet aneinander vorbei
Möglich :D

[Demirug]

Dieses etwas ist aber soviel, dass es offenbar lohnt dafür eine Menge Chipfläche zu investieren.

Bei normalen PC Chips braucht man das au vorgenannten Gründen sowieso.

Das hat afaik zumindest beim Intelcompiler schon implizit durch die Reihenfolge auch für "normale" Cpu´s.

Wie soll das gehen? Gerade was die Branches angeht gibt es ja unterschiedliche Programmierrichtlinen und entsprechend viel Code.

Naja ist aber auch nicht sehr praktikabel und ändert in vielen Fällen auch nichts an den entweder vielen Stalls oder zuviel berechneten Daten.
Dann muss man noch an die Teile der Spiele denken, die auf einer VM laufen.
Soll man die auch profilen?

Ich glaube wir reden hier aneinander vorbei.

Ich meinte das man den Profiler bei einem Durchlauf ermitteln lässt wie oft welcher Branch genommen wird. Diese Werte gibt man dann beim nächsten Compilerdurchlauf dem Compiler mit.

[robbitop]

Wenn der PPC Core so langsam sein soll, warum nahm man b.s.w. kein K7/8- oder ein Pentium M Derivat?

[RLZ]

Wie soll das gehen? Gerade was die Branches angeht gibt es ja unterschiedliche Programmierrichtlinen und entsprechend viel Code.
Irgendwo in einer Guideline (AMD, Intel oder sonstwas in der Richtung) hat ich mal so was gelesen. Finds aber grad nicht.
Nunja ist auch eigentlich nicht wichtig.


Ich glaube wir reden hier aneinander vorbei.

Ich meinte das man den Profiler bei einem Durchlauf ermitteln lässt wie oft welcher Branch genommen wird. Diese Werte gibt man dann beim nächsten Compilerdurchlauf dem Compiler mit.
Schon verstanden :)
Je nachdem kann das aber eine langwierige Angelegenheit werden bis man alles profiled hat.
Die Probleme bei einigermaßen gleichmässiger Wahrscheinlichkeitsverteilung löst es genausowenig wie direkte pragmas (da ja eigentlich nur Ersatz für faule Programmierer)

Auf jeden Fall bedeutet es einen Mehraufwand und Umgewöhnung für die Entwickler.
Eine wirkliche Mehrleistung um Faktor x wie vom Marketing versprochen bringen die Dinger im Normalfall auch nicht.

Wenn der PPC Core so langsam sein soll, warum nahm man b.s.w. kein K7/8- oder ein Pentium M Derivat?
Es geht mir ja nicht um das langsamer, sondern vorallem um die Behauptung sie wären wesentlich schneller. ;)
Die Konsolenjünger behaupten ja fast, dass eine Konsole den Earth-Simulator ersetzt. :D
3 Cores machen sich in der Werbung besser, AMD hat keine Kapazitäten für so etwas und die anderen anderen Designs sind an Intel gebunden (und imo nicht ganz so flexibel) usw.
Gründe kann das viele haben.
Apple ist ja jetzt den umgekehrten Weg gegangen.
Wobei dies ja andere PPC´s waren als in der XBox. (verstehen aber die meisten auch nicht...)

[Muh-sagt-die-Kuh]

In Verbindung mit einer Branch prediction ist es möglich bei einem Chip der mehr als eine Anweisung pro Takt starten kann eine Out-of-Order Einheit noch etwas rausholen kann. Deswegen soll man ja einem In-Order Compiler bei Branches Tipps geben was der normalerweise ausgeführte Zweig ist. Alternativ kann man den Compiler auch mit Profiler ergebnissen trainieren wenn er das unterstützt.Es gibt noch einen anderen Weg: Predication wie im IA-64 Befehlssatz vorgesehen. Man berechnet prinzipiell beide Pfade eines Branches parallel und nimmt dann den richtigen. Das ist nicht in jedem Fall die optimale Lösung, funktioniert aber recht gut.

Ein PowerPC Kern kann das allerdings nicht....

[ShadowXX]

Wenn der PPC Core so langsam sein soll, warum nahm man b.s.w. kein K7/8- oder ein Pentium M Derivat?

Vielleicht wollte man sich nicht nochmal an Intel binden.....oder IBM hat MS ein verdammt guten Preis gemacht, den IMHO ist der PPC-Core der MS-IBM-CPU nix anderes als ein "Abfallprodukt" des Cell.

Die Eigenschaften des Cell-PPC-Cores gleichen sich nämlich verdächtig mit denen der MS-CPU PPC-Cores.

(OT: Man hat in das Ding übrigens nicht ohne Grund gleich 3 von dieses Cores gesteckt.....es war bestimmt nicht, weil ein 1 Core Geschwindigkeitsmässig ausgereicht hätte und man sich dachte...holla, wir haben noch platz auf dem Die.)

Vielleicht ist es auch eine Mischung aus beidem....

AMD könnte ausserdem nicht genug CPUs liefern...zu geringe Kapazitäten.

Mich würde es auch nicht wundern, wenn die MS-CPU billiger herzustellen ist als ein vergleichbarer Intel/AMD-Kern.

[robbitop]

AMD könnte ausserdem nicht genug CPUs liefern...zu geringe Kapazitäten.


Mit Chartered Semiconductor, Fab36 und Fab30? Ab 2006 hat man mehr als genug Fertigungskapazitäten. Und alle laufen mit APM 3.

[reunion]

(OT: Man hat in das Ding übrigens nicht ohne Grund gleich 3 von dieses Cores gesteckt.....es war bestimmt nicht, weil ein 1 Core Geschwindigkeitsmässig ausgereicht hätte und man sich dachte...holla, wir haben noch platz auf dem Die.)


Die Xbox 360-CPU dürfte um ein vielfaches leichter auszulasten sein als dieses Cell-Monster. Cell bringt jedemenge Leistung mit, die dann so vielleicht gar nicht verwendet werden kann. Dazu muss man die Vektoreinheiten erstmal ausnutzen.
Dass man bei der Xbox-CPU drei Kerne integriert hat, ist eine logische Entwicklung, die jetzt selbst im Desktopsegment einzug hält. Cell hat hingegen nur eine echten Core. Ich sehe das eher als Vorteil, denn als Nachteil.

[BlackBirdSR]

Dass man bei der Xbox-CPU drei Kerne integriert hat, ist eine logische Entwicklung, die jetzt selbst im Desktopsegment einzug hält. Cell hat hingegen nur eine echten Core. Ich sehe das eher als Vorteil, denn als Nachteil.

Kommt darauf an, wie stark man die skalaren Einheiten der SPEs mit einbeziehen kann.
Ist ja nicht so, dass diese reine Vektoreinheiten wären, welche ohne vektorisierten Code nur idle laufen.

[Gast]

Mit Chartered Semiconductor, Fab36 und Fab30? Ab 2006 hat man mehr als genug Fertigungskapazitäten. Und alle laufen mit APM 3.
Ich denke Apples Weg hatte ganz klar finanzielle Hintergründe und Intel hatte schlicht das beste Angebot an Apple gemacht.

Konsolenfreund

[robbitop]

Ich denke Apples Weg hatte ganz klar finanzielle Hintergründe und Intel hatte schlicht das beste Angebot an Apple gemacht.

Konsolenfreund

@Betareverse

Intels Domäne ist sonst der Preis eigentlich nicht, aber wer weiß, vieleicht war es eine Mischung aus gutem Angebot und brauchbaren Kapazitäten.

[Gast]

Kommt darauf an, wie stark man die skalaren Einheiten der SPEs mit einbeziehen kann.
Ist ja nicht so, dass diese reine Vektoreinheiten wären, welche ohne vektorisierten Code nur idle laufen.
Selbst wenn, nur der PPC-Kern laufen würde ... ein Power PC mit mehr als 2 GHz ist ordentlich Holz vor der Hütte. Ich vermute eine Rechenstärke von einem PPC 750 ... aber der ist nie in Sichtweite von 2 GHz gewesen.

Und die SIMD-Einheiten (7 an der Zahl) mit eignenen Speicher ist etwas mehr als eine funzelige AltiVec-Einheit. Selbst wenn, die SIMD-Einheiten des Cell abwechselnd laufen (um kühl zu bleiben). So kann man doch wesentlich mehr Power erwarten.

Ähnliches könnte man auch von der X-Box 360 sagen, wenn auch die Architektur deutlich konservativer ist.

Was Multicore angeht, so hat die PS 1 schon gezeigt, dass mit geschicktem Code zwei MIPS Kerne gut ausgelastet werden können.

IBM ist ein Garant dafür, dass Multicores gut ausgelastet werden können, zum einen dank der langjährigen Erfahrungen rund um die Power 4/5.
Zum anderen haben sie aber auch diverse Analysentools und Kompiler den Code entsprechend zu schreiben.

Zusätzlich hat IBM aber auch Erfahrung in Sachen Virtualisierung, womöglich sind Softwarelayer eingezogen, die für eine gleichmässige Verteilung der Rechenlast sorgen. Bleibt natürlich immer noch die Frage wie gut die Kombination Vektorcode und Skalarcode unter einem Hut gebracht wird ...
-> Vektor-Rechner (http://www.orthy.de/modules.php?name=Encyclopedia&op=content&tid=31)

MFG Bo(2005)

[Gast]

Und die SIMD-Einheiten (7 an der Zahl) mit eignenen Speicher ist etwas mehr als eine funzelige AltiVec-Einheit.

Soweit ich weiß hat der CELL doch sogar eine separate Altivec-Einheit, oder?

[mocad_tom]

Diese beiden Berichte schonmal durchgelesen?
http://arstechnica.com/articles/paedia/cpu/xbox360-1.ars
http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars

Viele fühlen sich Angegriffen, wenn man einem Xenon-Core die Skalarcodeleistung einer P3-733MHz-CPU nachsagt. Aber mehr wird die CPU auch nicht haben - eher noch weniger. Der Compiler kann zwar noch ein bisschen rumsortieren und als Programmierer sollte man etwas die Sprungwahrscheinlichkeiten abschätzen helfen, aber bei verzweigtem Code ist kein Blumentopf zu holen.

Dafür aber als Vektor-CPU und dank SMT kann das innerhalb eines Cores ablaufen.
Jeder Core erhält einen Vektor- und einen Skalar-Thread.
Während der Skalar-Thread sich verläuft kann der Vektor-Thread weiterarbeiten. Damit der Vektor-Thread die Caches nicht leerräumt und da es bei SIMD-Aufgaben sowieso Vorteile hat, wenn man den Cache direkt beeinflussen kann, können Bereiche in einen Local Storage umgeschaltet werden.

Grüße,
Tom

[GloomY]

Erstmal allgemein: Um genau zu sein, muss man erstmal zwischen Out-of-Order Issue (meist auch OOO-Execution genannt) und Out-of-Order Completion unterscheiden. OOO-Issue beschreibt die Fähigkeit, mit der Berechnung von Befehlen in einer anderen Reihenfolge anzufangen als diese im Programm vorkommen.
OOO-Completion heißt, dass die Befehle in einer anderen Reihenfolge fertig werden, als diese im Programm stehen. Das ist z.B. dann der Fall, wenn die mehrere Befehle gleichzeitig ausgeführt werden (superskalar) und Befehle unterschiedlich lange Ausführungszeiten besitzen (z.B. FDIV und ADD) oder ein Befehl bei seiner Ausführung aufgehalten wird (Cache Miss).

Da es u.a. für Interrupts und Exceptions wichtig ist, dass das Registerfile bzw. der Speicher immer in einem Zustand ist, der nach der seriellen Abarbeitung des Programms erreicht werden würde (*) (d.h. nicht schon Ergebnisse von Befehlen drin stehen, obwohl es andere Befehl gibt, die früher im Programmcode stehen, aber noch nicht fertig sind), besitzen moderne CPUs oft In-Order Completion. Das wird mit einem Reorder Buffer erreicht, der die Befehle quasie wieder umsortiert, so dass diese das Register-File bzw. den Speicher updaten, als wenn alle Befehle nacheinander ausgeführt würden. (**)

AFAIK haben die meisten modernen CPUs OOO-Issue, aber gleichzeitig In-Order-Completion.


(*) Diese Eigenschaft nennt man "precise Execution" bzw. das Gegenteil "inprecise Execution"

(**) Das geschieht wie z.B. beim K7 / K8 mit zwei Register Files: Ein normales und ein "Future RegFile", in welches alle Ergebnisse eingetragen werden, die spekulativ sind oder ausserhalb der Reihenfolge errechnet wurden. Erst wenn die Ergebnisse nicht mehr spekulativ sind (korrekt vorhergesagter Sprung) oder alle im Programmcode davor stehenden Befehle fertig sind, werden die Ergebnisse vom Future Reg-File in das "echte" Reg-File übertragen, so dass dieses immer in einem Zustand ist, das durch serielle Abarbeitung erreicht werden würde. Siehe auch Hans de Vries excellenten Artikel (http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html#1.11).
Wie willst du denn etwas durch den Compiler umsortieren, wenn es zur Compilezeit garnicht nicht feststeht?Sehr berechtigter Einwand :)
Was steht da nicht fest? :|
Die Reihenfolge der Befehle sicherlich und um was anderes geht es bei Out-Of-Order nicht...Das größte Problem für In-Order CPUs stellt die mangelnde Flexibilität dar, auf Cache Misses zu reagieren. Diesen Fall kann man nicht zur Compile-Zeit voraussehen. Wenn er denn eintritt, steht die CPU für Hunderte von Takten still, selbst wenn es genügend unabhängige Befehle gäbe, die sie in der Zwischenzeit ausführen könnte.

Das ist die eigentliche Stärke von OOO-Issue und auch ein Grund, warum der (In-Order) Itanium so riesige Cache hat und braucht. Cache Misses sind hier unglaublich teuer.
Die Fähigkeit unabhängige Befehle zu finden, hängt natürlich mit der Größe des Befehlsfensters und der Pipelinelänge zusammen. Je größer das Befehlsfenster ist, desto mehr Befehle kann der Prozessor gleichzeitig bearbeiten und der Scheduler damit auswählen. Je mehr von dieser Anzahl an Befehlen in den Ausführungspipelines steckt, desto weniger Auswahl hat der Scheduler.
Deswegen hat z.B. der P4 trotz größerem Befehlsfenster (127 Befehle) gegenüber dem Athlon (72 Befehle) wahrscheinlich weniger Möglichkeiten für OOO-Issue, weil dessen (Ausführungs-)Pipeline wesentlich länger als die des Athlons sind. Die EV6 Alpha besitzt damit wohl den Titel, der am aggressivsten OOO-Issue betreibenden CPU (80 Befehle, sehr kurz Pipeline). Der PPC970 hat ein Befehlsfenster von über 200, wobei diese aber nicht einzeln geschedult werden können, sondern nur in 5er Gruppen. Insofern kann man diese Zahl nicht direkt mit den der anderen CPUs vergleichen.

Zusätzlich zu der Fähigkeit, bei einem Cache Miss noch weiterzuarbeiten, bringt natürlich OOO-Execution mehr Parallelität der Befehle mit sich. Auch wenn der Compiler probiert, den Code so anzuordnen, dass er optimal parallel in einer In-Order CPU ausgeführt werden kann, so ist dies auch nicht immer möglich. Bei Sprüngen kann eine In-Order CPU die Befehle vor und nach dem Sprung nicht gleichzeitig ausführen, sondern nur die vor dem Sprung und danach die nach dem Sprung.


Bezüglich der Konsolen und besonders Cell: OOO-Execution ist bei Vektoroperationen quasie uninteressant, weil es nichts bringt. Bei vektorisiertem Code ist genügend Parallelität vorhanden. Die einzelne Ausführungszeit eines Befehls ist auch fast uninteressant, weil es keinen gibt, der auf diesen angewiesen ist. Die Speicherbandbreite ist hier vor allem das entscheidende Kriterium, nicht die Latenz (siehe dazu auch hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=2846362#post2846362)).

Ein Cell mit OOO-Issue würde sicher keinen Sinn ergeben (zumindest nicht für die SPEs).

[mocad_tom]

Kommt darauf an, wie stark man die skalaren Einheiten der SPEs mit einbeziehen kann.
Ist ja nicht so, dass diese reine Vektoreinheiten wären, welche ohne vektorisierten Code nur idle laufen.

http://www.realworldtech.com/page.cfm?ArticleID=RWT021005084318&p=5
Die äusserst kurze Pipeline in Verbindung mit dem sehr hohen Takt - das klingt schon sehr vielversprechend.
Gut sortierte gewichtete Bäume und Graphen(z.B.Kollisionsabfrage), A-Stern-Algorithmen und zum Teil auch K.I. lassen sich damit performant bearbeiten. Und das waren jetzt noch nicht mal die wirklichen SIMD-Aufgaben.

Physik, Partikel-Systeme, Spline- und Curve-Tesselation, dynamische Erzeugung von z.B. Bäume wie es in der Unreal Engine unlängst vorgestellt wurde - für solche Sachen sind die SPEs geradezu maßgeschneidert.

Für die PPE bleibt dann fast nur noch die Game-Loop und nicht beherrschbare, komplexere K.I. über.

Das erinnert mich an die gute alte SNES-Zeit. Immer wenn in Zelda ein Endmonster anrückte mussten sich alle anderen Feinde verpissen, weil die Rechenleistung nicht mehr reichte :)

Dennoch denke ich, das sich die XBox2-CPU leichter auszureizen. Microsoft hat für die XBox2 das NovodeX-SDK lizensiert. Die Spiele-Entwickler müssen nicht jedesmal das Rad neu erfinden - die Lasten selbst verteilen - eine auf die Hardware optimierte Bibliothek nehmen dem Entwickler dies ab.

Wobei hier Sony mit Havok eng zusammenarbeitet.

Grüße,
Tom

[RLZ]

Dennoch denke ich, das sich die XBox2-CPU leichter auszureizen. Microsoft hat für die XBox2 das NovodeX-SDK lizensiert. Die Spiele-Entwickler müssen nicht jedesmal das Rad neu erfinden - die Lasten selbst verteilen - eine auf die Hardware optimierte Bibliothek nehmen dem Entwickler dies ab.
Die Novodex-SDK ist auch für die PS3 verfügbar. ;)
Inwiefern man die SPE´s im Cell für irgendwas verwenden kann wird wohl extrem davon abhängen welche Möglichkeiten für den Zugriff auf die Dinger hat.
Da werden wir aber wohl bald schlauer sein.
Das Programmierbeispiel auf der Konferenz morgen von 17.40-18.20 Uhr wird wohl schon einiges beantworten. :)

[Gast]

Die Novodex-SDK ist auch für die PS3 verfügbar. ;)
Inwiefern man die SPE´s im Cell für irgendwas verwenden kann wird wohl extrem davon abhängen welche Möglichkeiten für den Zugriff auf die Dinger hat.
Da werden wir aber wohl bald schlauer sein.
Das Programmierbeispiel auf der Konferenz morgen von 17.40-18.20 Uhr wird wohl schon einiges beantworten. :)

Welche Konfrerenz?

[RLZ]

Welche Konfrerenz?
http://www.power.org/news/events/barcelona/
Idealerweise ist aber der Broadcastserver total überlastet....

[Muh-sagt-die-Kuh]

Das größte Problem für In-Order CPUs stellt die mangelnde Flexibilität dar, auf Cache Misses zu reagieren. Diesen Fall kann man nicht zur Compile-Zeit voraussehen. Wenn er denn eintritt, steht die CPU für Hunderte von Takten still, selbst wenn es genügend unabhängige Befehle gäbe, die sie in der Zwischenzeit ausführen könnte.Auch dafür gibt es eine brauchbare Lösung: Switch-on-Event Multithreading, wie es u.A. im kommenden Itanium-(Doppel)Kern Montecito realisiert wird.Das ist die eigentliche Stärke von OOO-Issue und auch ein Grund, warum der (In-Order) Itanium so riesige Cache hat und braucht. Cache Misses sind hier unglaublich teuer.Der andere Grund ist der "leicht" platzfressende Befehlssatz ;)

[mocad_tom]

Die Novodex-SDK ist auch für die PS3 verfügbar. ;)

Ich dachte das M$ das Novodex-SDK bereits lizensiert und soweit in das Development-Kit integriert hat, das es keine zusätzlichen Kosten für 3rd-Party-Firmen gibt - nur noch die Tantiemen, die z.B. EA an M$ abführen muss.

Grüße,
Tom