Peta-FLOPS Rechner von NEC
- Ersteller KairoCowboy
- Erstellt am
KairoCowboy
Vice Admiral Special
Gegen den von <a href="http://www.nec.de/" target="_blank">NEC</a> geplanten Supercomputer wirkt der derzeitige Spitzenreiter "eServer BlueGene" von IBM, welcher immerhin eine Spitzenleistung von knapp 137 Tera-FLOPS erreicht, wie ein Spielzeug. So ist es in der Computerindustrie eben, nicht aufzuhaltender Fortschritt, rasante Entwicklungen, die das als High-End definierte von heute schon morgen alt aussehen lassen.
Genauere Informationen wie etwa Kosten, Anzahl und Lieferant der CPUs konnte NEC noch nicht verraten, bekannt ist aber das NEC bei diesem Supercomputer auf Lichtleitertechnik setzen möchte und Intel bereits erfolgreiche Versuche bei der Kombination von Silizium und Laserstrahlen vorweisen kann.
Welche CPU also verwendet werden wird, bleibt vorerst ein Rätsel, auf jeden Fall aber vom Typus Vektor-CPU, also ein Verbund vieler einzelner Prozessoren, welche dann nach aussen hin wie eine einzelne CPU mit einer großen Anzahl von Fliesskommaeinheiten wirkt.
Der Auftraggeber ist ebenfalls schon bekannt. Japans Regierung möchte diese Rechenpower für die Erforschung und Entwicklung der Industrie einsetzen und investiert auf diese Weise also direkt in den eigenen Fortschritt.
Spannend ist auch eine Ankündigung seitens IBM. Bis zum Jahr 2010 will man ebenfalls einen neuen Supercomputer mit 10^15 Rechenoperationen pro Sekunde auf die Beine stellen, wie IBM die Lösung des Problems angehen wird, wird mit Spannung erwartet.
Genauere Informationen wie etwa Kosten, Anzahl und Lieferant der CPUs konnte NEC noch nicht verraten, bekannt ist aber das NEC bei diesem Supercomputer auf Lichtleitertechnik setzen möchte und Intel bereits erfolgreiche Versuche bei der Kombination von Silizium und Laserstrahlen vorweisen kann.
Welche CPU also verwendet werden wird, bleibt vorerst ein Rätsel, auf jeden Fall aber vom Typus Vektor-CPU, also ein Verbund vieler einzelner Prozessoren, welche dann nach aussen hin wie eine einzelne CPU mit einer großen Anzahl von Fliesskommaeinheiten wirkt.
Der Auftraggeber ist ebenfalls schon bekannt. Japans Regierung möchte diese Rechenpower für die Erforschung und Entwicklung der Industrie einsetzen und investiert auf diese Weise also direkt in den eigenen Fortschritt.
Spannend ist auch eine Ankündigung seitens IBM. Bis zum Jahr 2010 will man ebenfalls einen neuen Supercomputer mit 10^15 Rechenoperationen pro Sekunde auf die Beine stellen, wie IBM die Lösung des Problems angehen wird, wird mit Spannung erwartet.
Das ist ein bisschen unglücklich formuliert. Besser wäre sowas:
auf jeden Fall aber vom Typus Vektor-CPU, also spezielle CPUs, die auf parallele Berechnungen mit sehr vielen Daten spezialisiert sind (ähnlich wie MMX, 3DNow oder SSE, nur viel extremer ausgeprägt).
Sonic
Grand Admiral Special
interessant ist auf jeden fall die optische anbindung. wenn ich das noch richtig im kopf hab, wollen die anscheinend die prozessoren optisch an den speicher koppeln... so wollen die einen x-fach höheren durchsatz schaffen...
ich frag mich, wann die den earth simulator wieder abreißen, weil er zu viel strom verbraucht... oder einfach n neueren rechner in die riesen halle stellen...
ich frag mich, wann die den earth simulator wieder abreißen, weil er zu viel strom verbraucht... oder einfach n neueren rechner in die riesen halle stellen...
Zuletzt bearbeitet:
spaceman2702
Commander
ich hoffe ja nur das die japaner endlich mal nen leistungsfähigen rechner bekommen der ihnen die arbeit abnimmt wale zu töten. wieviel so ein fisch ach nee säuger frisst lässt sich sicher genau so gut simulieren wie auch die zeit die sie noch bis zur ausrottung dieser brauchen.
jedenfalls ists mal wieder spanned zu sehen welche cpu das rennen macht. noch weis keiner nichts genaues.
thx für tip wie man nun die größten säuger wirklich schreibt
jedenfalls ists mal wieder spanned zu sehen welche cpu das rennen macht. noch weis keiner nichts genaues.
thx für tip wie man nun die größten säuger wirklich schreibt
Zuletzt bearbeitet:
Nö - wann der Earth Simulator durch einen Desktop Rechner ersetzt wird 
.
10fach höhere Speichertransferraten wäre natürlich was. VPUs schaffen heute schon locker 40gb/s, macht dann also sowas wie 400gb/s.
. 10fach höhere Speichertransferraten wäre natürlich was. VPUs schaffen heute schon locker 40gb/s, macht dann also sowas wie 400gb/s.
KairoCowboy
Vice Admiral Special
Wenn mich nicht alles täuscht, war doch diese Sache, war diese Lichtstrahl-Anbindung doch letztens schon einmal irgendwo im Gespräch oder?
Interessant auf jeden Fall, Silizium schaltet mitlerweile nicht mehr wirklich schnell, Gallium-Arsenid ist doch auch schon im Gespräch und von kompletten Recheneinheiten aus Lichtleitern kann man wohl nur träumen. aber auch die Anbindung, beispielsweise der Systemgeräte wie Speicher bringt wohl schon einiges an Performancegewinn.
Der Waal, die Waale ...
(und nicht Wahle oder Waals...)
Du hast wohl eben ne Doku nebenbei laufen .... und die scheint dir aufs Gemüt zu hauen.
Also ich glaube jedenfalls, dass das alles etwas themenfremd ist
Interessant auf jeden Fall, Silizium schaltet mitlerweile nicht mehr wirklich schnell, Gallium-Arsenid ist doch auch schon im Gespräch und von kompletten Recheneinheiten aus Lichtleitern kann man wohl nur träumen. aber auch die Anbindung, beispielsweise der Systemgeräte wie Speicher bringt wohl schon einiges an Performancegewinn.
spaceman2702 schrieb:
Der Waal, die Waale ...
(und nicht Wahle oder Waals...)Du hast wohl eben ne Doku nebenbei laufen .... und die scheint dir aufs Gemüt zu hauen.
Also ich glaube jedenfalls, dass das alles etwas themenfremd ist
Sonic
Grand Admiral Special
och, wieso? jetzt kann man statt einem schmetterling, der einen flügelschlag in südafrika macht und so das wetter beeinflusst, ne million schmetterling berechnen... nich besonders sinnvoll, aber wofür soll man die rechneleistung sonst verballern? seti?
KairoCowboy
Vice Admiral Special
Also falls ich gemeint war:
Themenfremd meine ich meinen zitierten Vorredner...
Ob Japan damit Wirtschaft simuliert oder Half Life 2 zockt bleibt den Japanern überlassen. Irgendwer profitiert auf jeden Fall davon, dazu sind die Dinger ja da
Themenfremd meine ich meinen zitierten Vorredner...
Ob Japan damit Wirtschaft simuliert oder Half Life 2 zockt bleibt den Japanern überlassen. Irgendwer profitiert auf jeden Fall davon, dazu sind die Dinger ja da
Jetzt müsste den Text eigentlich nur noch jemand in der News-Meldung ändern .
@Bokill
VPUs kennen keine OoO Execution, RegRenaming oder Branch Prediction wie CPUs, aber mit vetorisiertem Code kann ich nix anfangen.
Ansich muss der Code eben mehr auf die CPU abgestimmt werden, so wie das beim PC auch bis zum 486er der Fall war (ab da kamen dann superskalare Architekturen und um die auszulasten der Optimierungswust OoO, RegRenaming und BrachPrediction). Gleichförmiger Code sagt mir auch nix... was das suggeriert ist ja nicht falsch, aber eben ziemlich schwammig.
Der absolute Hauptpunkt ist parallelisierbarkeit. SSE2 bietet dem Progger ein paar 128Bit Register (8 an der Zahl). Die Register werden nicht mehr wie üblich je mit einem Wert beladen, sondern mit 'packed' Werten - man kann ein 128Bit Reg zB. mit 2 packet 64bit Werten, oder 4 packet 32bit Werten beladen. Sprich da sind dann eben 4 voneinander unabhängige Werte drinnen, und wenn die SSE Einheit die beiden Regs addiert, sind das effektiv 4 Additionen auf einmal, in der Zeit die eine einzelne Addition auch braucht.
Wenig Spaß macht es aber die Register jedesmal neu mit Werten zu füllen, bei einem 128Bit Reg dauert das auch eine Weile, und die Geschwindigkeit bei der Addition lohnt sich eben nicht, wenn man danach gleich wieder das Reg leerräumen muss - muss man mit den Ergebnissen weiterrechnen, lohnt sich die Sache schon viel eher.
Eine VPU läuft nun nicht großartig anders, nur sind die Register eben nicht nur 128bit klein, sondern ein paartausend Bits groß (in der Größenordnung um 4096bit). Muss man so ein Monsterregister neu befüllen, vergeht eine halbe Ewigkeit.
Das A und O für den Einsatz einer VPU ist also eine hohe Parallelisierbarkeit, bei geringen Abhängigkeiten (auf Ebene des Algorithmus: Also der folgende Algorithmus hängt vom Ergebnis der vorherigen Rechnung ab, beispielsweise tue das wenn Ergebnis = 0, was anderes wenn Ergebnis > 0, und nochwas anderes wenn Ergebnis < 0 - das macht die Parallelisierbarkeit nämlich zunichte, wenn die VPU nach 3 Rechnungen mit allen Werten anders weiterrechnen muss).
. @Bokill
VPUs kennen keine OoO Execution, RegRenaming oder Branch Prediction wie CPUs, aber mit vetorisiertem Code kann ich nix anfangen.
Ansich muss der Code eben mehr auf die CPU abgestimmt werden, so wie das beim PC auch bis zum 486er der Fall war (ab da kamen dann superskalare Architekturen und um die auszulasten der Optimierungswust OoO, RegRenaming und BrachPrediction). Gleichförmiger Code sagt mir auch nix... was das suggeriert ist ja nicht falsch, aber eben ziemlich schwammig
. Der absolute Hauptpunkt ist parallelisierbarkeit. SSE2 bietet dem Progger ein paar 128Bit Register (8 an der Zahl). Die Register werden nicht mehr wie üblich je mit einem Wert beladen, sondern mit 'packed' Werten - man kann ein 128Bit Reg zB. mit 2 packet 64bit Werten, oder 4 packet 32bit Werten beladen. Sprich da sind dann eben 4 voneinander unabhängige Werte drinnen, und wenn die SSE Einheit die beiden Regs addiert, sind das effektiv 4 Additionen auf einmal, in der Zeit die eine einzelne Addition auch braucht.
Wenig Spaß macht es aber die Register jedesmal neu mit Werten zu füllen, bei einem 128Bit Reg dauert das auch eine Weile, und die Geschwindigkeit bei der Addition lohnt sich eben nicht, wenn man danach gleich wieder das Reg leerräumen muss - muss man mit den Ergebnissen weiterrechnen, lohnt sich die Sache schon viel eher.
Eine VPU läuft nun nicht großartig anders, nur sind die Register eben nicht nur 128bit klein, sondern ein paartausend Bits groß (in der Größenordnung um 4096bit). Muss man so ein Monsterregister neu befüllen, vergeht eine halbe Ewigkeit.
Das A und O für den Einsatz einer VPU ist also eine hohe Parallelisierbarkeit, bei geringen Abhängigkeiten (auf Ebene des Algorithmus: Also der folgende Algorithmus hängt vom Ergebnis der vorherigen Rechnung ab, beispielsweise tue das wenn Ergebnis = 0, was anderes wenn Ergebnis > 0, und nochwas anderes wenn Ergebnis < 0 - das macht die Parallelisierbarkeit nämlich zunichte, wenn die VPU nach 3 Rechnungen mit allen Werten anders weiterrechnen muss).
KairoCowboy
Vice Admiral Special
In der reinen Lehre hast du Recht. Wenn du aber den NEC SX anschaust, dann hat der OoO, RegRenaming oder Branch Prediction ... das ist aber der MIPS-Anteil.i_hasser schrieb:aus diesem Posting
Jetzt müsste den Text eigentlich nur noch jemand in der News-Meldung ändern
@Bokill
VPUs kennen keine OoO Execution, RegRenaming oder Branch Prediction wie CPUs, aber mit vetorisiertem Code kann ich nix anfangen.
Alles im Fluss,was das suggeriert ist ja nicht falsch, aber eben ziemlich schwammig
Rüchtisch ...
Parallelisierbarkeit der Aufgabe, und die Art und Weise wie der Programmcode im Speicher abgelegt ist lässt Vektorprozessoren zu Witzfiguren, oder zu Monstern erstehen.
MFG Bo(2005)
Bezogen auf die Vektorrechnung haben die NECs auch kein OoO, RegRenaming oder sowas.
Die Worte im dem Orthy Artikel sind nunmal einfach schwammig. Man kann es richtig interpretieren, man könnte aber auch sonstwas hineininterpretieren - und wenn man VPUs eben nicht kennt, interpretiert man eher nicht das richtige hinein.
So ein Beispiel ist mir vor einer Weile wieder über den Weg gelaufen: Variable Schaufelgeometrie beim Turbolader. Die Schaufeln selbst sind aber nach wie vor vollkommen starr, da ändert sich rein garnix. variable Geometrie bezieht sich hier nicht auf die Form der Schaufeln, sondern auf das Strömungsverhalten an den Schaufeln - und genauso kannst du bei deiner Erklärung sonstwas hineininterpretieren. Beispiel:
Könnte man auch was wie Pipelining drunter verstehen.
Gut vorhersehbar jein, dynamische Sprünge die den Algorithmus für alle Daten ändern sind null Problem. Und statische Sprünge machen sowieso keine Probleme - also in 3/4 geht diese Aussage am eigentlichen Thema vorbei.
Und was das nun wieder bedeuten mag... erklär mir mal gleichförmigen Code - ich weis wirklich nix damit anzufangen.
Also den Versuch das Leuten die keine Ahnung von Rechnern haben zu erklären in Ehren, aber das ist zu schwammig. Jeder stellt sich unter den Begriffen was anderes vor.
Die Worte im dem Orthy Artikel sind nunmal einfach schwammig. Man kann es richtig interpretieren, man könnte aber auch sonstwas hineininterpretieren - und wenn man VPUs eben nicht kennt, interpretiert man eher nicht das richtige hinein.
So ein Beispiel ist mir vor einer Weile wieder über den Weg gelaufen: Variable Schaufelgeometrie beim Turbolader. Die Schaufeln selbst sind aber nach wie vor vollkommen starr, da ändert sich rein garnix. variable Geometrie bezieht sich hier nicht auf die Form der Schaufeln, sondern auf das Strömungsverhalten an den Schaufeln - und genauso kannst du bei deiner Erklärung sonstwas hineininterpretieren. Beispiel:
Könnte man auch was wie Pipelining drunter verstehen.
Gut vorhersehbar jein, dynamische Sprünge die den Algorithmus für alle Daten ändern sind null Problem. Und statische Sprünge machen sowieso keine Probleme - also in 3/4 geht diese Aussage am eigentlichen Thema vorbei.
Und was das nun wieder bedeuten mag... erklär mir mal gleichförmigen Code - ich weis wirklich nix damit anzufangen.
Also den Versuch das Leuten die keine Ahnung von Rechnern haben zu erklären in Ehren, aber das ist zu schwammig. Jeder stellt sich unter den Begriffen was anderes vor.
Was den Vektoranteil angeht stimmt deine Aussage.i_hasser schrieb:
Das beschreibt, dass der Code gleichsam wie an einem Stück im Speicher abgelgt ist. Das ist eines der Merkmale wie es ein Vektorprozessor mag. Wildes Adressenhoppeln ist nicht die Sache von Vektorprozessoren.
Das kann man auch von SIMD-Einheiten sagen. Der Pemtium 4 trägt dieser Neugung Rechnung indem die Cachelines besonders lang organisiert sind. Gut für Streaming-Daten, aber bei Skalarcode deutlich ungünstiger.
Und darum der Querverweis dort auf eine Diskussion aus dem Forum von 3DC ... nur so kann man dann deutlich besser den Inhalt verstehen.
MFG Bo(2005)
Das mit den Sprüngen stimmt nicht, hast du Belege dafür? Wildes rumspringen ist überhauptkein Problem, solang es nicht bedeutet, dass die Hälfte der Werte in den Registern anders behandelt werden muss, als die andere Hälfte. Bei einer VPU muss exakt der selbe Algorithmus auf die gleichen Daten angewendet werden, und der Algorithmus darf keine bedingten Verzweigungen etc. enthalten.
Gleichförmigen Code, also Code der am Stück vorliegt (am besten noch ohne Schleifen etc.) findest du heute praktisch nicht.
Gleichförmigen Code, also Code der am Stück vorliegt (am besten noch ohne Schleifen etc.) findest du heute praktisch nicht.
Das dick angestrichene ist ja das wesentliche ...i_hasser schrieb:
Ein anderes (klassisches Kriterium) war aber eben auch die Gleichförmigkeit. Da war ich auf einigen Institutsseiten.
Stand da anderes drin, bzw. in den Verlinkten Artikeln? Ich denke nicht.
Was die Programmierer aber nicht abhält für solche Vektorprozessoren den Code nach dieser Regel zu schreiben. Das macht die Vektorprozessoren ja zu solchen teuren Kollegen. Die wenigen, die dafür programmieren wollen ordentlich was dafür haben. Oder es werden teure Institute gehalten, um solche Rechner dann zu beschäftigen.
Bo(2005)
Du, als Assemblerprogger sag ich dir, dass gleichförmiger Code alles bedeuten kann, und dass man nach deiner Definitiv eine VPU auch sehr sehr gut mit nichtgleichförmigen Code füttern kann.
Und nochmal, ich sagte nicht falsch, sonder schwammig.
Und nochmal, ich sagte nicht falsch, sonder schwammig.
