Frontier: AMD liefert Zen-CPUs und Radeon-GPUs für 1,5-ExaFLOPS-Supercomputer
Das Oak Ridge National Laboratory hat Frontier angekündigt. Der Supercomputer wird vom US-amerikanischen Energieministerium in Auftrag gegeben, von AMD und Cray gebaut und soll mit einer Rechenleistung von über 1,5 ExaFLOPS ab 2021-2022 das schnellste System werden. Aurora mit Intels Xeon-CPUs und Xe-Beschleunigerkarten übertrifft man damit.
Im März sorgte das US-amerikanische Energieministerium (Department of Energy, DOE) bereits für Schlagzeilen. Damals wurde Aurora angekündigt, der als erster Supercomputer der Welt die Rechenleistung von einem ExaFLOPS überschreiten soll. Er nutzt ausschließlich Hardware aus dem Hause Intel in Form kommender Xeon-Prozessoren und Beschleunigerkarten mit Xe-GPUs. Noch im selben Jahr möchte das DOE einen zweiten Supercomputer erstmals ans Netz bringen: Frontier. Dieser wird im Oak Ridge National Laboratory stehen und wissenschaftliche Berechnungen durchführen. Bei der Rechenleistung soll er neue Maßstäbe setzen: Über 1,5 ExaFLOPS an durchgehender Rechenleistung sind anvisiert, wobei die Fertigstellung bis ins Jahr 2022 hinein dauern wird.
AMD liefert CPUs und GPUs für 1,5 ExaFLOPS Rechenleistung
Als alleiniger Chiplieferant fungiert dieses Mal AMD. Die Webseite anandtech.com merkt an, dass das DOE gesetzlich dazu verpflichtet ist, die Hardware von mindestens zwei Herstellern zu beziehen. Mit Intel für Auroa und AMD für Frontier wird die Bedingung erfüllt. Nvidia, einstiger Hauptlieferant für Beschleunigerkarten, geht leer aus - womöglich, weil AMD und Intel komplette Ökosysteme für CPUs und GPUs liefern können.
Auf Seiten der Hardware gehen die beteiligten Firmen noch nicht allzu sehr ins Detail. AMD spricht von angepassten Epyc-Prozessoren und Radeon-Instinct-GPUs. Die Custom-Lösungen sollen für die Bereiche Deep Learning und KI optimiert sein. In Anbetracht des Zeitfensters dürfte Zen 3 oder gar Zen 4 die Basis auf Seiten der CPUs bilden. Bei den GPUs erscheint ein Navi-Nachfolger realistisch. Per Infinity-Fabric-Interconnect sollen die CPUs und GPUs aneinander gekoppelt werden. Auf jeden Prozessor kommen vier Beschleunigerkarten.
Über 600 Mio. USD teuer
Der Bau von Frontier wird mit Ausgaben von über 600 Millionen US-Dollar konnotiert. Ein Teil davon geht an Cray, der die Infrastruktur für Frontier - genauso wie für Aurora - bereitstellen wird. Geplant ist der Einsatz eines kommenden Slingshot-Interconnects zum Verbund der verschiedenen Nodes. Danach bleibt offensichtlich genug Geld übrig, um angepasste Siliziumchips von AMD zu finanzieren.
Von meinen Quellen im IT-fernen wissenschaftlichen Bereich höre ich dagegen wenig über CUDA. Matlab ist Standard auf studentischer Ebene und große Projekte eben oft Fortran, seltener Lisp, vereinzelt wohl sogar COBOL. Wikipedia sagt, dass (US-)Raumfahrt und Militär, die hinter vielen der Großprojekte für diese Supercomputer stecken, Ada bevorzugen. Eine Sprache, über die ich sonst gar nichts weiß, die aber scheinbar wenig mit Bibliotheken des letzten Jahrzehnts zu tun hat.
1.) Fortran geht nicht weg. Es gibt viele hochaktuelle HPC Codes, die mit dem neuen Fortran Standard geschrieben werden. Von der NASA z.B. laufen auch noch viele Codes auf Fortran77 und die Performance laesst keine Wuensche offen.
2.) CUDA hat seine Daseinsberechtigung erfordert jedoch die Anwendungen die GPUs wirklich nutzen koennen. Manche Anwendungen koennen dies und manche koennen dies nicht. Besonders auf der HPC Seite gibt es Nutzfaelle, wo CUDA sinnfrei ist oder man mit weniger Investment an anderer Stelle Performance rausholen kann in dem man zum Beispiel Teile des Codes optimiert in Assembler schreibt.
3.) Wenn man sich den Datensheet fuer Frontier anschaut, dann kann man fest davon ausgehen, dass hier wieder ein Linux als Basis genommen wird und dann weiteroptimiert wird. Da bei dem Vertrag 100 Millionen alleine fuer die Softwareentwicklung enthalten sind, sollten jegliche Anpassungen kein Problem sein. Quelle: https://www.olcf.ornl.gov...
Da der Trend immer mehr zu heterogenen Anwendungen geht kann ich mir auch sehr gut vorstellen, dass man klassische CPU basierte Codes laufen laesst und einzelne serielle Teile mit vortrainierten neuronalen Netzwerken, die auf den GPUs laufen, kombiniert und eventuell globale Optimierungen mit Reinforcement Learning vornimmt, welches auch auf den GPUs laufen wuerden. Solche Systeme bringen auch neue Paradigmen grosse Simulationen zu machen hervor.
Eines ist auch klar. Der Gordon Bell Preis fuer Supercomputing wird in 2022 nur ueber Frontier gehen falls er dann online ist.
Wie gesagt: Video ist eine Sache. Eine, die Hardware-Hersteller als unterstützungswürdiges Betätigungsfeld entdeckt haben aber auch eine bei der sonst niemand das Rad neu erfindet.
Von meinen Quellen im IT-fernen wissenschaftlichen Bereich höre ich dagegen wenig über CUDA. Matlab ist Standard auf studentischer Ebene und große Projekte eben oft Fortran, seltener Lisp, vereinzelt wohl sogar COBOL. Wikipedia sagt, dass (US-)Raumfahrt und Militär, die hinter vielen der Großprojekte für diese Supercomputer stecken, Ada bevorzugen. Eine Sprache, über die ich sonst gar nichts weiß, die aber scheinbar wenig mit Bibliotheken des letzten Jahrzehnts zu tun hat.
Für Videoschnitt und CGI auf handelsüblichen Workstations und Servern gibt es eine breite Palette kommerzieller Software-Anbieter.
Für die Simulation von Kernwaffen auf Supercomputern von denen es genau ein Exemplar weltweit gibt, sollte man dagegen seine eigene Software mitbringen. Schon allein deswegen weil niemand externes Kompatibilitätstests auf so einer Anlage durchführen kann und weil diese sehr teuren Anlagen explizit für Aufgabenstellungen gebaut werden, die sich mit kleineren, bestehenden Systemen nicht hinreichend berechnen lassen. Da können schon kleine Anpassungen Rechenzeit im Werte von hunderttausenden US-Dollar einsparen.
Hochspezifische Optimierungen müssen dennoch nicht die Regel darstellen; zumindest in der nicht-militärischen Forschung fehlt es an der Schnittstelle zwischen Naturwissenschaft und Programmierung oft an Experten, die genug von beidem verstehen, um die hochkomplexen Aufgaben in hocheffizienten Code umzusetzen. Statt einem großen, effizienten Wurf basieren Klimamodelle dann auf über die Jahrzehnte gewachsenen Simulationsansätzen, geschrieben in antiken Programmiersprachen. Aber auch in solchen Fällen arbeitet niemand auf hohen, per Definition ineffizienten Abstraktionsebenen und der Quellcode steht per Definition für angepasste Rekompilierungen zur Verfügung – Supercomputer arbeiten in der Regel "close to the metal". Aktuelle Angaben habe ich nicht zur Hand, aber Japans Earth Simulator hatte meinem Wissen nach nicht einmal so etwas wie ein Betriebssystem. Stattdessen gab es ein paar Demo-/Entwicklerracks auf denen zu berechnende Aufgaben so in Systemcode eingebettet wurden, dass am Ende eine problem- und systemspezifische Firmware entstand, die direkt auf der Hardware lief. Nicht unähnlich den frühen Videospielkonsolen aus den 80ern, nur mit einer Rechenleistung die besagte Hollywood-Studios auch heute noch als ansehnlich erachten würden und einer Systemarchitektur, die Entwickler (Alb-)träumen lässt.
ja, es werden noch viele Altlasten an Fortran-Code uä mitgeschleppt, diese werden aber mehr und mehr neu geschrieben.
Bei Supercomputern - ja, da läuft nur ein Supervisor und normalerweise kein Program das wir als Betriebssystem bezeichnen würden - Aber:
Der Code der dort läuft ist teils sogar MatLab - effizient sieht anders aus. Ein sehr großer Teil ist auch einfach Java-code ( da kann die JRE noch viel verbessern).
Wenn die Leistung voll benötigt wird dann wird auch entsprechend viel Aufwand in eine gute Code-Struktur gesteckt - und das wiederum heisst fast immer auch das die entsprechenden Libraries und SDKs genommen werden und die schon millionen Mannstunden gesteckt wurden.
Ja, es gibt eine sehr große Auswahl an professioneller Video-Software. Und was hat der Großteil davon gemeinsam? Hardware-Beschleunigung mittels Cuda oä.
Avid Media Composer, Vegas, VDL, PowerDirector - Cuda support.
Adobe, autdesk? Cuda.
Es ist halt deutlich einfacher wenn man sich auf das Spezielle Problem konzentrieren kann und nicht jede rudimentäre Funktion neu erfinden muss. Es wäre bei mir unvorständlich alles an Software inhouse zu entwickeln ohne auf solche Libraries zurück greifen zu können. Da würde aus einem 10 mio projekt schnell mal 100 mio werden.
Braucht man sich nur Hollywood ansehen - die großen Filmstudios haben doch ein recht ansehnliches Budget - trotzdem wird dort nur sehr wenig an eigener Software erfunden sondern auf die großen Anbieter zurückgegriffen.
Für die Simulation von Kernwaffen auf Supercomputern von denen es genau ein Exemplar weltweit gibt, sollte man dagegen seine eigene Software mitbringen. Schon allein deswegen weil niemand externes Kompatibilitätstests auf so einer Anlage durchführen kann und weil diese sehr teuren Anlagen explizit für Aufgabenstellungen gebaut werden, die sich mit kleineren, bestehenden Systemen nicht hinreichend berechnen lassen. Da können schon kleine Anpassungen Rechenzeit im Werte von hunderttausenden US-Dollar einsparen.
Hochspezifische Optimierungen müssen dennoch nicht die Regel darstellen; zumindest in der nicht-militärischen Forschung fehlt es an der Schnittstelle zwischen Naturwissenschaft und Programmierung oft an Experten, die genug von beidem verstehen, um die hochkomplexen Aufgaben in hocheffizienten Code umzusetzen. Statt einem großen, effizienten Wurf basieren Klimamodelle dann auf über die Jahrzehnte gewachsenen Simulationsansätzen, geschrieben in antiken Programmiersprachen. Aber auch in solchen Fällen arbeitet niemand auf hohen, per Definition ineffizienten Abstraktionsebenen und der Quellcode steht per Definition für angepasste Rekompilierungen zur Verfügung – Supercomputer arbeiten in der Regel "close to the metal". Aktuelle Angaben habe ich nicht zur Hand, aber Japans Earth Simulator hatte meinem Wissen nach nicht einmal so etwas wie ein Betriebssystem. Stattdessen gab es ein paar Demo-/Entwicklerracks auf denen zu berechnende Aufgaben so in Systemcode eingebettet wurden, dass am Ende eine problem- und systemspezifische Firmware entstand, die direkt auf der Hardware lief. Nicht unähnlich den frühen Videospielkonsolen aus den 80ern, nur mit einer Rechenleistung die besagte Hollywood-Studios auch heute noch als ansehnlich erachten würden und einer Systemarchitektur, die Entwickler (Alb-)träumen lässt.