Der schnellste Supercomputer steht ab sofort in Japan

Thread Starter
Mitglied seit
06.03.2017
Beiträge
113.971
riken.jpg
Derzeit konzentriert sich in der Berichterstattung über die Supercomputer auf die zukünftigen Exascale-Systeme, die ab 2021/22 mit einer Rechenleistung von einem EFLOPS (ExaFLOPS). Aurora und El Capitan heißen die Systeme, die von Intel und AMD ausgestattet werden. Nun vermeldet das Forschungsinstitut RIKEN in Japan die finalen Daten zum Supercomputer Fugaku.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
"A64FX" Das erste was mir dazu in den Kopf kam war der Athlon 64 FX von 2003. :fresse2:

Was die Ingenieure sich bei der Namensgebung gedacht haben?
 
"A64FX" Das erste was mir dazu in den Kopf kam war der Athlon 64 FX von 2003. :fresse2:

Was die Ingenieure sich bei der Namensgebung gedacht haben?
Viel, der Fujitsu A64FX beinhaltet auch den TOFU-Controller aka Tofu D Interface aka Tofu Interconnect. Mich würde mal interessieren wie schwer das tatsächlich zu machen ist, im Prinzip ist es nur ein ARM Kernmonster zugepackt mit Cache und HBM2 :o.
 
Die Spitzenrechenleistung eines einzelnen Prozessors liegt bei 3,3792 TFLOPS (FP64), 6,7584 TFLOPS (FP32) und 13,5168 TFLOPS (FP16)

Der 3990X hat "nur" 3,2TFLOPS FP64.

Ich finde es interessant das eine CPU ausschließlich für diesen Supercomputer entwickelt wird? Vielleicht diente diese CPU auch als Sprungbrett für weitere Forschungen auf dem Gebiet.
Japan ist wohl dabei sich unabhängiger zu machen.
 
"nur" :sneaky:
Daß es ausschließlich CPUs sind ist doch gerade der Witz daran!
Die erste Server CPU in 10nm war doch der Centriq 2400 von Qualcomm, auch ein ARM 48 Kern Design, was soll daran witzig sein ? Der A64FX sieht relativ Simpel aus vom Aufbau eigentlich das wollte ich damit sagen.
 
....., was soll daran witzig sein ? Der A64FX sieht relativ Simpel aus vom Aufbau eigentlich das wollte ich damit sagen.

Der Witz ist, dass Du bei einem HPC-System welches nur CPUs ( ARM, x64, IA64, etc..) verwendet, bei Deinem Programmcode nicht auf die Einschränkungen und Besonderheiten von den Beschleunigerkarten Rücksicht nehmen musst. Man vereinfacht damit auch die Programmierung und Optimierung des Codes auf bestmögliche Performance und Skalierung.
Außerdem sind nicht alle Fragestellungen für HPC-Systeme mit Beschleunigerkarten geeignet und man verliert die Performance der Beschleunigerkarten, wenn man das dann auf solchen Systemen rechnen will/muss.

Cunhell
 
im Prinzip ist es nur ein ARM Kernmonster zugepackt mit Cache und HBM2
Die Rechenleistung wird im wesentlichen aber von den SVE-Einheiten erbracht, die bisher bei keinen anderen ARM Prozessoren vorhanden sind.
Der Witz ist, dass Du bei einem HPC-System welches nur CPUs ( ARM, x64, IA64, etc..) verwendet, bei Deinem Programmcode nicht auf die Einschränkungen und Besonderheiten von den Beschleunigerkarten Rücksicht nehmen musst
Hier muss der Programmcode für die SVE-Einheiten optimiert werden.
 
Die Rechenleistung wird im wesentlichen aber von den SVE-Einheiten erbracht, die bisher bei keinen anderen ARM Prozessoren vorhanden sind.

Hier muss der Programmcode für die SVE-Einheiten optimiert werden.
Ich sehe den Clou. Fujitsu plant das aber nicht in der Masse oder, sieht nämlich auf dem Papier ziemlich effizient aus ?
 
Die Rechenleistung wird im wesentlichen aber von den SVE-Einheiten erbracht, die bisher bei keinen anderen ARM Prozessoren vorhanden sind.

Hier muss der Programmcode für die SVE-Einheiten optimiert werden.
Richtig und damit ist das jetzt auch kein Wunderwerk im Vergleich zu GPU-basierten Systemen mehr denn für SVE musst du ebenso dafür sorgen dass der Algorithmus möglichst viele gleichartige Rechnungen gleichzeitig ausführt.
 
Natürlich muss der Code für den Befehlssatz der CPU geschrieben und optimiert werden. Das habe ich ja geschrieben. Man muss z.B. auch Rücksicht auf die unterschiedlichen Intel-Prozessorgenerationen und deren Eigenheiten nehmen, um die höchstmögliche Performance zu erhalten.
Aber ich muss nicht zusätzlich den Code für die Beschleunigerkarten wie die von Nvidia oder AMD anpassen. Und der Code läuft erst mal auf jeder ARM-CPU, die den Befehlssatz unterstützt, was die Erstellung des Codes dem Nutzer vereinfacht. Außerdem kann ich mit einer CPU-Only Konfiguration eine sehr viel größere Bandbreite an Fragestellungen abdecken, als mit einer Kombination aus CPU und Beschleunigerkarte.
Das Rechner, welche Beschleunigerkarten verwenden, in manchen Fragestellungen performanter sind steht außer Zweifel. Darum gibt es die Karten ja ;-)
Aber das hat halt auch seine Nachteile. Einfach ein paar Beschleunigerkarten hinzufügen und alles wird gut, ist halt nicht.
Genau darum gibt es ja die CPU-Only Rechner.

Cunhell
 
(..)
Aber ich muss nicht zusätzlich den Code für die Beschleunigerkarten wie die von Nvidia oder AMD anpassen. Und der Code läuft erst mal auf jeder ARM-CPU, die den Befehlssatz unterstützt, was die Erstellung des Codes dem Nutzer vereinfacht. Außerdem kann ich mit einer CPU-Only Konfiguration eine sehr viel größere Bandbreite an Fragestellungen abdecken, als mit einer Kombination aus CPU und Beschleunigerkarte.
Das Rechner, welche Beschleunigerkarten verwenden, in manchen Fragestellungen performanter sind steht außer Zweifel. Darum gibt es die Karten ja ;-)
Aber das hat halt auch seine Nachteile. Einfach ein paar Beschleunigerkarten hinzufügen und alles wird gut, ist halt nicht.
Genau darum gibt es ja die CPU-Only Rechner. (..)

Ja und nein aus meiner Sicht.

Wir haben drei Codes, die jeweils bis zu 40k+ CPU Kernen skalieren und aus meiner Erfahrung mit diesen Codes und so wie ich das Feld derzeit auf dem Sprung hin zur Exascale-Aera betrachte wird mehr und mehr Abstraktion in die Compiler geschoben. Intel OneAPI ist da so ein Versuch, doch am Donnerstag hat NVIDIA auch das HPC-SDK angekuendigt mit Standardcompilern, die die Standardsprache i.e. C++, FORTRAN auf GPUs optimieren. So ist zumindenst das Versprechen.

In den naechsten Wochen sollten die Codes zum ersten Mal mit den NVIDIA Compilern getestet werden - also Mal schauen.

Wenn es wirklich ueber die Compiler geht sehe ich qualitativ keinen grossen Unterschied zwischen den Ansaetzen (CPU only, CPU+GPU). Am Ende des Tages sind die numerischen Algorithmen an sich auch der begrenzende Faktor und nicht die zu Grunde liegende Architektur.

Die CPU only Rechner werden denke ich in den naechsten 5-10 Jahren aus der Supercomputing Arena verschwinden und sich auf das Level der Universitaetscluster reduzieren.
 
Und der Code läuft erst mal auf jeder ARM-CPU, die den Befehlssatz unterstützt,
Es gibt aber derzeit wohl nur genau eine ARM CPU mit SVE.
Die CPU only Rechner werden denke ich in den naechsten 5-10 Jahren aus der Supercomputing Arena verschwinden und sich auf das Level der Universitaetscluster reduzieren.
Gibt es überhaupt noch Supercomputer, wo die Rechenleistung in wesentlichen von einer universellen CPU erbracht wird und nicht von spezialisierten, im CPU-Die integrierten AVX/SVE Einheiten? Der Vorteil einer GPU Lösung ist m. E. das man das Verhältnis zwischen Vektorleistung (GPU) und universeller Rechenleistung (CPU) je nach Anwendungsfall etwas variieren kann. Bei einer CPU-only Lösung ist man da festgenagelt.
 
(..)
Gibt es überhaupt noch Supercomputer, wo die Rechenleistung in wesentlichen von einer universellen CPU erbracht wird und nicht von spezialisierten, im CPU-Die integrierten AVX/SVE Einheiten? Der Vorteil einer GPU Lösung ist m. E. das man das Verhältnis zwischen Vektorleistung (GPU) und universeller Rechenleistung (CPU) je nach Anwendungsfall etwas variieren kann. Bei einer CPU-only Lösung ist man da festgenagelt.

Gibt noch eine ganze Reihe an CPU-only Rechnern. So zur Zeit zum Beispiel HAWK und SuperMUC-NG, wobei man hier argumentieren kann, dass beide CPUs auch AVX Einheiten haben. Das Problem sind bei all diesen Supercomputer Konfigurationen immer eher die Nutzer und ihre Codes. Die US Superrechner haben extrem viel Geld fuer ihre Codes und das Feintuning auf die jeweiligen Architekturen, waehrend im Europaeischen Raum die Forschungscode eher historisch wachsen und deswegen mehr Hilfe bei solchen Umstellungen brauchen (Was daher konservative Kaeufer auch dazu anregt eher eine klassische CPU-only Maschine, wie z.B. SuperMUC-NG zu kaufen um die Nutzer vor nicht allzu grosse Umstellungsprobleme zu stellen.)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh