Multi Core Cpus: die Zukunft (am Beispiel von CELL)

[tombman]

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2379

Imo einer der besten Anandtech Artikel die ich kenne: super informativ, aber für jedermann verständlich :)

MUST READ! :)

[GloomY]

Auch ich kann der Aussage von Tombman nur zustimmen, dass dieser Artikel definitiv lesenswert ist, auch wenn mir schon viele der Details von Cell zuvor bekannt waren. :)

Schön, dass sich jemand mal die Mühe gemacht hat und pseudo-NMOS erklärt hat, auch wenn ich nicht ganz nachvollziehen konnte, warum das schneller schalten soll als statisches CMOS. :confused:

[Quasar]

What’s the big deal then? With the absence of cache, but the presence of a very low latency memory, each SPE effectively has controllable, predictable memory latencies. This means that a smart developer, or smart compiler, could schedule instructions for each SPE extremely granularly. The compiler would know exactly when data would be ready from the local memory, and thus, could schedule instructions and work around memory latencies just as well as an out-of-order microprocessor, but without the additional hardware complexity. If the SPE needs data that’s stored in the main memory attached to the Cell, the latencies are just as predictable, since once again, there’s no cache to worry about mucking things up.

Vielleicht ist es zu kurz gedacht, aber für mich klingt das nach der Logik: Ich gehe lieber zu Fuß, da kommt mir kein Stau dazwischen und ich kann mit zwei Stunden Weg kalkulieren. (Anstatt die zwei Stunden mit dem Auto als Worst-Case anzunehmen und die gesparte Zeit als Bonus einzukalkulieren).

Oder ist die gesparte Zeit, um in meinem Analog zu bleiben, es am Ende nicht wert, sich überhaupt ein Auto anzuschaffen?
(Wobei das ja nur auf die Existenz des Caches, nicht aber einer In-Order-Struktur erstrecken würde)

[mrdigital]

...
Schön, dass sich jemand mal die Mühe gemacht hat und pseudo-NMOS erklärt hat, auch wenn ich nicht ganz nachvollziehen konnte, warum das schneller schalten soll als statisches CMOS. :confused:
Man muss nur noch die Kapazitäten von den N Kanal Transistoren umladen und nicht mehr die von den N und PMOS. Ausserdem ist die Ladungsträgerbeweglichkeit in NMOS ca. doppelt so groß wie in PMOS, daher mussten die PMOS immer doppelt so breite Kanäle haben. Dadurch steigt aber auch der kapazitive Belag im PMOS Zweig und es muss noch mehr Ladung umgeschaufelt werden. Und hier gewinnt Pseudo NMOS Logik :)
Edit: Die Spannung an einer Kapazität kann nicht springen, d.h dI / dt ist nicht unendlich, und genau das limitiert die Schaltzeiten eines Transitors.

[Muh-sagt-die-Kuh]

Der Artikel ist insofern lesenswert, da er den grundlegenden Aufbau von Cell anschaulich erläutert. Die eingestreuten Ausflüge in In-Order / Out-of-Order und Design von Logik-Schaltungen machen es dem normalen Leser auch einfacher, den Artikel zu verstehen.

Mir persönlich sind die beiden Real World Tech Artikel ([1] (http://www.realworldtech.com/page.cfm?ArticleID=RWT021005084318) [2] (http://www.realworldtech.com/page.cfm?ArticleID=RWT022805234129))lieber, einem normalen Anandtech Leser würde ich diese aber nicht zumuten ;)

[tombman]

Mir gings gar ned mal so um Cell, sondern um den Gedanken wie man Leistung in Zukunft steigert generell. Intel/Amd springen ja praktisch (wenn auch lange ned so radikal) auf den selben Zug auf- multi core is einfach geil ;)

Außerdem finde ich es beachtlich, daß alte Techniken wie in-order rangenommen werden um Leistung zu bekommen, einfach durch puren speed, der früher ned da war.

[Muh-sagt-die-Kuh]

Mir gings gar ned mal so um Cell, sondern um den Gedanken wie man Leistung in Zukunft steigert generell. Intel/Amd springen ja praktisch (wenn auch lange ned so radikal) auf den selben Zug auf- multi core is einfach geil ;)Wobei Cell deutlich anders aufgebaut ist als ein kommender intel oder AMD Dual-Core. So einfach es ist 8 oder mehr Vektorprozessoren mit lokalem Speicher (das sind die SPEs) auf einen DIE zu knallen, so schwer sind diese Spezialisten zu programmieren bzw. so schwer ist es, sie effizient zu nutzen. Bei einem SMP System hat man zwar auch so seine Probleme mit Thread-Synchronisation, Deadlocks und co....dafür aber kaum Einschränkungen beim Speicher und ungenutzte Leistung.Außerdem finde ich es beachtlich, daß alte Techniken wie in-order rangenommen werden um Leistung zu bekommen, einfach durch puren speed, der früher ned da war.Effektives Out-of-Order mit einem großen Instruction-Window kostet eine Menge Transistoren.....da der PowerPC Core hier nicht viel mehr macht als Aufgaben zu verteilen tut es auch ein einfaches In-Order Design und man hat mehr Transistoren für die anderen Bereiche der CPU übrig.

[tombman]

Wobei Cell deutlich anders aufgebaut ist als ein kommender intel oder AMD Dual-Core. So einfach es ist 8 oder mehr Vektorprozessoren mit lokalem Speicher (das sind die SPEs) auf einen DIE zu knallen, so schwer sind diese Spezialisten zu programmieren bzw. so schwer ist es, sie effizient zu nutzen. Bei einem SMP System hat man zwar auch so seine Probleme mit Thread-Synchronisation, Deadlocks und co....dafür aber kaum Einschränkungen beim Speicher und ungenutzte Leistung.Effektives Out-of-Order mit einem großen Instruction-Window kostet eine Menge Transistoren.....da der PowerPC Core hier nicht viel mehr macht als Aufgaben zu verteilen tut es auch ein einfaches In-Order Design und man hat mehr Transistoren für die anderen Bereiche der CPU übrig.

na der PPE interssiert mich eher weniger, ich find die 8 SPEs einfach nur PIMP :D

[mrdigital]

Naja, wenn du so willst, hat ein NV40 sowas auch schon, 16 Pixelpipelines, die SM3 machen können, gehen in eine ähnliche Richtung ;)

[HellHorse]

na der PPE interssiert mich eher weniger, ich find die 8 SPEs einfach nur PIMP :D
Und was bringen die, wenn sie nicht (richtig) genutzt werden. :confused:

[tombman]

Und was bringen die, wenn sie nicht (richtig) genutzt werden. :confused:

Genauso viel wie ein Ferrari in den Händen eines Fahrschülers- nix- was aber den Ferrari ned weniger geil macht ;)

[Coda]

Wüsste nicht was daran so spektakulär ist. Die Pixelshader deiner NV40 sind sehr ähnlich...

Mir gings gar ned mal so um Cell, sondern um den Gedanken wie man Leistung in Zukunft steigert generell. Intel/Amd springen ja praktisch (wenn auch lange ned so radikal) auf den selben Zug auf- multi core is einfach geil Multicore ist eine krasse Notlösung und alles andere als toll. Mir wären 10Ghz P4s lieber gewesen.

[Muh-sagt-die-Kuh]

na der PPE interssiert mich eher weniger, ich find die 8 SPEs einfach nur PIMP :DWas ist an Vektoreinheiten mit ein bischen Speicher so spektakulär?

[Coda]

Der Hype anscheinend :rolleyes:

[tombman]

Der Hype anscheinend :rolleyes:

und diesmal is der hype imo gerechtfertigt....

[GloomY]

Vielleicht ist es zu kurz gedacht, aber für mich klingt das nach der Logik: Ich gehe lieber zu Fuß, da kommt mir kein Stau dazwischen und ich kann mit zwei Stunden Weg kalkulieren. (Anstatt die zwei Stunden mit dem Auto als Worst-Case anzunehmen und die gesparte Zeit als Bonus einzukalkulieren).

Oder ist die gesparte Zeit, um in meinem Analog zu bleiben, es am Ende nicht wert, sich überhaupt ein Auto anzuschaffen?
(Wobei das ja nur auf die Existenz des Caches, nicht aber einer In-Order-Struktur erstrecken würde)Ich finde dies zumindest auch nicht wirklich glücklich formuliert. Dass die Speicherzugriffszeiten einheitlich und daher vorhersehbar sind, hilft nicht darüber hinweg, dass diese vorhersehbar schlecht sind (ohne Cache).

Der entscheidende Punkt ist hier aber, dass die Speicherzugriffszeiten bei einem Vektorrechner eben nicht für die Performance entscheidend sind. Zuminders längst nicht so entscheidend wie für einen (Super-)Skalarprozessor. Denn im Gegensatz dazu kann man die Zugriffszeiten bei einem Vektorrechner hinter anderen Berechnungen verstecken, so dass hier nur die einmalige Anfangszugriffszeit die Performance beeinflusst. Danach hat man die Vektoroperation gestartet und streamed ohne Verzögerung durch den Speicher (d.h. man macht Burst-Übertragungen mit linear anstiegenden Adressen ohne dass die Zugriffszeit einen Einfluss darauf hat.)

Hier liegt eben ein grundsätzlicher Unterschied zwischen einem Vektor- und einem Skalarrechner. Ein Vektor besteht eben immer aus einer Menge von einzelnen Datenelementen, die nacheinander mit den Datenelementen anderer Vektoren arithmetisch verknüpft werden. Dabei bestehen keinerlei Abhängigkeiten zwischen den einzelnen Datenelementen der Vektoren, so dass man hier die Berechnung zeitlich beliebig datieren kann.


Anschauliches Beispiel: Addition zweier Vektoren. Dabei wird zuerst Element 1 von Vektor1 mit Element1 von Vektor2 addiert und das Ergebnis in Element1 eines Ergebnisvektors zurückgeschrieben. Im nächsten Takt addiert man die Elemente Nummer 2 der beiden Vektoren und schreibt das Ergebnis in Element2 des Ergebnisvektors usw.
Die Zugriffe auf die stets folgenden Elemente der Vektoren sind alles Bursts, also Zugriffe auf nachfolgende (aufsteigende) Adressen. Und das geht recht fix :)


Die Länge des Vektors beeinflusst hierbei, wie stark die anfängliche Zugriffszeit Einfluss auf die Gesamtperformance hat. Beispiel:
Zugriffszeit für einen random Access: Sagen wir mal ziemlich schlechte 200 Takte, danach jeden Takt ein Datenwort (=Element des Vektors). Nehmen wir mal weiterhin an, dass wir je ein Wort gleichzeitig lesen und schreiben können (bei Cell nicht ganz richtig, aber ein echter Vektorrechner kann das).
Da wir pro Operation 2 Lesezugriffe und einen Schreibzugriff brauchen, können wir also (im Schnitt) alle 2 Takte eine Berechnung fertigstellen.

Bei einer Vektorlänge von 20 dauert diese Operation dann 238 Takte. 200 für den anfänglichen Zugriff und 2*19=38 für die weiteren 19 Elemente des Vektors.
Der Vektorrechner kann also nur 20/238 = ~ 8,4% seiner maximalen Leistung entfalten (20 Operationen alle 238 Takte)
Bei einer Vektorlänge von 100 sieht das aber schon anders aus:
Hier braucht man insgesamt 398 Takte für 100 Operationen (200+2*99) und kommt somit auf etwa 25% der theoretischen Rechenleistung (trotz beschissener Zugriffszeiten).
Bei entsprechend längeren Vektoren kommt man auf noch bessere Ergebnisse. :)

Deswegen definiert man für einen Vektorrechner oftmals auch ein n1/2 (n mit Index 1/2), was aussagt, bei welcher Vektorlänge man die Hälfte der theoretischen Leistung erreicht.
Jedoch multipliziert sich der n1/2 Wert mit der Anzahl der Pipelines und beim Cell natürlich auch mit der Anzahl der SPEs, so dass hier wahrscheinlich ein recht hoher Wert herauskommen dürfte (zusammen mit der recht schlechten Zugriffszeit des DRAMs). Ich schätze irgendwas um die 500 für n1/2 (ähnlich der Fujitsu VPP5000 mit ihren 16 Vektorpipelines, welche ebenso um diesen Dreh liegen dürfte oder die SX-5 des Earth Simulators).

Naja, jetzt hab' ich aber fast schon ein bisschen sehr viel zum Thema Vektorrechner geschrieben (Sorry, falls zu OT). Also zusammenfassend ist für Vektoroperation die Zugriffszeit längst nicht so kritisch wie für einen Skalarrechner. Für Vektorrechner zählt letztendlich hauptsächlich Bandbreite.


und diesmal is der hype imo gerechtfertigt....weil...?

[Coda]

Und diesmal is der hype imo gerechtfertigt....Sorry, aber weil du das auch beurteilen kannst :rolleyes:

[tombman]

Sorry, aber weil du das auch beurteilen kannst :rolleyes:

red ma in 5 Jahren weiter und sehen ob ich Recht hatte.. Cell-like designs sind die Zukunft.

[Quasar]

Die Zukunft? Sicherlich nicht, solange der gemeine Windoof-PC noch nach Abwärtskompatibilität mit uralt-Software schreit.

Und momentan scheint man ja mit PPC-Cores die meiste Leistung freisetzen zu können, wie IBM einmal mehr bewiesen hat.

[Coda]

red ma in 5 Jahren weiter und sehen ob ich Recht hatte.. Cell-like designs sind die Zukunft.Hab ich ja auch nicht bestritten, weil die Zukunft der einzige Ausweg aus der Misere ist in der wir uns befinden.
Wie gesagt ist das Multicorezeug nur eine Notlösung, die für Entwickler die Hölle bedeutet.

[tombman]

Die Zukunft? Sicherlich nicht, solange der gemeine Windoof-PC noch nach Abwärtskompatibilität mit uralt-Software schreit.

Und momentan scheint man ja mit PPC-Cores die meiste Leistung freisetzen zu können, wie IBM einmal mehr bewiesen hat.

Kommt drauf an wie weit in der Zukunft ;)

[desperado2000]

Warum gibts keine Dual Core Grafikkarten?
Ist doch billiger als 2 GPUs auf ner Karte...oder?

[Muh-sagt-die-Kuh]

red ma in 5 Jahren weiter und sehen ob ich Recht hatte.. Cell-like designs sind die Zukunft.Wie wäre es wenn du anfängst, deine Aussagen / Behauptungen zu begründen....einzeilige Kommentare sind echt eine super Grundlage für eine Diskussion :|

[Muh-sagt-die-Kuh]

Warum gibts keine Dual Core Grafikkarten?
Ist doch billiger als 2 GPUs auf ner Karte...oder?Rendering ist fast beliebig parallelisierbar, als Hersteller packst du also so viele Pipelines / Quads auf deinen Chip dass du noch eine gescheite Ausbeute erhältst. Wenn man eine Pipeline / ein Quad als Core betrachtet so sind Grafikchips schon weit in die Multicore-Welt vorgedrungen ;)

[mapel110]

Rendering ist fast beliebig parallelisierbar, als Hersteller packst du also so viele Pipelines / Quads auf deinen Chip dass du noch eine gescheite Ausbeute erhältst. Wenn man eine Pipeline / ein Quad als Core betrachtet so sind Grafikchips schon weit in die Multicore-Welt vorgedrungen ;)
Jup, und man hats schwieriger 2 Cores zu verbauen, weil man dann auch Probleme mit dem Graka-Speicher bekommt. Entweder man verbaut ihn doppelt oder man teilt. Beides ist suboptimal. :)

SLI hat ja schon das Problem, dass man entweder abwechselnd Frames rendern muss oder das Bild "aufteilt nach Last". Wenn man 2 Cores auf einen Die packen will, müsste man sich wohl für eine der beiden Möglichkeiten entscheiden(fest verdrahten) und dann gäbs wohl zwangsweise Inkompatibilitäten.
Oder sehe ich das falsch?!

[Tigerchen]

red ma in 5 Jahren weiter und sehen ob ich Recht hatte.. Cell-like designs sind die Zukunft.


Ich möchte mal die Frage aufwerfen ob es nicht ohnehin schon schwer genug ist ein gutes Spiel zu machen. Muß man da den Entwicklern auch noch eine CPU zumuten die hochoptimierten Code braucht um ein gescheites Ergebnis abzuliefern.

[Tigerchen]

Die Zukunft? Sicherlich nicht, solange der gemeine Windoof-PC noch nach Abwärtskompatibilität mit uralt-Software schreit.

Und momentan scheint man ja mit PPC-Cores die meiste Leistung freisetzen zu können, wie IBM einmal mehr bewiesen hat.


Sind schon die ersten PS3 Titel da die diese Aussage belegen?

[dirk.loesche]

Ich sag mal abwarten und Tee drinken!

Wenn die Entwickler erstmal begriffen haben wofür genau sie die vielen Vektoreinheiten verwenden können wird das für sie auch nicht mehr so schwer sein. Aber 1-2 Jahre werden da schon vergehen bis da ordentlich drauf optimierte Software läuft.

OT:
Vielleicht machen die ja dann mal in Spielen ordentliche Gegneranimationen rein. Wo auch die Masse und deren Trägheit der Gegener mit berücksichtigt wird. Dummdidi... :-)

[GloomY]

Hmm, ich wollte ja noch was hierzu schreiben: :|Man muss nur noch die Kapazitäten von den N Kanal Transistoren umladen und nicht mehr die von den N und PMOS. Ausserdem ist die Ladungsträgerbeweglichkeit in NMOS ca. doppelt so groß wie in PMOS, daher mussten die PMOS immer doppelt so breite Kanäle haben. Dadurch steigt aber auch der kapazitive Belag im PMOS Zweig und es muss noch mehr Ladung umgeschaufelt werden. Und hier gewinnt Pseudo NMOS Logik :)Danke für die Erklärung. =)

Sehe ich das richtig, dass aber bei pseudo NMOS (warum heisst das "pseudo"? Es ist doch im Prinzip reines NMOS!?) aber bei jedem Takt Ladung von Vdd nach Ground fliesst? D.h. dass dies die Ziele von CMOS nicht erreichen kann?
Werden deswegen nur kleine Teile eines Chips und nicht der komplette Chip in pseudo NMOS implementiert?
Edit: Die Spannung an einer Kapazität kann nicht springen, d.h dI / dt ist nicht unendlich, und genau das limitiert die Schaltzeiten eines Transitors.Klingt logisch =)
Das Ding wird vielleicht mit nem 1Ghz Athlon mithalten können wenn's gut geht.Was Skalar-Code angeht, wohl schon. Der läuft dann aber wohl fast ausschliesslich auf dem PPE. Und das ist aber nicht umbedingt das primäre Ziel von Cell.
Sagt dir In Order überhaupt was?Bei vollkommen vektorisiertem Code hat Out-of-Order Execution gegenüber In-Order praktisch keinerlei Vorteil. Das kann man sich grad' sparen.

Das heisst natürlich nicht, dass der PPE keine OOO-Execution gebrauchen könnte. Dieser ist ein "normaler" Prozessor, d.h. er bewältigt Skalar-Operationen. Der eigentliche Speed kommt aber von den acht SPEs, und die sind auf Vektorberechnung spezialisiert. Dort macht OOO dann eben keinen Sinn.

Amdahl's Law sagt uns, dass wenn der Geschwindigkeitsunterschied (Speedup) zwischen Skalar- und Vektor-Ausführung recht groß ist, dann ist es ungemein wichtig für gute Performance, dass der Anteil der schnelleren Ausführung (Vektoroperation) an der Gesamtausführungszeit sehr (!) groß ist. Schon kleine Reduzierungen (z.B. 5%) können hier die Performance halbieren. :|

D.h. dass der Grad der Vektorisierung wohl einen sehr großen Einfluss darauf haben wird, wie schnell Cell nun wirklich in der Praxis sein wird. Und da kommt es letztendlich dann auf Programmierer bzw. Compiler an, die automatisch vektorisieren können usw.

[mrdigital]

Hmm, ich wollte ja noch was hierzu schreiben: :|Danke für die Erklärung. =)

Bitte :)

Sehe ich das richtig, dass aber bei pseudo NMOS (warum heisst das "pseudo"?

keine Ahnung, ich hab dieses Prinzip unter dynamischer Logik kennengelernt, es scheint also mehrere Begriffe dafür zu geben.

Es ist doch im Prinzip reines NMOS!?) aber bei jedem Takt Ladung von Vdd nach Ground fliesst? D.h. dass dies die Ziele von CMOS nicht erreichen kann?
Werden deswegen nur kleine Teile eines Chips und nicht der komplette Chip in pseudo NMOS implementiert?

genau so ist es :). Dazu kommt noch die große Herausforderung mit dem Takt. Jedes Gatter in pseudo NMOS muss mit einem symetrischen Takt versorgt werden. Das ist nicht ganz trivial (Stichwort Signallaufzeiten) und geht auch gewaltig in die Energiebilanz, denn Taktreiber wollen auch gefüttert werden.

[Stone2001]

Sehe ich das richtig, dass aber bei pseudo NMOS (warum heisst das "pseudo"? Es ist doch im Prinzip reines NMOS!?)
Fast! Das "pseudo" kommt dadurch, das der Lasttransistor ein p-Kanal-Transistor ist und nicht wie in nMOS ein n-Kanal-Transistor.
Allerdings würde ich hier auch nicht den Begriff 'Pseudo nMOS' verwenden, sondern 'dynamische Logik', da Teile der Schaltung getaktet sind. Die Bezeichung ist aber nicht einheitlich.

Auch findet man auf der Folie von Intel nicht den Begriff 'Pseudo nMOS' ö.ä., sondern nur Sleep-Transistors. Wenn ich mal Zeit habe, werde ich mal in der Datenbank von Intel wühlen, vielleicht finde ich den Artikel woraus die Folie stammt. (Falls jemand den Artikel / Präsentation hat...). Interessant ist an dieser Folie aber auch das linke Beispiel zur Reduktion, der Leckströme, indem man die Source-Substrat auf negative Werte legt.

Vielleicht sollte man mal einen Grundlagenartikel über sowas schreiben. :uponder:

Sehe ich das richtig, dass aber bei pseudo NMOS bei jedem Takt Ladung von Vdd nach Ground fliesst?
Nein, kommt auf die Werte der Inputs an.
Beispiel NOR-Gatter aus dem Artikel: Wenn beide Input "Low" sind, sind die Logik-Transistoren gesperrt. Öffnet man jetzt den getakteten p-Kanal-Transistor, wird der Ausgang auf "High" gezogen. Öffnet danach der n-Kanal-Transistor kann die Ladung nicht über die beiden Logik-Transistoren zu Ground abfließen.
Ist aber einer der beiden (oder beide) Logik-Transistoren geöffnet, wird jedesmal beim Takt Ladung umgeladen.

Was halt bei dieser Logik nicht auftritt, sind die Kurzschlußströme beim umschalten des Gatters. Im Umschaltpunkt (meistens bei Udd/2) sind bei Transistoren in gesättigtem Mode und es gilt, das die Drainströme durch den n-Kanal- und den p-Kanalbereich gleich sind.
Diese Ströme machen noch zur Zeit den Hauptteil der Verlustleistung aus, deswegen dürfte die dynamische Logik hier Vorteile haben.

Werden deswegen nur kleine Teile eines Chips und nicht der komplette Chip in pseudo NMOS implementiert?
Wie im Artikel schon angesprochen, dürfte es ein riesiges Problem sein, jedes Gatter mit einem Takt zu versehen. Da kann man gleich mal ein paar Lagen Metall für die Taktverteilung reservieren. ;) Auch dürfte die Verlustleistung der Treiber auch nicht gerade klein sein und zuletzt hat man noch das Problem mit dem Skew (Verschiebung äquivalenter Taktflaken) und Jitter. Man bedenke, ein cm Leitung verursacht eine Flankenverschiebung von 66 ps. Der H-Tree eines Alpha 21164 war schon 57cm lang, ich will nicht wissen, wie lang die Leitungen für einen Cell-Prozessor sind.