Cell und Alpha AXP

[Gast]

Ich möchte mal einen Vergleich wagen:

Man nehme 8 Digital Alpha CPU's (z.B. vom Typ 21064A)
erhöhe den 1st-Level Cache auf 256 KB,
takte jeden mit 3.2 GHz, erweitere die 2*32 Register auf 128,
spendiere eine Zentralinstanz, packe alles auf einen Chip,
fasse einen Vektor als viele viele Bits auf und nenne das ganze "Alpha-Cell".
Das ganze nimmt schlappe 80 Watt auf.

Und nun meine Frage an die Cell-Kritiker:
Wer von Euch würde ein 1x, 2x, 4x oder 8x X86 System
NICHT gegen diesen Alpha-Cell eintauschen ?

[Coda]

Seit wann sind Alphas Streamprozessoren?

[Gast]

Gegenfrage: Was hindert mich daran, die SPU's wie "normale Alphas" zu verwenden ?

[Demirug]

Da wird dir wohl schon der Befehlssatz der SPUs einen Strich durch die Rechnung machen.

[Gast]

Ich kann mich täuschen, aber ich denke schon das der Befehlssatz
einigermaßen brauchbar sein wird, nicht nur für streambare Probleme :)
und der hier im Forum genannte Link
http://www.hpcaconf.org/hpca11/papers/25_hofstee-cellprocessor_final.pdf
sagt doch auch nichts Gegenteiliges.

Warten wir mal die Publikation des "offiziellen" Befehlssatzes
des Cell's ab !

Würde mich wundern, wenn IBM & Co den Cell nicht schon im Simulator/Emulator
(s. Alpha's, Itaniums, Mac's) erfolgreich auf seine Tauglichkeit z.B. für
die PS3 getestet hätten.

[Demirug]

Ich bezog mich hier eher darauf das die SPUs keinen direkten Speicherzugriff haben. Das macht es komplizierter eine solche Einheit als GP-CPU zu nutzen.

Ansonsten muss man noch warten bis Sony die Details rausrückt.

Natürlich wird Sony die Tauglichkeit des Cell Konzept für Spiele untersucht haben. Es gibt ja in einem Spiel durchaus einige Dinge die man mit einem Streamprozessor erledigen kann.

[GloomY]

Ich möchte mal einen Vergleich wagen:

Man nehme 8 Digital Alpha CPU's (z.B. vom Typ 21064A)
erhöhe den 1st-Level Cache auf 256 KB,
takte jeden mit 3.2 GHz, erweitere die 2*32 Register auf 128,
spendiere eine Zentralinstanz, packe alles auf einen Chip,
fasse einen Vektor als viele viele Bits auf und nenne das ganze "Alpha-Cell".
Das ganze nimmt schlappe 80 Watt auf.

Und nun meine Frage an die Cell-Kritiker:
Wer von Euch würde ein 1x, 2x, 4x oder 8x X86 System
NICHT gegen diesen Alpha-Cell eintauschen ?Der erste Alpha Prozessor mit Unterstützung für SIMD Operationen war der 21164PC (Motion Video Instructions). Mit dem Befehlssatz des 21064A wäre es um einiges schwieriger, einen Streaming-Prozessor zu bauen.


Demirug,

die SPUs können doch auch Datan aus dem Hauptspeicher in ihren kleinen Zwischenspeicher laden, oder?

[Demirug]

Demirug,

die SPUs können doch auch Datan aus dem Hauptspeicher in ihren kleinen Zwischenspeicher laden, oder?

Ja, aber nur über den DMA Controller. Der Zugriff ist dann erst möglich wenn der Transfer abgeschlossen ist. Man muss also recht genau planen.

IMHO hätte man das mit einer 3 Stufen Architektur anstelle der 2 Stufen besser lösen können.

[Gast]

Ich kann mich täuschen, aber ich denke schon das der Befehlssatz
einigermaßen brauchbar sein wird, nicht nur für streambare Probleme :)
und der hier im Forum genannte Link
http://www.hpcaconf.org/hpca11/papers/25_hofstee-cellprocessor_final.pdf
sagt doch auch nichts Gegenteiliges.

Warten wir mal die Publikation des "offiziellen" Befehlssatzes
des Cell's ab !

Würde mich wundern, wenn IBM & Co den Cell nicht schon im Simulator/Emulator
(s. Alpha's, Itaniums, Mac's) erfolgreich auf seine Tauglichkeit z.B. für
die PS3 getestet hätten.
Die Infos sind schon bekant, nur der Befehlssatz nicht. Was auch noch wichtig ist, wieviel Takt eine SPE pro Befehl benötigt.
Ja, aber nur über den DMA Controller. Der Zugriff ist dann erst möglich wenn der Transfer abgeschlossen ist. Man muss also recht genau planen.

IMHO hätte man das mit einer 3 Stufen Architektur anstelle der 2 Stufen besser lösen können.
3 Stufen Architektur in Bezug auf Speicher? Ich dachte der Cell hätte dies.

[Demirug]

3 Stufen Architektur in Bezug auf Speicher? Ich dachte der Cell hätte dies.

3 Stufen im Bezug auf die Programmausführung.

Soweit ich das ganze aufgrund der spärlichen Informationen verstanden habe startet der PowerPC Kern die Programme in den SPUs. Diese Programme müssen sich dann selbst darum kümmern das die erforderlichen Daten in den Speicherblock geladen werden und auch wieder zurück in den Hautspeicher gelangen. Das Problem dabei ist nun vollgendes. Der Befehl zum laden des Speicher muss soweit im vorraus erfolgen das die Daten rechtzetig wenn sie gebraucht werden verfügbar sind. Speicherlatenzen sind nun aber in einem solchen System schwer vorher zu bestimmen.

Bei einem 3 Stufen System würde der Steuerkern den DMA controller anweisen die Daten zu laden. Dieser würde dann nachdem dies erfolgt ist das entsprechenden SPU Programm zur Ausführung bringen. Nach dem Berechnen meldet die SPU dem DMA Controller die Ausführung welcher dann die Daten an die vorgesehen Speicherstelle kopiert. Damit das ganze nun schön kontinuirlich laufen kann teilt man den Speicher in zwei Bereiche. Einer wird dann immer von den SPUs bearbeitet und der zweite vom DMA controller.

In einer solchen 3 Stufen Architektur kann man die Bandbreite in der Regel besser verteilen weil der DMA controller über mehr Informationen verfügt.

Es ist natürlich noch durchaus möglich das man bei Cell vorgesehen hat das man dem DMA controller zusätzliche Metadaten mitgeben kann.

[Gast]

[QUOTE=Gast]Die Infos sind schon bekant, nur der Befehlssatz nicht. Was auch noch wichtig ist, wieviel Takt eine SPE pro Befehl benötigt.

Ok, aber Kapitel 6 des genannten Links sagt:
"The dual issue SPE consists of ..."

Ich würde deshalb ableiten, eine SPE kann prinzipiell zwei Befehle pro Takt
ausführen bzw. in die Pipeline schieben.

@GloomY: Der 21064 unterstützt ebenfalls "dual issue" und kennt kein
register renaming, out of order execution und all den Schnick-Schnack der
Transistoren und Strom frißt. Daher der Vergleich mit den SPE's.

</OT: Irgendwie werd ich das Gefühl nicht los, mein 1994 angeschaffter Alpha
ist seiner Zeit > 10 Jahre voraus ;-) >

[Coda]

Dann verstehe ich nicht auf was du hinaus willst. Was soll an 8 von den Teilen so toll sein?

[GloomY]

Dann verstehe ich nicht auf was du hinaus willst. Was soll an 8 von den Teilen so toll sein?Ich glaube er will anders herum argumentieren. Die SPEs des Cells sind eigentlich nicht wirklich toll. Im Prinzip sei jede SPE mit einer 21064 Alpha vergleichbar. Habe ich das richtig verstanden, werter Gast?

Jedoch macht eben genau das die Stärke des Cells aus. Mehrere kleine Cores, die für Streaming optimiert sind zusammen mit einem Core, der für die Steuerung der SPEs und der Berechnung von Skalar-Code zuständig ist. Es ist imho vielmehr das Design - sprich: Die Zusammensetzung - als die Leistungen jeder einzelnen Einheit, die den Cell so interessant machen.

[Gast]

Ja genau GloomY, wir verstehen uns :)

Ich glaube, daß Cell den Ansätzen von Intel / AMD
usw. bei denen die bisherigen Kerne mehr oder weniger
"geklont" in einem Chipgehäuse vereinigt werden
voraus ist:
Wozu 125 Millionen Transistoren für einen Core
verschwenden, wenn es 3 Millionen plus sagen wir 10 für den
schnellen lokalen Speicher auch tun und das ganze einen Bruchteil
an Strom / Chipfläche schluckt. Man muß ja auch heute schon mal
an das "Post-8-fach Core Zeitalter" denken: Es braucht hocheffiziente
einfache Core's; (X86-)Kompatibilität (in Hardware) wird dabei weiter
an Bedeutung verlieren, spätestens, wenn die Virtualisierung
beliebige Architekturen zu emulieren vermag und man davon nicht mal
was merkt. Es war natürlich trotzdem naheliegend, dem Cell einen
"kompatiblen" PPC-Core zu spendieren (Lerneffekt vom Itanium ?), damit
zumindest Linux / Max OS o.ä. erstmal booten.

Ich glaub ich wart doch noch auf den Dual-Cell Mac in 65nm !

@Demirug: Das "Problem" mit der Cell-Speicherarchitektur sehe ich nicht
so kritisch: In parallelen Systemen konkurieren die
Prozesse, ich brauche unbedingt schnelle Kommunikation und -Synchronisierung:
Du weißt das, ich weiß das und IBM weiß das am besten.
Glücklicherweise kann man sich bei Cell aber auf exaktes Timing der
einzelnen SPE's verlassen (feine Sache !)

[Coda]

Warum 125 Mio. verschwenden? Weil paralleles programmieren um einiges schwerer ist und nicht immer geht.

Ich glaub ich wart doch noch auf den Dual-Cell Mac in 65nm !Da wirst du imho lange warten können.
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=225351

[Bokill]

Erst mal THX für die gute Threadidee Gast! :)

Wozu 125 Millionen Transistoren für einen Core verschwenden, wenn es 3 Millionen plus sagen wir 10 für den schnellen lokalen Speicher auch tun und das ganze einen Bruchteil an Strom / Chipfläche schluckt. Ein teilweise guter Grund für den Cell. Mit den SIMD, MMX, 3DNOW!, SSE, AltiVec etct. ist immer mehr Vektorcode im Laufe der Zeit hinzugekommen.
Da ist es naheliegend verstärkt noch mehr Streaming-Eigenschaften zu implemetieren. HDTV und anderen Audio/Video-Geschichten sei Dank.

Man muß ja auch heute schon mal an das "Post-8-fach Core Zeitalter" denken Schon mal was von SUN mit den Projekten Rock und Niagara gehört?
Es hat schon seinen Grund sich über verschiedene Arten vo Multicores Gedanken zu machen. Eine Server-CPU mit tausenden von Anfragen zur gleichen Zeit, mag besonders viele Einzelkerne. Die dürfen sogar recht einfach gestrickt sein.
Aber bei komplexen Berechnungen ist häufig genug doch eine fettere CPU gefragt.

NEC hat fette Vektor-CPUs mit gigantischer Rechenpower, aber die SX-Reihe versagt jämmerlich bei Skalar-Code, da müht sich der MIPS-Kern in den SX-CPUs von NEC zwar redlich, aber doch nur mit überschaubarere Rechenkraft.

Es braucht hocheffiziente einfache Core's; (X86-)Kompatibilität (in Hardware) wird dabei weiter an Bedeutung verlieren X86 ist eine ISA, wie die Hardware dahinter aussieht kann sehr unterscheidlich sein.

Sogar DEC hatte für ihre Alphas schon einen x86-Emulator (FX!32) um die wichtigsten Befehle vergleichsweise zügig auf den Alphas laufen zu lassen. -> "Wölfe im CISC-Kleid" über die Funktionsweise von FX!32 (http://www.planet3dnow.de/vbulletin/showthread.php?p=1753671#post1753671) (deutscher Erklärungsansatz zu dem überragenden zwingend lesenswerten englischen Original: Wolves in CISC Clothing (http://www.realworldtech.com/includes/templates/articles.cfm?ArticleID=RWT122803224105&mode=print) von Paul de Mone).

Der Itanium kann x86 (Hardware, und mit Emulationssoftware), Transmetas Code Software Morphing, und diverse andere Emulatoren für die verschiedensten Architekturen.

spätestens, wenn die Virtualisierung beliebige Architekturen zu emulieren vermag und man davon nicht mal was merkt. Das ist jetzt schon der Fall. Die Dicken Eisen setzen schon länger auf Virtualisierung. Je nach Anwendung frisst Virtualisierung auch gar nicht mehr so viel Rechenleistung.

Es war natürlich trotzdem naheliegend, dem Cell einen "kompatiblen" PPC-Core zu spendieren Die Softwarewelt besteht nicht nur aus Vectorcode -> Vektor-Rechner (http://www.orthy.de/modules.php?name=Encyclopedia&op=content&tid=31)
und vor allem dem Posting/Thread aus dem 3DC-Forum => Re: Multi Core Cpus: die Zukunft (am Beispiel von CELL) #16 (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=2846362#post2846362) von GloomY. :D

Lerneffekt vom Itanium?, damit zumindest Linux / Max OS o.ä. erstmal booten. Der Itanium ist, wie jede andere CPU auch, dumm wie Brot.
Der Lerneffekt ist im Kompiler, und dort ist jede CPU anders gestrickt, um dem Kompiler besonders hilfreich zur Hand zu gehen.
Da ist der Itanium recht gut gemacht worden (der ist aber auch zwingend gut geschriebenen Code angewiesen), aber auch Transmetas CPUs (-> Code Morphing) und ARM CPUs haben Erleichterungen für Kompiler, um besseren Code zu generieren.

MFG Bo(2005)