HWL News Bot
News
Thread Starter
- Mitglied seit
- 06.03.2017
- Beiträge
- 113.960
... weiterlesen
Der schnellste Supercomputer steht ab sofort in Japan
- Ersteller HWL News Bot
- Erstellt am
... weiterlesen
"A64FX" Das erste was mir dazu in den Kopf kam war der Athlon 64 FX von 2003. 
Was die Ingenieure sich bei der Namensgebung gedacht haben?
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"A64FX" Das erste was mir dazu in den Kopf kam war der Athlon 64 FX von 2003.
Was die Ingenieure sich bei der Namensgebung gedacht haben?
.Du meinst die AMD Ingenieure von damals ?"A64FX" Das erste was mir dazu in den Kopf kam war der Athlon 64 FX von 2003.
Was die Ingenieure sich bei der Namensgebung gedacht haben?
Am Besten wir entfernen die Buchstaben F und X aus dem Alphabet.
Klar, statt f nehmen wir v, klappt bei '"vater" ja auch.
Und statt x dann "iks" so wie es vor der erfindung des x 1633 auch war.
smalM
Enthusiast
@DeckStein
Das X wurde von den alten Griechen "erfunden".
Daß es ausschließlich CPUs sind ist doch gerade der Witz daran!
Das X wurde von den alten Griechen "erfunden".
Nur in passenden Aufgabestellungen, bei denen die GPUs ihre Parallelität ausspielen können.
"nur"
Daß es ausschließlich CPUs sind ist doch gerade der Witz daran!
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.
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."nur"
Daß es ausschließlich CPUs sind ist doch gerade der Witz daran!
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
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 ?
smalM
Enthusiast
Nicht nur auf dem Papier.
Fujitsu selbst wird 2U-Einschübe (8 CPUs) und ganze Serverschränke (384 CPUs) anbieten, die Skalierung ist ausgelegt bis 1024 Racks (393216 CPUs).
Cray wird auf Basis des A64FX eine eigene Lösung anbieten.
Fujitsu selbst wird 2U-Einschübe (8 CPUs) und ganze Serverschränke (384 CPUs) anbieten, die Skalierung ist ausgelegt bis 1024 Racks (393216 CPUs).
Cray wird auf Basis des A64FX eine eigene Lösung anbieten.
DragonTear
Legende
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.
Cunhell
iceman_brinkmanship
Profi
- Mitglied seit
- 14.02.2020
- Beiträge
- 19
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.
Es gibt aber derzeit wohl nur genau eine ARM CPU mit SVE.
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.
iceman_brinkmanship
Profi
- Mitglied seit
- 14.02.2020
- Beiträge
- 19
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.)
Laut https://www.fujitsu.com/global/Images/supercomputer-fugaku.pdf: Linux . was ja zu erwarten war.