News Für das Metaversum: Metas KI-Supercomputer setzt auf 16.000 Nvidia-GPUs

Duke711 schrieb:
Ja, aber richtige Klimamodelle bauen auf die typischen Methoden wie die Finite Volumen oder Finite Differenzen Methoden auf, die zur FEM verwandt sind und es werden die klassischen numerischen Verfahren wie Runge Kutta verwendet (..) dies läuft hauptsächlich über die CPU

Wuerde ich stark widersprechen.

Der Vergleich mit ANSYS finde ich stark an den Haaren herbeigezogen. Auf Supercomputern rechnet kaum jemand mit ANSYS, und schon gar nicht auf der Skala von mehreren tausend GPUs.

Um das Ganze Mal von dem Niveau von nicht peer-reviewten, und aus meiner Sicht komplett veralteten, Blogposts/Vorlesungsinhalten abzuholen. Aktuelle Klimamodelle laufen insbesonders auf GPUs, wobei das Tooling hierfuer sich fairerweise auch erst in den letzten Jahren etabliert hat.

Die Kernreferenzen hierfuer sind:

Duke711 schrieb:
Dann ist meist auch das Problem das man eine GPU bezüglich Overhead nur mit maximal 8 Kernen effektiv kommunizieren kann usw. Auch ist das Problem der begrenze VRam. Für große Netze sind auch die 48 GB Vram pro GPU zu wenig.

@Airis hat dies schon richig dargelegt. Keine Forschungsgruppe entwickelt mehr homogene CPU-Codes, wenn sie anstrebt auf Tier-0, oder Tier-1 Systemene zu rechnen.

Die Ausnahmen fuer CFD, oder effektiv alle memory-bound HPC-Anwendungen, sind Fugaku mit seinen Fujitsu A-64 FX und die Milan-X Prozessoren, welche beide HBM Speicher auf der CPU haben und somit zu "kleinen GPUs" werden.

P.S.: Die neuen GPUs haben zudem weitaus mehr Speicher mit 80GB (NVIDIA) und 128GB (AMD).
 
  • Gefällt mir
Reaktionen: PHuV
icemanspirit schrieb:
Wuerde ich stark widersprechen.

Der Vergleich mit ANSYS finde ich stark an den Haaren herbeigezogen. Auf Supercomputern rechnet kaum jemand mit ANSYS, und schon gar nicht auf der Skala von mehreren tausend GPUs.

Das stimmt nicht, welche Software sollte dann ansonsten zum Einsatz kommen?
Auf Supercomputer wie HLRS Stuttgart gibt es gewöhnlich wie bie vielen anderen Systemen ein Portfolio wie z.B. Ansys, Openfoam, Star CCM usw. Der jeweilige Anwender wählt die von ihm gewünschte Software.

icemanspirit schrieb:
Aktuelle Klimamodelle laufen insbesonders auf GPUs, wobei das Tooling hierfuer sich fairerweise auch erst in den letzten Jahren etabliert hat.

Die Kernreferenzen hierfuer sind:

Merkwürdige Referenzen. Bei der Referenz Nr. 1 wird ein Python Code vorgestellt und kein eigentliches Klimamodell. Vor allem gibt des die Klimamodelle in unterschiedlichen Detailgraden und bei dem vorgestellen Python Code handelt es sich, nach kurzen Blick, um ein sehr einfaches Klimamodell.
Dann wurde nur bis gerade mal eine Gridsize von einer Million getestet und wie man anhand Figure 5 sehen kann, skaliert der Python Code ab 10 GPUs nicht mehr. Während der Fortan Code über die CPUs (Figure 4) bei ebenfalls einer Million Gridsize noch bei über 300 MPI Prozesse skaliert.
Tut mit leid das spricht jetzt nicht gerade für diesen Python Code. Vor allem ist eine Gridsize von einer Million aus dem Stand der 80er Jahre. Das ist simit keine Referenz. Wie schaut es bei 200 Millionen aus?
Wie bereits erwähnt handelt es sich bei der Publikation um kein etabliertes Klimamodell nach aktuellen Stand der Wissenschaft was pratkisch angewandt wird.

Bei der zweiten Referenz geht es mal wieder um das leidige Thema bei LES auf einer GPU. Das ist nichts neues.

Beispiel von LES auf einer GPU:


Es gibt noch viele andere Beispiele. Problem ist hier einfach die Genauigkeit, aus diesem Grund hat sich das bisher auch noch nicht etabliert.

Kernreferenz:

https://www.cfd-online.com/

mit viele Abhandlungen und Benchmarks das bei CFD über FVM und teilweise FEM eben die GPUs als Beschleuniger keinen Nutzen haben.

Also als Kernreferenzen würde ich die zwei Links bezüglich der Publikationen jetzt nicht sehen und auch nicht als Beleg bezüglich der Behauptung die Berechnungen würden über GPU stattfinden oder deutlich schneller sein.

icemanspirit schrieb:
@Airis hat dies schon richig dargelegt. Keine Forschungsgruppe entwickelt mehr homogene CPU-Codes, wenn sie anstrebt auf Tier-0, oder Tier-1 Systemene zu rechnen.

Die Ausnahmen fuer CFD, oder effektiv alle memory-bound HPC-Anwendungen, sind Fugaku mit seinen Fujitsu A-64 FX und die Milan-X Prozessoren, welche beide HBM Speicher auf der CPU haben und somit zu "kleinen GPUs" werden.

Supercomputer wie der HLRS Stuttgart werden immer für eine breite Anwendergruppe gebaut. Wie ich ursprünglich erwähnt habe ist in Teilbereichen die Beschleunigung durch eine GPU
gegeben. Somit werden die Systeme alle mit GPU Beschleuniger ausgestattet. Das ist aber kein pauschaler Beleg das eben die Systeme ohne GPU Beschleuniger nicht mehr zeitgemäß und in der Berechnungsgeschwindigkeit deutlich unterlegen sind, denn das entspricht nicht den Tatsachen. Bei CFD bietet eine GPU keinen Mehrwert, weitere Referenzen und Benchmarks sind z.B: hier zu finden:

https://www.cfd-online.com/

icemanspirit schrieb:
P.S.: Die neuen GPUs haben zudem weitaus mehr Speicher mit 80GB (NVIDIA) und 128GB (AMD).

Das ist schön, aber trotzdem noch zu wenig. Gängige Praxis über mehrere GPUs per NVLink den Vram erhöhen, tolle Notlösung.
 
Zuletzt bearbeitet:
Duke711 schrieb:
Das stimmt nicht, welche Software sollte dann ansonsten zum Einsatz kommen?
Auf Supercomputer wie HLRS Stuttgart gibt es gewöhnlich wie bie vielen anderen Systemen ein Portfolio wie z.B. Ansys, Openfoam, Star CCM usw. Der jeweilige Anwender wählt die von ihm gewünschte Software.

Hier scheint ein fundamentales Missverstaendnis ob der Nutzung vorzuliegen - die meisten CPUh auf Hawk werden mitnichten mit obig genannten Anwendungen verbracht. Was Du beschreibst ist die Industrienutzung. Diese Maschinen stehen zwar in gewissen Masse der Industrie offen, sind aber zuvorderst fuer die akademische Nutzung gemacht, konzipiert, und allokieren auch so ihre Rechenzeitskontingente.

Akademische Nutzer haben ihre eigene Codes, welche sie fuer diese Maschinen validieren muessen um dann in Gauss-Calls oder den sogenannten Rolling Calls der Rechenzentren ihre Rechenzeit zugewiesen zu bekommen.

Falls Dir die beiden Beispielcodes zu klein waren, hier zwei weitere Codes die bis zu 1000en GPUs skalieren:
 
Zuletzt bearbeitet:
icemanspirit schrieb:
Akademische Nutzer haben ihre eigene Codes, welche sie fuer diese Maschinen validieren muessen um dann in Gauss-Calls oder den sogenannten Rolling Calls der Rechenzentren ihre Rechenzeit zugewiesen zu bekommen.

Glaube ich nicht. Denn einen CFD Code der validierungsfähig, robust und vor allem eine sehr gute MPI Skalierung hat, ist sehr aufwendig und mal eben nicht von einem akademischen Nutzer oder einer kleinen Gruppe geschrieben. Siehe Openfoam und das ist weder Industrie, sondern einfach Open Source, was sehr viele Wissenschafter verwenden.
Außerdem kann man sich auf einen Supercomputer mal eben nicht so einfach seine programmierte Software installieren. Wer soll denn bitte Code für Code das Programm nach einer möglichen Backdoor etc. prüfen?

In der Regel sieht das so aus und das hat überhaupt nichts mit Industrie zu tun, denn das gilt für alle Anwender (science and engineering)

https://www.hlrs.de/solutions-services/service-portfolio/application-software-packages/

icemanspirit schrieb:
Falls Dir die beiden Beispielcodes zu klein waren, hier zwei weitere Codes die bis zu 1000en GPUs skalieren:

Ist mir etwas zu dünn, bezüglich etabliertes Klimamodell:

https://journals.ametsoc.org/view/journals/bams/98/10/bams-d-15-00278.1.xml?tab_body=pdf

Wie erwartet die bekannte GPU Beschleunigung mit mind. 1 GPU pro 8 Kernen (Haswell 8 Kerne) für eine gute Skalierung.

Für einen 64 Kerner, bei Dualsockel 128 Kerne, werden dann 16 GPUs benötigt.

16 * Tesla V100

= 160.000 Euro

Für diese zusätzliche Kosten würde man zusätzlich für 20.000 Euro acht weiter Nodes bekommen:

System
1 Node
2x 7713 Eypc
16x Tesla V100

System
9 Nodes
2x 7713 Eypc

Zumal das 9 Node System deutlich mehr RAM hat und somit viel größere Modelle berechnen kann bzw. eine deutlich größere Speicherbandbreite, sehr wichtig für CFD.

Dürfte wohl klar sein welches das schnellere System ist. Denn der GPU Speedup liegt nur bei Faktor 2,5, also +250%.


Wird schon einen Grund haben warum viele praktische Anwender ihre Cluster für solche Simulationen nicht mit GPUs ausstatten. Ich habe zware nichts mit Klimamodellen zu tun, aber für meine Anwendungen sind GPU Beschleuniger nettes Marketing und nicht lohnenswert und ja ich habe selbst Benchmarks durch geführt.
 
Zuletzt bearbeitet:
Schaut euch doch einfach an was an Systemen gekauft wird. In Deutschland sind Tier0/1 Jülich, HLRS und LRZ. Bis auf Jülich sind das reine CPU Kisten und auch bei Tier2 sind es fast nur CPU only Systeme, wenn man mal die AI/ML Maschinen ausnimmt.

Aber auch wenn man sich PRACE anschaut sind die GPUs die Exoten.

Klar die neuesten großen Maschinen sind GPU Maschinen, aber auch da sind es "nur" GPU Partitionen genau wie in Jülich.

Und warum? Weil halt das absolute Groß der Anwendungen für die Rechenzeit drauf geht, CPU only ist. Das ist auch heute noch ein sehr langsamer Prozess hin zur Verwendung von GPUs.

Aber was man auch Bedenken sollte
Es geht nicht NUR um Capability sondern auch um Capacity Computing. Also throughput ist durchaus wichtig. Und da ist es auch ok, wenn es nur auf einer GPU läuft, aber schneller ist. Ich habe ja eh VIELE runs.
 
  • Gefällt mir
Reaktionen: Duke711
Duke711 schrieb:
Das stimmt nicht, welche Software sollte dann ansonsten zum Einsatz kommen?
Auf Supercomputer wie HLRS Stuttgart gibt es gewöhnlich wie bie vielen anderen Systemen ein Portfolio wie z.B. Ansys, Openfoam, Star CCM usw. Der jeweilige Anwender wählt die von ihm gewünschte Software.
Ansys/Abaqus skalieren in der Regel bis grob 64 Prozessoren. Eine compute node der HLRS Hawk hat 128 Prozessoren. Solche Pakete sind extrem flexibel bezüglich der zu simulierenden Phänomene. Aber die Flexibilität hat Nachteile in der Skalierbarkeit.

Dass solche Pakete vorgehalten werden stimmt aber schon. Zumal es nicht nur die großen Supercomputer, sondern auch die kleineren Cluster mit Schränken voller heterogener compute nodes gibt.

OpenFoam, Code Aster, Trixi.jl, AVBP, ... sind noch gute Beispiele für Ingenieurmäßige use cases.
 
Zurück
Oben