CELL offiziell vorgestellt: ready for 4 GHz !?
- Ersteller rkinet
- Erstellt am
![mtb][sledgehammer](/data/avatars/m/1/1883.jpg?1596828194){kind=avatar}
mtb][sledgehammer
Grand Admiral Special
Wow. Ich liste mal auf (alles DP):
- Athlon @ 2 GHz: immerhin 4 GFLOPs
- Celeron @ 2,8 GHz: 5,6 GFlops
- Pentium 4 @ 3,8 GHz: 7,6 GFLops
- Power 5 @ 1,9 GHz: 7,6 GFLOPS
- Itanium @ 1,5 GHz: 6 GFLOps
Nun stellt sich natürlich die Frage, warum man die teuren Vektorprozessoren in den Earth Simulator gesteckt hat, obwohl je 2 der oben aufgeführten Prozessoren einen von ihnen theoretisch ersetzen könnte.
Die nächste Frage ist, ob die Antwort auf die erste Frage auch eine Antwort auf die Frage gibt, ob für Cell eine ähnliche Problematik gilt.
wird aus dem Thread doch noch was? 
Ich denke es wird langsam sichtbar, dass reine GFlops-Angaben gar nichts aussagen. Und der NEC SX 5/6/8 zeichnet eines aus, ihre unglaublich breite Speicheranbindung, und ihre unglaublich breite Registeranordnung.
Entscheidend für hohe Performance ist, dass auch die Software dazu breitsteht, inklusive verschiedenster Biblitheken, Compiler.
Da IBM aber grosse Erfahrung in Gridcomputing, sowie auch bei Multicorearchitekturen besitzt (Stichwort MCM bei der Powerfamilie), ist die Erfahrungsbasis für Cell bei IBM recht breit.
Für mich stellt sich die Frage, ob a) IBM so eine vollständig neue Geräteklasse schafft in ihrem Server/Workstationzoo, oder b) gar langfristig ihre bisherige Powerfamilie abschaffen wollen (was ich aber nicht glaube).
Der Cell setzt ja definitiv auf 2 Fremdfirmeninterfaces. Bei dem Speicher wird XDR von Rambus eingesetzt, bei dem Systembus ausserhalb vom Cell ist auch eine Lösung von Rambus drin.
Ich denke das spricht da eher für eine eigenständige Serverlinie, die parallel zum bisherigen Power leben kann. Man kann ja mal schauen worin der NEC SX gut ist ... genau dort könnte der Cell angreifen ... mit Cell-Vorteilen bei klassischen CPU Architekturen, und mit einem leichten Cell-Nachteil bei typischen Vectorprozessoraufgaben der NEC SX Reihe.
MFG Bokill
Ich denke es wird langsam sichtbar, dass reine GFlops-Angaben gar nichts aussagen. Und der NEC SX 5/6/8 zeichnet eines aus, ihre unglaublich breite Speicheranbindung, und ihre unglaublich breite Registeranordnung.
Entscheidend für hohe Performance ist, dass auch die Software dazu breitsteht, inklusive verschiedenster Biblitheken, Compiler.
Da IBM aber grosse Erfahrung in Gridcomputing, sowie auch bei Multicorearchitekturen besitzt (Stichwort MCM bei der Powerfamilie), ist die Erfahrungsbasis für Cell bei IBM recht breit.
Für mich stellt sich die Frage, ob a) IBM so eine vollständig neue Geräteklasse schafft in ihrem Server/Workstationzoo, oder b) gar langfristig ihre bisherige Powerfamilie abschaffen wollen (was ich aber nicht glaube).
Der Cell setzt ja definitiv auf 2 Fremdfirmeninterfaces. Bei dem Speicher wird XDR von Rambus eingesetzt, bei dem Systembus ausserhalb vom Cell ist auch eine Lösung von Rambus drin.
Ich denke das spricht da eher für eine eigenständige Serverlinie, die parallel zum bisherigen Power leben kann. Man kann ja mal schauen worin der NEC SX gut ist ... genau dort könnte der Cell angreifen ... mit Cell-Vorteilen bei klassischen CPU Architekturen, und mit einem leichten Cell-Nachteil bei typischen Vectorprozessoraufgaben der NEC SX Reihe.
MFG Bokill
@mocad_tom
Die Angaben oben sind alle für DP
.
Tatsache ist, dass die praktische Leistung bei x86 recht unabhängig von 32bit oder 64bit Float ist. Die Whetstone Benchmarks zeigen da praktisch keinen Unterschied.
@Bokill
Das wichtigste fehlt noch: Die Architektur muss für das jeweilige Problem geeignet sein, und genau da liegt der Hase im Pfeffer. Ein SX8 kann einen noch so hohe Rechenleistung haben, für komplexe Sachen (verzweigter Algorithmus etc.) ist der nicht gebaut und nicht geeignet. Genauso Cell.
Die Angaben oben sind alle für DP
. Tatsache ist, dass die praktische Leistung bei x86 recht unabhängig von 32bit oder 64bit Float ist. Die Whetstone Benchmarks zeigen da praktisch keinen Unterschied.
@Bokill
Das wichtigste fehlt noch: Die Architektur muss für das jeweilige Problem geeignet sein, und genau da liegt der Hase im Pfeffer. Ein SX8 kann einen noch so hohe Rechenleistung haben, für komplexe Sachen (verzweigter Algorithmus etc.) ist der nicht gebaut und nicht geeignet. Genauso Cell.
maxxx
Cadet
Hi Leuts!
Hab mich jetzt durch den teils sehr "mühsamen"
Text durchgebissen, und will nun auch etwas dazu schreiben.
Ein Freund von mir arbeitet in der Hardware Entwicklung (in Österreich) bei einer nicht so kleinen Firma
Nun, er hat mir was von einer PCI-E 16x karte, mit 2 Cell´s drauf erzählt (läuft aber noch nicht). Mit der (laut Ihm) alles Mögliche gemacht werden soll (OS Emulation, Grafikberechnungen usw.)
Vielleicht ist da was dran, wir werden ja sehen!
Lg Maxxx
Hab mich jetzt durch den teils sehr "mühsamen"
Text durchgebissen, und will nun auch etwas dazu schreiben.Ein Freund von mir arbeitet in der Hardware Entwicklung (in Österreich) bei einer nicht so kleinen Firma
Nun, er hat mir was von einer PCI-E 16x karte, mit 2 Cell´s drauf erzählt (läuft aber noch nicht). Mit der (laut Ihm) alles Mögliche gemacht werden soll (OS Emulation, Grafikberechnungen usw.)
Vielleicht ist da was dran, wir werden ja sehen!
Lg Maxxx
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
@RLZ
Ob und wann neben dem primären EyeRay weitere Strahlen erzeugt werden ist eine Implementationsfrage. Ein iterativer Algorithmus kann das jedenfals genauso leisten, denn die Ergebnisfarbe eines Samples/Pixels kann einfach additiv (=> Kommutativ Gesetz) bestimmt werden -- die Abfolge der Berechnung der Farbanteile einzelner Strahlen ist damit veränderbar. Interessant ist auch ob es nicht sogar sinnvoll sein kann die Rekursionstiefe zu beschränken: Wenn ja kommst du iterativ zum identischen Ergebnis.
Raytracing definiert keinen bestimmten Algorithmus, sondern nur eine Klasse von Algorithmen die die gleiche Idee (Strahlenrückverfolgung) benutzen um zu einem Abbild zu kommen.
Ob und wann neben dem primären EyeRay weitere Strahlen erzeugt werden ist eine Implementationsfrage. Ein iterativer Algorithmus kann das jedenfals genauso leisten, denn die Ergebnisfarbe eines Samples/Pixels kann einfach additiv (=> Kommutativ Gesetz) bestimmt werden -- die Abfolge der Berechnung der Farbanteile einzelner Strahlen ist damit veränderbar. Interessant ist auch ob es nicht sogar sinnvoll sein kann die Rekursionstiefe zu beschränken: Wenn ja kommst du iterativ zum identischen Ergebnis.
Nicht zwingend! M.W. verwendet Povray sogar BSP-Trees mit iterativem Traversal. Bei kD-Trees (eine Spezialform der BSP-Trees) kannst du iterativ den Baum z.B. mittels Corner-Stitching oder mit dem Kaplan-Algorithmus durchlaufen.
rkinet
Grand Admiral Special
nun klingt doch sehr positiv.Original geschrieben von maxxx
Ein Freund von mir arbeitet in der Hardware Entwicklung (in Österreich) bei einer nicht so kleinen Firma
Nun, er hat mir was von einer PCI-E 16x karte, mit 2 Cell´s drauf erzählt (läuft aber noch nicht). Mit der (laut Ihm) alles Mögliche gemacht werden soll (OS Emulation, Grafikberechnungen usw.)
Auch ist zu erwarten, daß IBM-Sony-Toshiba parallel zur Cell-Hardwareentwicklung sicherlich bereits Tolls für alle denkbaren Applikationen entwickelt haben und per Simulation auf Mainframes (IBM baut sowas, echt! ... so hat schon Billy MS sien erstes BASIC entwicket) den Cell und seine Tolls getestet haben.
Aber unser etablierter CPU-Hersteller ist ja auch nicht untätig:
'Toledo' für 'Home Entertainment' - http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=206962
2005/6 wird noch spannend werden - erinnert schon etwas an die 'Boomzeit' Ende der 70er und anfang der 80er Jahre.
PuckPoltergeist
Grand Admiral Special
Man man man, ist das ein Stuss. Viele einzelne Aussagen, die für sich genommen korrekt sind, ergeben zusammen geworfen trotzdem nicht unbedingt was sinnvolles. So wie das da oben geschrieben steht, ist das definitiv falsch.
Shdow
Vice Admiral Special
*no comment*
rkinet
Grand Admiral Special
http://arstechnica.com/articles/paedia/cpu/cell-1.ars/2
Man beachte dabei (in der Vergrößerung):
Instruction Fetch
Decode
Dispatch
natürlich eine 'schwache CPU', aber eben einen sehr starken 'Execution Core'
so im Text:
'' In this respect, the individual SPUs are like very simple, PowerPC 601 -era processors. ...
The individual SPUs can throw a lot overboard, because they rely on a regular, general-purpose POWERPC processor core to do all the normal kinds of computation that it takes to run regular code. ''
Je SPU eine 'alte 32 Bit' PowerPC Gurke ...
sage keiner, 32 Bit sein zu nichts mehr zu gebrauchen ...
''The Cell system features eight of these SPUs all hanging off a central bus, with one 64-bit POWERPC core handling all of the regular computational chores. ''
ALSO,
8* 32 Bit PowerPC-Core in den SPUs und
1* 64 Bit PowerPC-Core für sonstige Aufgaben.
Diese dezentrale Verteilung von Rechenaufgaben zeigt nachfolgendes Schema nur indirekt bei Betrachtung der Bandbreiten - die 64 Bit CPU hat ja nur einen Bruchteil der SPU Gesamtbandbreite zur Kommunikation zur Verfügung
(2* 16 zu 2* 128 Byte / Takt -- bei 4 GHz also 2* 64 GByte/s zu 2* 1 TByte/s)
in der Übersicht: http://www.heise.de/ct/05/05/018/bild.gif
Bem: sind schon atemberaubende Daten, oder ?
Also was du hier abziehst ist der pure Hohn! Das könnte man schon fast als persönliche Beleidigung auffassen.
Ich stell mir gerade vor wie ich durch eine Straße laufe und auf einmal von einem türkisch-deutsch sprechenden (egal welcher Nationalität) angehalten werde, der mir Deutsch beibringen will.
Nein, ist noch zu harmlos.
Also was du da zum Argumentieren benutzt, ist wirklich das Hinterletzte. Selbst dem 486er kann ich guten Gewissens ähnliche Pipelineschritte zuschreiben, trotzdem hat das nix mit RISC und nix mit Leistungsfähigkeit zu tun!
Die Anzahl der Pipelinestufen sagt noch überhauptgarnix, nicht das allergeringste oder allerwenigste über die Leistung von einem Prozessor aus!!! Da einen Zusammenhang sehen zu wollen grenzt an Blödheit!
Du hast es echt geschafft - deine Argumentation ist so *zensiert*, dass es nun tatsächlich wehtut!
Auch die Sache mit dem Execution Core - der ist nicht stark, so eine Behauptung ist fernab jeder Logik! Die Recheneinheit ist vielleicht stark, bei Branches etc. ist der Execution Core aber schnarchlahm!
Allein schon die Idee die Geschwindigkeit davon an der theoretischen Rechenleistung festzumachen...
Ich könnte dir jetzt hunderte Geschichen auftischen die belegen, dass das nix miteinander zu tun hat (weder Rechenleistung <-> allgemeine Geschwindigkeit, noch Pipelinelänge <-> Geschwindigkeit).
Aber es würde dich ja sowieso nicht interessieren, du hast dir deine Meinung sowieso schon gebildet (wovon eigentlich? Ich hab bisher weder eine technische Quelle, noch sonstirgendwas vergleichbares gesehen!). rkinet, das Wunder das auf die Welt kam und schon alles wusste?
Wenns wenistens nur das wäre. Aber dann ziehst du hier Parallelen, ich könnte mich jetzt noch 2 Seiten darüber aufregen.
Schon allein die Idee, dass RISC=schnell ist... für mich zeugt das ehrlich von Ahnungslosigkeit. Und zwar in dem Sinne, dass jemand der keine Ahnung hat und dauernd hört wie toll doch die Server CPUs sind (bzw. einige), und dass diese alle RISC sind, ja doch irgendwann zu dem Schluss kommt, dass RISC allgemein schnell ist.
Um mal eine greifbare Analogie zu bringen: Du hörst den ganzen Tag wie toll ja die heutigen Motoren mit Turbo sind - ganz klar, ein Turbo Motor bringt bei ähnlichen Eckdaten deutlich mehr Leistung als ein Sauger mit Einspritzung, oder gar ein Vergasermotor.
Aber gehst du desswegen in einen Rasenmäherladen und verlangst einen Benzinrasenmäher mit Turbo oder wenigstens Einspritzung? NEIN! Das wäre ja totaler Quatsch!
Ganz genauso sieht deine Argumentation aus. Exakt so.
Und dann würfelst du auch noch dauernd. Die SSE Einheiten vom zB. K8 sind absolut - also wirklich absolut - unvergleichbar mit einer SPU. Äpfel und Brinen haben viel mehr Gemeinsamkeiten, man könnte sagen du vergleichst Gluonen mit Sommerreifen.
Ich stell mir gerade vor wie ich durch eine Straße laufe und auf einmal von einem türkisch-deutsch sprechenden (egal welcher Nationalität) angehalten werde, der mir Deutsch beibringen will.
Nein, ist noch zu harmlos.
Also was du da zum Argumentieren benutzt, ist wirklich das Hinterletzte. Selbst dem 486er kann ich guten Gewissens ähnliche Pipelineschritte zuschreiben, trotzdem hat das nix mit RISC und nix mit Leistungsfähigkeit zu tun!
Die Anzahl der Pipelinestufen sagt noch überhauptgarnix, nicht das allergeringste oder allerwenigste über die Leistung von einem Prozessor aus!!! Da einen Zusammenhang sehen zu wollen grenzt an Blödheit!
Du hast es echt geschafft - deine Argumentation ist so *zensiert*, dass es nun tatsächlich wehtut!
Auch die Sache mit dem Execution Core - der ist nicht stark, so eine Behauptung ist fernab jeder Logik! Die Recheneinheit ist vielleicht stark, bei Branches etc. ist der Execution Core aber schnarchlahm!
Allein schon die Idee die Geschwindigkeit davon an der theoretischen Rechenleistung festzumachen...
Ich könnte dir jetzt hunderte Geschichen auftischen die belegen, dass das nix miteinander zu tun hat (weder Rechenleistung <-> allgemeine Geschwindigkeit, noch Pipelinelänge <-> Geschwindigkeit).
Aber es würde dich ja sowieso nicht interessieren, du hast dir deine Meinung sowieso schon gebildet (wovon eigentlich? Ich hab bisher weder eine technische Quelle, noch sonstirgendwas vergleichbares gesehen!). rkinet, das Wunder das auf die Welt kam und schon alles wusste?
Wenns wenistens nur das wäre. Aber dann ziehst du hier Parallelen, ich könnte mich jetzt noch 2 Seiten darüber aufregen.
Schon allein die Idee, dass RISC=schnell ist... für mich zeugt das ehrlich von Ahnungslosigkeit. Und zwar in dem Sinne, dass jemand der keine Ahnung hat und dauernd hört wie toll doch die Server CPUs sind (bzw. einige), und dass diese alle RISC sind, ja doch irgendwann zu dem Schluss kommt, dass RISC allgemein schnell ist.
Um mal eine greifbare Analogie zu bringen: Du hörst den ganzen Tag wie toll ja die heutigen Motoren mit Turbo sind - ganz klar, ein Turbo Motor bringt bei ähnlichen Eckdaten deutlich mehr Leistung als ein Sauger mit Einspritzung, oder gar ein Vergasermotor.
Aber gehst du desswegen in einen Rasenmäherladen und verlangst einen Benzinrasenmäher mit Turbo oder wenigstens Einspritzung? NEIN! Das wäre ja totaler Quatsch!
Ganz genauso sieht deine Argumentation aus. Exakt so.
Und dann würfelst du auch noch dauernd. Die SSE Einheiten vom zB. K8 sind absolut - also wirklich absolut - unvergleichbar mit einer SPU. Äpfel und Brinen haben viel mehr Gemeinsamkeiten, man könnte sagen du vergleichst Gluonen mit Sommerreifen.
Shdow
Vice Admiral Special
@i_hasser
du sprichst mir aus der seele
sse hat mit einer spe soviel zu tun wie ein auto mit einer tiefgarage.
ich selber sehe mich hier als alles andere als "DIE" Leuchte , aber gegen solche aussagen wie von rkinet bin ich ja Gott
du sprichst mir aus der seele
sse hat mit einer spe soviel zu tun wie ein auto mit einer tiefgarage.
ich selber sehe mich hier als alles andere als "DIE" Leuchte , aber gegen solche aussagen wie von rkinet bin ich ja Gott
rkinet
Grand Admiral Special
Für solch einfache Designs sind sicherlich einige Takte für einen Branch nötig.
Aber auch nicht ewig, denn selbst simple Rechenknechte der Frühzeit packten in 4-8 Takten einen Branch. Bei 4 GHz also 0,5 - 1 Milliarde / Sekunde.
Zudem ist die SPU keine SSE, die eine permanete Datenzufuhr benötigt.
Sind wiederkehrende Operationen mit dem gleiche Algorithnmus durchzuführen,
holen sich die Execution Logic Teilbereiche eigenständig neue Daten aus dem lokalen Cache.
@i-Hasser,
man sollte IBM und Sony etwas geistige Fähigkeiten zubilligen.
Und nicht die Effektivität solcher Designs bei überschaubaren Aufgaben unterschätzen.
Ein 'richtige' CPU entfaltet sich erst bei komplexen Code.
Nach wie vor, ich bin der Überzeugung, daß die $2 Milliarden nicht fehlinvestiert wurden und der CELL nicht von Idioten designed wurde.
Bem:
Ich beschäftige mich mit einem RISC Mikrokontroller und programmiere in Assembler. Manches im CELL kommt mir bekannt vor und ich kenne ja etwa Vergleichstaktbedarf für gewisse Funktionalitäten.
Der CELL ist und bleibt Technik für übermorgen die morgen schon verkauft wird.
Zuletzt bearbeitet:
Shdow
Vice Admiral Special
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
also das es solch negative grenzen geistiger armut gibt hätte ich nicht gedacht rkinet hätte ja wenigstens mal nachschlagen können was die beiden sachen sind die sein gesicht grad in einen riesengroßen warmen kuhfladen drücken. wäre toll wenn du uns mal sagst was SSE ist bevor du das irgendwie mit etwas anderem vergleichst.
Zuletzt bearbeitet:
maxxx
Cadet
Ahm
Oh nein ich hatte 12Jahre lang ein völlig falsches bild von CPU´s
Maxxx
PuckPoltergeist
Grand Admiral Special
Original geschrieben von maxxx
Ahm
Oh nein ich hatte 12Jahre lang ein völlig falsches bild von CPU´s
Maxxx
Mach dir nix draus, du bist nicht der einzige. Alleine hier im Forum dürften das schon so viele sein, die das betrifft, dass wir hier locker eine Selbsthilfegruppe aufmachen können.
.
SnakePlisken
Vice Admiral Special
- Mitglied seit
- 30.01.2004
- Beiträge
- 928
- Renomée
- 16
Haha ,Shdow Du bist doch ne Frucht.
i-hasser, Du aber auch
i-hasser, Du aber auch
rkinet
Grand Admiral Special
http://www.fh-wedel.de/cis/archiv/seminare/ws00/ue/power/powerpc.html#FloatingPoint_Unit
Lesestoff gegen die geistige Armut ...
Die SPUs sind ein Ersatz für die 'AltiVec Units' im PowerPC Design.
Dazu auch begrenzt kompatibel, aber eben 8-fach vorhanden.
Zusätzlich noch eine 'Floating-Point Unit'.
Die SSEx ist eine moderne Floating-Point Unit, mehr aber auch nicht.
hier in der Übersicht der Techniken (noch ohne SPUs des CELL)
http://www.ra.informatik.uni-stuttgart.de/~bergmats/cpuseminar/cpuseminar_05p.pdf
schon die alten 'AltiVec Units' hatten mehr wie SSEx,
erst recht die CELL -SPUs.
Lesestoff gegen die geistige Armut ...
Die SPUs sind ein Ersatz für die 'AltiVec Units' im PowerPC Design.
Dazu auch begrenzt kompatibel, aber eben 8-fach vorhanden.
Zusätzlich noch eine 'Floating-Point Unit'.
Die SSEx ist eine moderne Floating-Point Unit, mehr aber auch nicht.
hier in der Übersicht der Techniken (noch ohne SPUs des CELL)
http://www.ra.informatik.uni-stuttgart.de/~bergmats/cpuseminar/cpuseminar_05p.pdf
schon die alten 'AltiVec Units' hatten mehr wie SSEx,
erst recht die CELL -SPUs.
Aufpassen, gleich liegst du drinnen! Mit deinem letzten Beitrag hast du dich auf 3cm angenährt 
.
In gewisser Weise und unter einer Schrankwand voll Einschränkungen hast du recht. Dumm nur, dass du die SPUs bei weitem nicht so ansteuern kannst wie AltiVec Einheiten oder eben auch SSE Einheiten.
Die Quelle die du gepostest hast ist zwar technisch noch nicht so tiefgreifend, lässt mich (zur Abwechslung) aber doch irgendwie vermuten, dass du versuchst dich über das Thema zu informieren.
Der Unterschied zwischen den SPUs und diversen SIMD Umsetzungen wie SSE und AltiVec ist, dass letztere nur Teil einer CPU sind, wogegen die SPUs praktisch ausschließlich aus SIMDs bestehen.
Oder einfach: Wenn die CPU mal kurz 20 Rechnungen machen muss (weil es sich durch irgendwelche Vorbedingungen so ergeben hat), werden die auf kürzestem Wege zu den direkt angeschlossenen SIMD Einheiten geschickt. Die rattern ein bisschen und sind nach ein paar Takten fertig. Die Ergebnisse wandern auf dem kürzesten Weg zurück zu - ja wo auch immer die eben gebraucht werden und wie das Speichermanagement umgesetzt ist.
Beim Cell dagegen stellt der langsam vor sich hin trabende Kern fest, dass jetzt mal 20 Rechnungen angesagt sind. Als Folge davon lädt er in eine der SPUs ein neues Apulet bzw. Programm, das diese Rechungen ausführen soll. Zeitbedarf: ungefähr der 10fache wie der der eigentlichen Rechnung.
Dann fängt die SIMD an zu rechnen und ist vielleicht in 1/4 bis 1/2 der Zeit einer SSE Einheit fertig.
Jetzt werden die Ergebnisse langwierig wieder zum Core transferriert, damit der mit der Auswertung beginnen kann. Das passiert aber sowieso erst, nachdem ein Zyklus der SPUs durchgelaufen ist. Zeitbefarf ~20mal so viel wie für die eigentlichen Rechnungen.
Du hast bisher damit argumentiert, dass die SIMD für die eigentliche Rechnung ja nur 1/4 der Zeit braucht. Die Riesenbremsen davor und danach hast du dabei aber einfach weggelassen, und desswegen ist die Sache auch nicht für Desktops geeignet.
Bei wissenschaftlichen Anwendungen kann man (bei den richtigen Gebieten) locker die nächsten 100'000 Rechnungen vorhersagen. Die 20 Rechnungen die ich als Beispiel genommen hab sind schon sehr optimistisch, und eigentlich nur bei Spielen oder Multimediasachen (Audio/Video) erreichbar. Mehr geht aber auch da prakisch nicht.
Der Cell schafft zwar die eigentlichen Rechnungen in einem Bruchteil der Zeit, aber die dauernden Transfers von Daten und Programmen dauern viel viel länger als die eigentlichen Berechnungen auf einer anderen CPU. Das liegt nunmal einfach daran, dass die Datenwege von Cell nicht auf 'Latenz' ausgelegt sind. Bis die Daten bei einem K8 von den SSE Einheiten in den Teil für die Speicherzugriffe oder die fürs Branching gelangen dauert es vielleicht 3 Takte (Größenordnung dürfte stimmen).
Bei Cell gehen dafür dann mehrere hundert Takte drauf. Dann gehen mehrere tausend Takte drauf bis der Zyklus der SPUs beendet ist, und dann nochmal ein paarhundert bis die Daten wieder beim Core angekommen sind.
.In gewisser Weise und unter einer Schrankwand voll Einschränkungen hast du recht. Dumm nur, dass du die SPUs bei weitem nicht so ansteuern kannst wie AltiVec Einheiten oder eben auch SSE Einheiten.
Die Quelle die du gepostest hast ist zwar technisch noch nicht so tiefgreifend, lässt mich (zur Abwechslung) aber doch irgendwie vermuten, dass du versuchst dich über das Thema zu informieren.
Der Unterschied zwischen den SPUs und diversen SIMD Umsetzungen wie SSE und AltiVec ist, dass letztere nur Teil einer CPU sind, wogegen die SPUs praktisch ausschließlich aus SIMDs bestehen.
Oder einfach: Wenn die CPU mal kurz 20 Rechnungen machen muss (weil es sich durch irgendwelche Vorbedingungen so ergeben hat), werden die auf kürzestem Wege zu den direkt angeschlossenen SIMD Einheiten geschickt. Die rattern ein bisschen und sind nach ein paar Takten fertig. Die Ergebnisse wandern auf dem kürzesten Weg zurück zu - ja wo auch immer die eben gebraucht werden und wie das Speichermanagement umgesetzt ist.
Beim Cell dagegen stellt der langsam vor sich hin trabende Kern fest, dass jetzt mal 20 Rechnungen angesagt sind. Als Folge davon lädt er in eine der SPUs ein neues Apulet bzw. Programm, das diese Rechungen ausführen soll. Zeitbedarf: ungefähr der 10fache wie der der eigentlichen Rechnung.
Dann fängt die SIMD an zu rechnen und ist vielleicht in 1/4 bis 1/2 der Zeit einer SSE Einheit fertig.
Jetzt werden die Ergebnisse langwierig wieder zum Core transferriert, damit der mit der Auswertung beginnen kann. Das passiert aber sowieso erst, nachdem ein Zyklus der SPUs durchgelaufen ist. Zeitbefarf ~20mal so viel wie für die eigentlichen Rechnungen.
Du hast bisher damit argumentiert, dass die SIMD für die eigentliche Rechnung ja nur 1/4 der Zeit braucht. Die Riesenbremsen davor und danach hast du dabei aber einfach weggelassen, und desswegen ist die Sache auch nicht für Desktops geeignet.
Bei wissenschaftlichen Anwendungen kann man (bei den richtigen Gebieten) locker die nächsten 100'000 Rechnungen vorhersagen. Die 20 Rechnungen die ich als Beispiel genommen hab sind schon sehr optimistisch, und eigentlich nur bei Spielen oder Multimediasachen (Audio/Video) erreichbar. Mehr geht aber auch da prakisch nicht.
Der Cell schafft zwar die eigentlichen Rechnungen in einem Bruchteil der Zeit, aber die dauernden Transfers von Daten und Programmen dauern viel viel länger als die eigentlichen Berechnungen auf einer anderen CPU. Das liegt nunmal einfach daran, dass die Datenwege von Cell nicht auf 'Latenz' ausgelegt sind. Bis die Daten bei einem K8 von den SSE Einheiten in den Teil für die Speicherzugriffe oder die fürs Branching gelangen dauert es vielleicht 3 Takte (Größenordnung dürfte stimmen).
Bei Cell gehen dafür dann mehrere hundert Takte drauf. Dann gehen mehrere tausend Takte drauf bis der Zyklus der SPUs beendet ist, und dann nochmal ein paarhundert bis die Daten wieder beim Core angekommen sind.
maxxx
Cadet
Hi i_hasser!
Naja, so langsam is der Kern dann auch wieder nicht! Er hat zum Beispiel einige neue units erhalten, die eigens für die Aufteilung auf die 8 SPU´s da sind.
Die Bandbreite zwischen "Kern" und SPU´s wurde nicht gerade gering gewählt.
Aber dein Einwand ist natürlich richtig, naja warten wirs mal alles ab!
is ja nimmer lange!
Lg Maxxx
mtb][sledgehammer
Grand Admiral Special
Wen du den Artikel gelesen hättest (oder irgend etwas anderes sinnvolles), dann wüsstest du, dass SSE eben nicht nur eine moderne FPU ist, sondern Sowohl int als auch fp SIMD Unit. Int Operationen sind auf 8, 16, 32 oder 64 Bit Varbiablen möglich, FP eben auf single und double precision Variablen.
BTW: unglaublich das ich an dieser Uni studiere (zum Glück nicht Info), denn die Seite 32 ist echt der Abschuss:
PHP:
Vergleich der Technologien
Verkauf Prozessor Transistoren
VIS 1995 UltraSprac +3%=5.8 Mio
Intel MMX 1996 Pentium MMX +36%=4.5 Mio
Intel SSE 1999 Pentium 3 8.2 Mio/28 Mio1
Intel SSE2 2000 Pentium 4 Northwood 55 Mio
Intel SSE3 2004 Pentium 4 Prescott 125 Mio
Altivec 1999 G4 10.5 Mio
3DNow 1998 K6-2 +5%=9.3 Mio
1Die Anzahl der Transistoren wurde für den Pentium 3 erhöht, um eine
3fache Taktfrequenz zu erreichenAber der Abschuss ist die Anmerkung unter 1: a) der PIII Katmai hatte 9,503,153 Transistoren (laut Sandpile), b) der Coppermine erreichte mit 1 GHz Takt gerade einmal 66% mehr Takt als der schnellste Katmai mit 600 MHz und c) wurde die Anzahl der Transistoren damals erhöht, weil man mal kurz den L2 Cache auf den Die gepackt hat. "kopfschüttel"
Ich glaub da muss ich mal vorbei
rkinet
Grand Admiral Special
Die SPUs sind Erweiterungen zum 'AltiVec' Design, nicht Reduzierungen.
Nachdem Du - eigentlich kaum zu übersehen - die 256K Cache je SPU schon übersehen hast, kann man den Rest des Satement gleich in die Tonne kloppen.
http://arstechnica.com/articles/paedia/cpu/cell-1.ars/2
Ebenso empfehle ich eine gute Lesebrille, denn
The second difference, and this is perhaps the most important, is that the L1 cache has been replaced by 256K of locally addressable memory.
The SPE's ISA, which is not VMX/Altivec-derivative (more on this below), includes instructions for using the DMA controller to move data between main memory and local storage. The end result is that each SPE is like a very small vector computer, with its own "CPU" and RAM.
IBM & Sony haben die $2 Milliarden Entwicklungskosten verwendet, daß genau die von i_hasser beschriebenen Probleme nicht auftreten.
Daß die SSEx 'SIMD' beherrscht macht sie noch lange nicht zu einer sich selbst steuernden Einheit. Und genau deshalb belastet die 8 SPUs den PowerP-Core nicht übermäßig, der so für andere Aufgaben zur Verfügung steht.
Die SPUs sind nur dann ein 'Klotz am Bein', wenn simple Rechenaufgaben zu erledigen sind. Nur, dann ist es wie heute auch, daß die Performance eine FPU, SSE oder eben SPU immer weitaus besser ist, als EXCEL & Co. je benötigen werden. EXCEL lastet selbst unter Vollast eine FPU nur im einstelligen Prozentbereich aus und dies galt schon bei 500 MHz PCs.
Das hab ich nicht übersehen, sondern es spielt dabei schlicht keine Rolle. Der Cache hat keinen Einfluss darauf wie schnell oder langsam die Rechnungen ablaufen, bei 20 Rechnungen bleiben die Ergebnisse sowieso in den Registern.
Was du vielleicht noch wissen solltest: Die AltiVec Einheiten beschränken sich auf SIMD. Ich weis nicht wo ich geschrieben hab die SPUs wären Einschränkungen davon, im Gegenteil - da kommt das SIMD noch viel brachialer zum Vorschein, nur lässt sich das im Desktop Bereich seltenst effizient einsetzen.
Was du vielleicht noch wissen solltest: Die AltiVec Einheiten beschränken sich auf SIMD. Ich weis nicht wo ich geschrieben hab die SPUs wären Einschränkungen davon, im Gegenteil - da kommt das SIMD noch viel brachialer zum Vorschein, nur lässt sich das im Desktop Bereich seltenst effizient einsetzen.
Exlua
Grand Admiral Special
Wie die kleinen Kinder 
Wir wissendoch alle das ein PSX 3 nie mit ein PC mit halten kann .
Wir wissendoch alle das ein PSX 3 nie mit ein PC mit halten kann .
Ähnliche Themen
