Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsRIKEN Fugaku: ARM-Supercomputer erreicht bis zu 537 PetaFLOPS
Fujitsu und das naturwissenschaftliche Forschungsinstitut Rikagaku Kenkyūjo (RIKEN) haben die Spezifikationen des japanischen Supercomputers Fugaku veröffentlicht. Mit 158.976 Compute-Nodes, basierend auf je 48 Fujitsu A64FX-Kernen vom Typ ARM, erreicht der auf HPC und KI optimierte Supercomputer bis zu 537 PetaFLOPS.
sehr beeindruckend so ein system. solange damit sinnvolle sachen errechnet werden und nicht für waffentests genutzt wird...
wie aktuell ist eigentlich die liste der supercomputer? auf den ersten 10 plätzen finden man ausser intel noch IBM und noch einen hersteller aber AMD ist mal nicht vorhanden.
Wie kann man das verstehen? Als Cache? Ram ja sicherlich nicht? Wo befindet sich der Speicher in der CPU oder auf dem Mainboard? Welche positiven Auswirkungen hätte vergleichbares im Desktop Segment?
Wird er in die Listen der Top500 aufgenommen, wenn sie im Juni aktualisiert wird? Oder erst, wenn er vollständig steht?
Wenn er seine reale (Rmax) und theoretische Spitzenleistung (Rpeak) im als Branchenstandard geltenden Benchmark auf Basis von LINPACK nachgewiesen hat.
Wie kann man das verstehen? Als Cache? Ram ja sicherlich nicht? Wo befindet sich der Speicher in der CPU oder auf dem Mainboard? Welche positiven Auswirkungen hätte vergleichbares im Desktop Segment?
Als RAM. Zusätzlicher DDR4 (o.ä.) Speicher ist nicht vorhanden.
Wie bei HBM üblich mit auf dem Package.
Auswirkungen? Sehr hohe Bandbreite des Hauptspeichers, allerdings dadurch auch stark beschränkt in der Kapazität.
Wie kann man das verstehen? Als Cache? Ram ja sicherlich nicht? Wo befindet sich der Speicher in der CPU oder auf dem Mainboard? Welche positiven Auswirkungen hätte vergleichbares im Desktop Segment?
Zusätzlich, zu dem was bereits Peter gesagt hat, sind auch die Latenzen anders. Sie sollen höher sein als DDR4. RAM nach stecken geht damit auch nicht.
Interessant wird der reale Linpack Wert. Bin gespannt.
Dürfte für die vor allem ein ziemlicher Sprung zum K Computer werden.
Bin schon irgendwie gespannt auf den Eintrag in die TOP500, denn mit der hohen Speicherbandbreite sollte der in LINPACK gut abschneiden. Die relativ geringe Menge an RAM dämpft eventuell ein bisschen, aber das sollte zumindest da nicht so tragisch sein.
Da auch Vergleiche zu den US Supercomputern aufkamen die ja öfter für relativ spezifische Einsatzzwecke gedacht sind wäre es eventuell auch von interesse dass das RIKEN ziemlich breit aufgestellt ist, einfach mal einen Blick auf deren englische Seite werfen.
Mich würden ja auch noch Erfahrungsberichte von Anwendern interessieren, besonders welche die auch auf x86 Clustern gearbeitet haben. Kompensieren inzwischen die Compiler die meisten Unterschiede, oder muss man immer noch vergleichsweise viel beachten? Hab da früher einige 'fehlende Begeisterung' mitbekommen wenn jemand mal was mit ARM machen musste.
Da wird sicher auch immer wieder recht hardwarenaher Code geschrieben, bei highlevel code kommt das alles kaum zum tragen.
SVE klingt nebenbei auch ziemlich interessant. Klingt etwas als könnte man da mit einem 512 Bit Datentyp rechnen anstatt nur kleinere Datentypen reinpacken. Weiß da vielleicht jemand mehr?
Ist halt die Frage, wie die Berechnungen aussehen, die hauptsächlich darauf laufen sollen. Wenn die verhältnismäßig wenig RAM brauchen, aber von der Bandbreite stark profitieren, bringt HBM2 ja eher Vorteile ggü “klassischem“ RAM.
Und irgendwas werden die Leute sich ja auch dabei gedacht haben, diese Variante zu verbauen.
SVE klingt nebenbei auch ziemlich interessant. Klingt etwas als könnte man da mit einem 512 Bit Datentyp rechnen anstatt nur kleinere Datentypen reinpacken. Weiß da vielleicht jemand mehr?
Aber schonmal vorweg, sofern ich deine Frage richtig verstanden habe: Nein, du kannst, wie üblich, nur vordefinierte, kleinere, Datentypen "reinpacken". Der größte Datentyp scheint 64bit groß zu sein.
Hier stimmt doch was nicht, oder?
Die aktuelle Nummer 1 hat Rpeak 200 TeraFlops, das Teil hier sol über 500 PetaFlops haben, mit nur der 5 oder 6 fachen Anzahl an Kernen? Das ist ja mehr als die 2000fache Leistung. Das ist dochn Schreibfehler?!
edit: ah, gecheckt. Ami Schreibweise. Das sind nicht 200, sondern 200.000 TFlops, also 200 PetaFlops.
Als RAM. Zusätzlicher DDR4 (o.ä.) Speicher ist nicht vorhanden.
Wie bei HBM üblich mit auf dem Package.
Auswirkungen? Sehr hohe Bandbreite des Hauptspeichers, allerdings dadurch auch stark beschränkt in der Kapazität.
nur ARM/SVW/HBM/Tofu statt x86/AVX/HMC/Omnipath. Mit zeitgemäß leicht erhöhtem HBM GB (x2?) und ggf Vernetzungskapazität. Die Zahl der Prozessoren und die die SIMD Vektorgrößen nahezu gleich.
Wer hat solche Stapel-DRAM Konzepte mit CPU-SIMD eigentlich zuerst probiert - Fujitsu oder Intel ?
Aber vermutlich sieht die Verlustleistung/Flops bei der moderneren Technologie und Architekturoptimierungen deutlich besser aus.
Ich gehe mal von einem Vergleich mit KNL aus (ein Vergleich mit KNC "Beschleuniger-Karten" macht wenig Sinn):
Jein, schon recht ähnlich, beim Speicher aber doch anders. Der Xeon Phi x200 hat den Vorteil auf zusätzlichen DDR4 Speicher zugreifen zu können. Die 16GB HMC können in unterschiedlichen Modi konfiguriert und entsprechend verwendet werden. Diese 16GB alleine als Hauptspeicher wären, für die meisten Anwendungen, einfach nicht ausreichend gewesen. Dies ist auch der gravierende Nachteil beim A64FX: 32GB pro CPU werden schnell zu wenig sein. Dies versucht man mit einem sehr guten (?) Interconnect (Tofu) abzufedern.
Naja 29 GBit/s x 2 lanes x 10 Ports, wenn man die 2 lanes mal für hin un her unterstellt bleiben also etwa 290 GBit/s für jede Richtung dieser Tofu Links. Das ist im Vergleich mit der Datenrate von HBM (1 TByte/s beide Richtungen zusammen) aber der übliche Witz - von wahlfreiem Zugriff auf den verteilten Hauptspeicher (a la SMP) ist das meilenweit entfernt. (Die "x2 lanes" sind aber frei interpretiert - man muß tiefer graben als ich's jetzt mag um den Webdokumenten das zu entreißen - wenn die Hersteller wolkiges CPU Geschwafel lieben kann ich das auch ..)
Auch die bislang in (einigen) XEON und PHI verbauten 2x100G (auch je Richtung) Omnipath (entspricht 32xPCIe3.0) waren nicht wirklich sehr viel weniger. (zum Vergleich NVlink/Blulink 2.0 (alt) 6x200GBit/s je GPU chip. 3.0: 12x200G)
Hinsichtlich KNC/KNL - in dem XEON Phi Supercomputer in der Top500 Liste waren wohl von Cray 7250 also tatsächlich welche mit DDR4 und nicht mehr HMC verbaut (tot. 115GByte/s für DDR4 2400x6ch) entsprechend auch mehr Speicher.
