Leibniz-Rechenzentrum setzt auf Sapphire Rapids und Ponte Vecchio

Thread Starter
Mitglied seit
06.03.2017
Beiträge
113.949
intel-2020.jpg
Das Leibniz-Rechenzentrum hat erste Details zur Phase zwei des SuperMUC-NG bekanntgegeben. Für die kommende Ausbaustufe zum Einsatz kommen sollen Xeon-Prozessoren der nächsten Generation (Sapphire Rapids) und Beschleuniger auf Basis der Xe-HPC-Architektur Ponte Vecchio. Beide stammen von Intel, genau wie 1 PB an Distributed Asynchronous Object Storage (DAOS), der auf Optane DC SSDs und Optane DC Persistent Memory basieren wird.

... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich frag mich ja was die auf den Ponte Veccio GPUs ohne vernünftiges Ökosystem rechnen wollen.

Das ist doch fast alles in CUDA geschrieben.
 
Ein Kumpel von mir ist an der Uni und forscht im Bereich theoretische Chemie.
Die haben einen eigenen Cluster im Keller mit zig Nvidia Titan aus der ersten Generation.

Nachdem die Consumer Nvidia Karten in Sachen DP Performance dann aber nicht mehr brauchbar waren sind sie auf OpenCL umgestiegen um AMD Karten nutzen zu können, man ist da also durchaus flexibel.
 
Hab ich das jetzt richtig gelesen, daß wir 1PB an Optanes kaufen??? 🤪

Ich wüsste wirklich mal gerne wofür man die Teile schneller und schneller braucht und eben was wirklich mit "speziell qualifizierten Forschungsprojekten bundesweit in einem wissenschaftlichen Auswahlverfahren" gemeint ist.

1. SuperMUC-NG macht ja bis heute nichts mit GPGPU. Es sind nur wenige Teslas drin und das nur zu Testzwecken...

2. Intel treibt in der Khronos Group extrem Spir-V und sämtliche Umgebungen/Compiler an, um möglichst einfach wie effizient CUDA zu portieren. AMD tut da übrigens diesbezüglich auch soviel sie halt.
Anschließend kann man das eben schon real sehr einfach, auf allem mögliche fahren. Also nicht nur Intel oder AMD, sondern auch z.B. auf ASICs.
Da gehts schon seit 4 Jahren rund und mittlerweile ist das auch relativ brauchbar und gut. Auch wenn man die Sachen direkt drauf macht und nicht Cuda-Code ummoddet.

p.s.:
Ich glaub da ist ein kleiner Fehler im Text:
"Die Phase eins des SuperMUC-NG verwendet aktuell 12.960 Intel Xeon Platinum 8174 mit jeweils Kernen."
Daß ein Xeon Platinum jeweils Kerne hat, das ist denk ich jedem bewusst ;)
 
Zuletzt bearbeitet:
Sachlich bleiben hilft uns doch allen weiter, nicht wahr?
 
Ich kenn mich nicht so aus. Vielleicht kann jemand Licht ins Dunkel bringen. Wie sehr ist man durch die verwendete Software denn an die Plattform gebunden? Ich kann mir keinen anderen Grund denken, warum man noch Intel-Server-CPUs nimmt. Spart man durch Epyc nicht irre viel Kohle bzw. kriegt irre viel Mehrleistung in nur einem Chip?
 
Ich kenn mich nicht so aus. Vielleicht kann jemand Licht ins Dunkel bringen. Wie sehr ist man durch die verwendete Software denn an die Plattform gebunden? Ich kann mir keinen anderen Grund denken, warum man noch Intel-Server-CPUs nimmt. Spart man durch Epyc nicht irre viel Kohle bzw. kriegt irre viel Mehrleistung in nur einem Chip?
Es ist nichts über die genauen Kaufsummen der einzelnen Einheiten bekannt - soweit ich das sehe!?
Epyc ist nicht günstiger. Das ist für Retail Listenpreise vllt der Fall - aber kein Mensch zahlt Liste abseits der Foren-Schreihälse, die das immer gern vergleichen ;)
Weiterhin ist "irre viel" in der Form nicht zutreffend. Ja, 64C Eypc Rome und die neuen Zen3 based Epycs mit gleicher Anzahl sind schneller als die neuesten Intel Xeons - in vielerlei Hinsicht. Hier reden wir aber entweder über die erste Phase vom SuperMUC-NG - da gab es schlicht und ergreifend noch keine Epyc Rome CPUs - die wurden erst im Spätsommer bis Herbst 2019 vorgestellt. Das System läuft aber seit 01/2019. Oder wir sprechen über die kommenden Sapphire Rapids Xeons und Ponte Vecchio GPUs - da bleibt einfach abzuwarten, was bei rum kommt. Gerüchten zur Folge sollen das 56C in vier Slices werden, wenn ich das richtig im Kopf hab... Zzgl. der nächsten Architekturstufe - möglicherweise >Zen3 IPC. Im dritten 10nm Aufguss. Was das bringt, wie gesagt, werden wir sehen. +-64C Rome, ggf. auch Milan Level würde man aber schon erwarten.

Mal davon ab, in den Größenordnungen wo man sich dort bewegt. Mit allen drum und dran, Kühlung, Vernetzung der Nodes, Speicher, Storage, GPUs usw. usf. -> der CPU Preis geht einfach komplett unter.
Weiterhin kommt hier dazu, dass es sich gefühlt irgendwie um ein Intel Vorzeige Projekt handelt. Sprich Intel wird hier ganz sicher bisschen die Hosen runter gelassen haben um eben etwas in der Größenordnung mit Medienwirksamkeit ausgestattet zu bekommen. Sprich ob da groß was dran verdient wird, ist fraglich.

Kurzum, neeee, irre viel Kohle spart man nicht mit Epyc, weil es keine Epyc CPUs zur Anschaffungszeit der ersten Stufe gab, die überhaupt in Frage kamen - und irre viel Mehrleistung kommt dabei dann auch nicht raus.

Ob man das heute, wenn man sagen wir Mid. 2021 fertig werden wollen würde, anders bauen würde - wahrscheinlich. Dann mit Rome oder direkt Milan und vllt dicke AMD oder NV GPUs rein anstatt auf Ponte Vecchio warten. War aber eben hier zeitlich nicht der Plan... Man will wohl Anfang 2022 mit Phase 2 fertig werden und Phase 1 läuft aktiv seit 01/2019. Damit gings nur so - oder mit Naples. Dann aber auch maximal 32C pro Socket und 2x4x NUMA pro "Node" vs. 2x NUMA pro "Node" bei der Skylake Geschichte.
 
@StefanG3
Von Phase1 auf Phase2 wäre das der reinste Irrsinn. Dermassen, daß ich aufschreckte als ich grad überlegte was ich alles auf- und ausschreiben könnte, warum. Warum nicht schon bei Phase1 AMD hat fdsonne auch glasklar erotert. Warum nicht für Phase2...

Im kürzesten wäre vielleicht mal wieder eine Auto-Analogie 🤪 Man nehme den Pagani Zonda. Und eine Presseinfo, daß sie jetzt ein Facelift davon rausbringen. Und jemand kommt anschließend und fragt in einem Forum warum sie nicht den M V12 dafür genommen haben (Liste mit Vorteilen im Gepäck), sondern wieder den AMG V12. Antwort:
Nichts an dem Auto ist für einen anderen Motor ausgelegt. Weder die Motorsoftware noch der Antriebsstrang noch die Stellen wo der Motor mit dem Auto verbunden ist. So ein Vorhaben, für ein Facelift, wäre, richtig: Irre. Genauso ist es mit einer Phase2 bei einem Großrechner.
Nur weil beide Motoren SuperPlus brauchen und man auch den Tankstutzen behalten kann, bringt noch keine Erleichterung bei so einem Vorhaben.

Mal davon ab, daß am Anfang ein Vertrag mit Intel steht wo alle geplanten Phasen mit Kosten UND Leistungen drin stehen. Leistungen als Rechenleistung wie Verbrauch. Und Support.
Die Preisgestaltung wird auch recht angenehm sein für solche Mengen. Nicht wegen einem Mengenrabatt :) sondern weil das für Intel sehr große Werbung ist. Wenn man da sozusagen mit Eigenwerbung noch einen kleinen Plus macht, dann kann einem nichts besseres passieren.
Ich nehme daher nicht an, daß Intel sich bei solchen Projekten satt frisst.
 
@StefanG3 nicht zu vergessen ist auch, dass das Leibniz Rechenzentrum effektiv ein Intel-Shop ist. Sie kaufen bevorzugt Intel, auch wenn Sie danach komplett verbrannt werden wie bei SuperMUC NG geschehen, der in Produktion erst weit nach 01/19 ankam, am Anfang extrem instabil lief und bis heute nicht die Leistung liefert welche bei der Anschaffung versprochen wurde.

Was hier effektiv gekauft wird ist ein (viel) kleinerer Klon von Aurora, i.e. eines der drei US-Exascale Systeme entstehend an den Argonne National Labs, da die meisten Europaeischen pre-Exascale (>100Pf) Maschinen bisher ueber AMD liefen wird Intel diese Maschine auch brauchen um mit Ihrer Vision fuer die naechsten Jahre im Europaeischen Markt relevant zu bleiben und daher werden dort entsprechend Nachlaesse gegeben worden sein.
 
Wow Leute, ihr seid voll in eurem Element anscheinend. Danke für die Infos. Ist für einen Außenstehenden schon interessant.
 
Ich hoffe ich bin hier nicht der einzige Depp, der sich beim Lesen der Überschrift gefragt hat, was ein Keks Hersteller mit einem Rechenzentrum will :bigok:
 
Ich hoffe ich bin hier nicht der einzige Depp, der sich beim Lesen der Überschrift gefragt hat, was ein Keks Hersteller mit einem Rechenzentrum will :bigok:
Es müssen schließlich 52 Zähne addiert werden. :fresse:
 
@StefanG3 nicht zu vergessen ist auch, dass das Leibniz Rechenzentrum effektiv ein Intel-Shop ist. Sie kaufen bevorzugt Intel, auch wenn Sie danach komplett verbrannt werden wie bei SuperMUC NG geschehen, der in Produktion erst weit nach 01/19 ankam, am Anfang extrem instabil lief und bis heute nicht die Leistung liefert welche bei der Anschaffung versprochen wurde.

Was hier effektiv gekauft wird ist ein (viel) kleinerer Klon von Aurora, i.e. eines der drei US-Exascale Systeme entstehend an den Argonne National Labs, da die meisten Europaeischen pre-Exascale (>100Pf) Maschinen bisher ueber AMD liefen wird Intel diese Maschine auch brauchen um mit Ihrer Vision fuer die naechsten Jahre im Europaeischen Markt relevant zu bleiben und daher werden dort entsprechend Nachlaesse gegeben worden sein.
Sorry. Das entging mir.
Aurora ist doch auch schon versemmelt. Vor knapp über 2 Jahren tauchte das Ding überall als die erste Exaflop Kiste die 2021 mit knapp über 1 Exaflop um die 60MW aus dem Kraftwerk saugen sollte. Das wird wohl nichts.

Es wird wohl 2x AMD mit Cray Shasta werden. 1.5 (!) Exaflops im Frontier und das diesjahr, bei 30MW peak. 1x leicht gemoddeter Zen3 mit 4x MI200 und Dualsockel mit dann 2x 4x MI200, und fertig.

Ende nächsten Jahres, in etwa, das gleiche mit 2 Exaflops im ElCapitan.
 
Aurora ist doch auch schon versemmelt. Vor knapp über 2 Jahren tauchte das Ding überall als die erste Exaflop Kiste die 2021 mit knapp über 1 Exaflop um die 60MW aus dem Kraftwerk saugen sollte. Das wird wohl nichts.

Es wird wohl 2x AMD mit Cray Shasta werden. 1.5 (!) Exaflops im Frontier und das diesjahr, bei 30MW peak. 1x leicht gemoddeter Zen3 mit 4x MI200 und Dualsockel mit dann 2x 4x MI200, und fertig.

60 MW hin, 60 MW her, die dortigen HPC Nutzer wollen glaube ich nur langsam endlich Mal eine neue Maschine haben nach so vielen Jahren der leeren Versprechungen von Seiten Intels haben... Ich moechte nicht wissen wie viele Forschungsprojekte deswegen in den Verzug geraten sind.

Frontier in Oak Ridge, El Capitan in Livermore, und Lumi in Finland sollten auf der x86 Host-CPU Seite schon fuer die naechsten 2-3 Jahre tonangebend sein.
 
Das Thema FP64-Exascale wird aber zunehmend auch unaufgeregter :) Die Zutaten wie das Kochrezept kennt man nun von spätestens Frontier und das Ergebnis ist gut einschätzbar. Jedenfalls wenn man nicht auf Intel setzt...

Man wird, für mich eher unerwartet, auch so langsam satt. Letztens hab ich noch ein Interview auf Englisch mit irgendeinem head of bei OAK erwischt der bisschen PR-Erklärbär machen musste, und der dann einen der Absätze in etwa mit dem O-Ton anfing: "Ok, was macht man nun mit einer nahezu unbegrenzten Rechenleitung. […]"
Na denn :) Wenn man Exascale gleich mit 1.5 Exaflops bei knapp unter 30MW anfängt, dann hat man vorerst wohl mehr als genug.

Und da liegt das alles auch nicht so brach wie auf dem x86-Desktop :cautious:
 
Zuletzt bearbeitet:
Ich frag mich ja was die auf den Ponte Veccio GPUs ohne vernünftiges Ökosystem rechnen wollen.

Das ist doch fast alles in CUDA geschrieben.
Nein, das ist meist nicht exklusiv der Fall. Klassicher HPC-Code wird in C, C++ oder Fortran geschrieben, und bei Bedarf mit MPI und/oder OpenMP parallelisiert. Wenn CUDA genutzt wird, wird meist der OpenMP Teil durch CUDA-Anteile ersetzt. Das geschieht meist aber so, dass man beide Codeanteile behält und je nach Bedarf den einen oder anderen nutzt. Sowohl Intel wie auch nVidia gehen mittlerweile den Weg, dass man nicht per direkt für CUDA oder Intels aktuelles Backend Software schreiben muss, sondern man verwendet etwas anderes. Das Was sprengt hier den Rahmen. Wen das interessiert sollte sich bei Intel bzw. nVidia durch die Doku durchlesen, es ist relativ umfangreich und es gibt nicht nur einen Weg das Ziel zu erreichen.

Bei den XeonPhis hat Intel diese per OpenMP genutzt, d.h. man konnte ganz normalen Code, den man ursprünglich für reine CPU-Cluster geschrieben hatte, auf einem XeonPhi Cluster ausführen. Für Intel Xe wird wohl ähnliches möglich sein.
 
Es gibt ein "Nvidia HPC SDK" ;) Von daher ist da schon bisschen was dran...

AMD löst das mit ROCm und kann damit auf theoretisch gleich schnellen GPUs Cuda-Code auch nur nach einer rein maschinellen Konvertierung oft gleich schneller fahren als NV selbst... Den aktuellen Featuresset von Cuda decken sie aber noch nicht ab. Vielleicht wollen/müssen sie das ja auch nicht zukünftig.

Die "Platform" heißt bei denen mein ich HIP und es gibt da auch schon Bestrebungen eine Art Frontends für klassiche Programmiersprachen zu machen (mal nach hipfort suchen). Auch für Fortran also.
 
Zuletzt bearbeitet:
Ich weiss nicht, ob ich mit dem Verweis auf die HPC SDK und ROCm so ganz d'accord bin. ROCm ist eher wie CUDA zu verstehen. @jdl trifft den Nagel schon recht gut auf den Kopf, dass man moderne Codes nicht mehr nativ in pur CUDA schreibt oder analog in ROCm, OpenCL, Metal und was es sonst noch so alles heutzutage gibt..

Vor allem die US Nationallabs pushen herstellerunabhaengige Backends wie Kokkos und Raja sehr stark. Zusaetzlich gibt es ja auch noch HPX von anderer Stelle. Die Codes gehen, analog zu den modernen Machine Learning Codes, den Weg das der Code in einer Sprache definiert aber durch Frameworks wie Kokkos, Raja, HPX etc. dann auf die Nutzungplattform mit CUDA, ROCm etc. kompiliert werden. Jede der Exascalemaschinen hat in etwa ein 200m USD Softwareentwicklungsbudget, was die Labore nicht verschwenden sondern moeglichst langfristig anlegen wollen.

Nur weil die erste Generation jetzt von AMD dominiert wird, heisst es nicht das die naechste Generation in 5 Jahren nicht theoretisch von NVIDIA kommen koennte und dann die ganzen Codes wieder von vorne angepasst werden muessten..
 
Problem: Es gibt bereits TONEN davon. 100fach validiert mit zufriedenstellender Skalierung. Die Konverter nach ROCm gibt es ja nicht, weil Papermaster mit Norrod und Naffziger beim gemeinsamen Zelten einen Budweiser zuviel hatten. Sonst widerspricht da ja nichts jdl.

Und Cuda bleibt noch weiterhin lebendig. Für FP64 wie oben erstmal mind. in Wiederverwertung, für KI wird sie noch eine ganze Weile auch frisch bleiben. Ich bin KEIN Grüner :) (an sich garkein Fanboy), aber da hat es eben und sonst laaaaange nichts gleich gutes gegeben.

Ich weiß aber grad auch nicht, ob wir nicht aneinander vorbei reden. Wenn LLNL das pusht, dann ist das nur zu begrüßen, aber sie das ist nciht die Rede von heute und Frontier wird sozusagen "heute" Exaflops liefern. Bis dahin sind sie mit dem Durchpushen noch nicht fertig.

Ich stelle aber auch gerne wohl noch einige Defizite bei mir was die "Strukturen" angeht. Für Cuda kann man schlecht was kompilieren. Man kompiliert für die GPU kernel libs. Was du beschreibst hört sich eher nach Reinterpretation von z.B. Fortran nach Cuda, damit Cuda das am Ende kompilieren kann. Da müsste man auch schauen wie das am Ende performt, gegenüber dem, wenn es direkt in Cuda geschrieben wäre.
Ich glaub ich hab noch paar Sachen zu lesen bis ich weiter mitquatschen kann :)

p.s.:
ROC und Cuda sind jedenfalls weniger das Problem. Mit ROCm ist quasi eine Interoperabilität gegeben. Xilinx wird man in ROCm mit aufnehmen. Da halt noch so Sachen wie A64FX oder WSE. Grad von Cerebras werden wir imho noch viel hören (falls sie wer nicht aufkauft).
 
Zuletzt bearbeitet:
(..) Ich weiß aber grad auch nicht, ob wir nicht aneinander vorbei reden. Wenn LLNL das pusht, dann ist das nur zu begrüßen, aber sie das ist nciht die Rede von heute und Frontier wird sozusagen "heute" Exaflops liefern. Bis dahin sind sie mit dem Durchpushen noch nicht fertig.

Ich stelle aber auch gerne wohl noch einige Defizite bei mir was die "Strukturen" angeht. Für Cuda kann man schlecht was kompilieren. Man kompiliert für die GPU kernel libs. Was du beschreibst hört sich eher nach Reinterpretation von z.B. Fortran nach Cuda, damit Cuda das am Ende kompilieren kann. Da müsste man auch schauen wie das am Ende performt, gegenüber dem, wenn es direkt in Cuda geschrieben wäre.
Ich glaub ich hab noch paar Sachen zu lesen bis ich weiter mitquatschen kann :)

p.s.:
ROC und Cuda sind jedenfalls weniger das Problem. Mit ROCm ist quasi eine Interoperabilität gegeben. Xilinx wird man in ROCm mit aufnehmen. Da halt noch so Sachen wie A64FX oder WSE. Grad von Cerebras werden wir imho noch viel hören (falls sie wer nicht aufkauft).

Ich glaube wir denken Beide das Gleiche aber druecken uns, vermutlich auf Grund der Bereiche aus denen wir kommen, anders aus.

Ich argumentiere weder fuer ROCm, noch CUDA, noch irgendeines der anderen Paradigmen. Wofuer ich argumentiere ist das Performance-portable Libraries wie Kokkos, Raja, HPX etc. das Backend von modernen Codes und den Codes der Zukunft repraesentieren welche dadurch selbst nicht direkt z.B. CUDA Code beinhalten aber auf CUDA-Kernels kompiliert werden koennen. Dadurch vermeidet man einen Vendor lock-in, behaelt sich aber die Performance vor. Ich weiss nicht direkt die exakte Nummer des Performanceverlustes, weil diese auch sehr spezifisch fuer die einzelnen Applikationen sein wird, wuerde aber tippen dass diese unter 5% liegen muesste.

Der neueste Schritt hierbei sind die neueren LLVM-basierten GPU Compiler wie Triton , Python ist hier nur eine Frontend-Wahl. Wenn man es direkt vergleicht ist NVPTX, i.e. das NVIDIA Backend von LLVM, merklich schneller als CUDA selbst.
 
Wer noch was zu SuperMUC-NG erfahren möchte:
Eine schöne Übung um Level3-durch die Blumen zu erkennen :sneaky: Weidendorfer hat auch keine Lust mehr auf den Mist, in einer Form wo er das aber plausibel klar verneinen kann 8-)

Wobei HPE die NUR Testplatform da imho auch schon ein knappes Jahr aufbaut...
 


Den neben Newton größten Universalgelehrten und Mathematiker in der Geschichte nicht zu kennen macht schon nen Deppen aus...

Außerdem ist er natürlich u.v.a. der Urvater des Computers!

Und Keks = Bahlsen und Hannover!
 
Zuletzt bearbeitet:
Zitat: "Mittel- bis langfristig sollen uns Hersteller nicht mehr nur als Kunden sehen, wir können und wollen neue Computertechnologie mitgestalten"

Der war gut.. :haha:

Das mag vielleicht der Anspruch sein, aber den kann man (wenn man sich in dem Bereicht bewegt und auch mit dem LRZ zu tun hat) einfach nicht ernst nehmen. Die muessen erst Mal ihr Haus auf Vordermann bringen und wieder kundenfreundlicher werden. In Deutschland ist da klar Juelich das Zentrum welches bei neuen Computertechnologien eher den Ton angeben wird.

(Das LRZ hat ja zum Beispiel nicht Mal die noetigen Stromleitungen um richtige Maschinen der pre-Exascale Aera beherbergen zu koennen - nicht dass man ihnen so was anvertrauen woellte)
 
Zitat: "Mittel- bis langfristig sollen uns Hersteller nicht mehr nur als Kunden sehen, wir können und wollen neue Computertechnologie mitgestalten"
Ich weiß nicht was du hast... Das ist jetzt die Hauptkompetenz am LRZ. Die Erfahrung die man mit der 0.3Alpha Version des SuperMUC-NG gesammelt hat, war die Entwicklung vor Ort zu begleiten. Fertig geliefert war es nicht und fertig abgeliefert ist es bis heute nicht.
Entwickeln während des Aufbaus, da hat jetzt kein RZ auch nur Ansatzweise soviel Erfahrung mit sowas als LRZ 😝

Man besinnt sich da nun auf seine Stärken 😅 Und will glaub ich bei der Entwicklung bzw. Testentwicklung von der EU-CPU (lach schlapp). Was wohl ein RISC-V sein wird. Alles halt nicht so nah am regulären RZ-Betrieb wie die anderen. Und die anderen haben auch keine Zeit dafür, weil sie halt arbeiten müssen...
 
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