High-Performance APU: 16 Zen Cores/32 Threads, Vega10(?)-GPU - 2017/2018

[fondness]

Ein interessanter Spekulationsthread betreffend zukünftiger AMD-Produkte fehlt noch, nämlich die offiziell für 2017 angekündigte High-Performance-Server-APU:

https://s16.postimg.org/6zrd9gc39/AMDdatacenter.png (https://postimg.org/image/8esxy6d69/)

Das AMD schon länger den Plan verfolgt, auch High-Performace-APUs zu produzieren, ist spätestens seit dieser Präsentation bekannt:

https://s13.postimg.org/5eerkzg13/814860d1427714492_amd_roadmaps_bis_2020_a_origin.jpg (https://postimg.org/image/ad29zijtv/)

https://s13.postimg.org/u6eds7x7r/3057759_0473820062_AMD_F.jpg (https://postimg.org/image/lbdjhp8f7/)


Basis der Spekulation sind nach wie vor die Leaks von Fudzilla:

https://s4.postimg.org/6nharvxot/84cbc506429ede06026d76e6de6651b2_XL.jpg (https://postimg.org/image/fii52emh5/)

https://s4.postimg.org/v59efs099/7e42c9447e754167c85105ffe1a1d866_XL.jpg (https://postimg.org/image/ma8k59bgp/)

[iuno]

Das AMD schon länger den Plan verfolgt, auch High-Performace-APUs zu produzieren, ist spätestens seit dieser Präsentation bekannt:

https://s13.postimg.org/5eerkzg13/814860d1427714492_amd_roadmaps_bis_2020_a_origin.jpg (https://postimg.org/image/ad29zijtv/)

Wobei man mit der Terminologie auch ein bisschen vorsichtig sein muss.
Damals haben sie auch das, woraus Kaveri/Carrizo geworden ist, mit "HPC" deklariert

http://cdn.wccftech.com/wp-content/uploads/2013/12/AMD-Opteron-APU-Roadmap.jpg

[AnarchX]

Multi TFLOPs SP/DP ist schon die HPC-Klasse. Was man damals auf der Roadmap meinte, weiß wohl nur AMD. Wenn man 4 Kaveri/Carrizon in einen 150W Blade-Node bekommen hätte, wäre das sicherlich auch eine Alternative gewesen. Aber bevorzugt werden wohl eher eine fette CPU (>12 Kerne) + eine High-End-GPU.

[Achill]

Wobei man mit der Terminologie auch ein bisschen vorsichtig sein muss.
Damals haben sie auch das, woraus Kaveri/Carrizo geworden ist, mit "HPC" deklariert

http://cdn.wccftech.com/wp-content/uploads/2013/12/AMD-Opteron-APU-Roadmap.jpg

Wenn mich mein Gedächtnis nicht täuscht, dann war das neue Feature bei Kaveri/Carrizo der HSA Support (https://en.wikipedia.org/wiki/Heterogeneous_System_Architecture) und dieser führt natürlich zu / ermöglicht / erleichtert HPC.

HPC selbst ist ja ein Moving-Target und immer vom Stand der Technik und den Zeitpunkt an dem man über HPC spricht, abhängig.

[Ailuros]

Es gibt schon in anderen fora relevante threads wo manche sogar so weit gehen und den Tod der dGPU fruehzeitig erkennen wollen. Dass zum dem Zeitpunkt wo diese APU erscheinen werden, schon alleine von der GPU nur Bruchteile einer HPC dGPU erreichen wird, will keiner einsehen.

Das eigentliche Ziel von diesem Projekt ist die lower end dGPUs fuer workstations und HPC zu ersetzen und natuerlich ist dann rein zufaellig auch praktisch auf diesem basierend Microsoft fuer einen semi custom SoC wie Scorpio zu fuettern.

[Skysnake]

Naja, tot werden die dGPUs nicht sein. Gibt ja durchaus Anwendungsfälle, bei denen man kaum Daten hin und her transferieren muss. Aber es gibt sehr viel mehr Fälle, bei denen das eben doch erforderlich ist.

Man muss halt schauen, was für einen passt. Ich hatte z.B. mir eine Funktion angeschaut, die war massiv schneller auf der GPU (>Faktor 100 im Vergleich zu ner Single Trad CPU Implementierung). Das Problem dabei war nur, das durch den Datentransfer am Ende die CPU-Implementierung auf 12 Threads gesehen schneller war/ist. Und daran wird sich auch nichts mit PCI-E 4.0 oder NVLink im großen und ganzen ändern. Die CPUs werden ja auch leistungsstärker. Und selbst wenn du am Ende mit der dGPU schneller bist, dann wirst du dennoch massig Performance brach liegen lassen.

Genau darauf zielen HPC SoCs ab (sollten Sie zumindest). Für HPC usw ist die Rechenleistung eines Chips nicht unbedingt entscheidend. Schau dir BlueGene/Q an. Das Ding hat Millionen von CPU-Cores, die ziemlich schwach sind. Nimmt man halt einfach mehr Chips. MPI muss man ja eh verwenden, also shit drauf.

Am Ende läuft das wieder auf Small vs Fat Node/Core hinaus, und wenn man sich die jüngere Vergangenheit anschaut, dann sind die Small Nodes/Cores nicht schlecht gefahren.

Die Frage ist halt, ob man damit wirklich am Ende High-End Gamer erreichen kann. Recht lange habe ich gedacht ja, aber mit Fiji bin ich mir da unsicherer geworden, bzw. meine Einschätzung war da zu optimistisch. In dem Bereich wird es wohl noch lange dGPUs geben, einfach weil Sie die bessere Wahl sind für DIESEN! Einsatzzweck.

Bei Compute muss man es sich anschauen. Am Ende wird es wohl recht lange beides geben, und es auch eher eine Frage sein, ob sich die Parallelentwicklung von dGPUs rentiert auf Dauer. Aber auch umgekehrt. So lange man keinen Markt für High-Performance SoCs sieht, werden die halt nicht kommen.

Intel grast so lange halt die Möglichkeiten ab, und wir sollten uns nichts vormachen. Intel wird sich die Kritik an ihrem Design anschauen. Mit KNH wirds noch geine unterschiedlichen Cores geben, aber danach würde ich meine Hand nicht mehr dafür ins Feuer legen...

Intel hat halt den Vorteil, dass das Zeug erstmal einfach läuft, und so lange man bei den APUs zwingend OpenCL braucht und nicht einfach in C/C++, FORTRAN oder von mir aus auch Python das Zeug hinrotzen kann, so lange werden die einen schweren Stand haben. Wenn werden die Chinesen so etwas einfach verwenden. Die sind da viel flexibler und hocken nicht so sehr auf irgendwelcher Legacy Software...

[|MatMan|]

Der Erfolg einer high performance APU hängt meiner Meinung nach stark an AMDs Software Bemühungen. Zur Veröffentlichung der APU müssen die HSA Unterstützung und die dazugehörigen SDKs dafür vollständig sein. Man braucht ein Killer-Beispiel, wo die Vorteile einer solchen APU im Vergleich CPU + dGPU sichtbar sind. Analog zu dem deep learning Zeug zur GP100 Vorstellung. Egal ob die Leute deshalb wirklich GP100 kaufen, aber es gibt eine funktionierende Lösung für ein spezielles Problem und nicht nur theoretische Zahlen. Solch eine HPC Anwendung (oder was auch immer) wird sich doch für eine high performance APU finden lassen. Ich meine nicht diesen Excel Quatsch, den sie mal als HSA Anwendung gezeigt haben, sondern etwas wofür es auch einen Markt gibt!

[Skysnake]

Ich schau mir ja Beruflich den ganzen Tag HPC Applikationen an und schau wie man Sie schneller machen könnte. Da sind schon immer wieder welche dabei, wo ich mir denke, dass da eine APU wohl ganz gut passen würde.

Das Problem dabei ist dann aber, dass das Zeug dann entweder in FORTRAN oder eben NICHT in C++11 sondern irgend einem älteren C++ Standard geschrieben sind, wo man OpenMP als Threading-Modell benutzt. HSA muss mit OpenMP zusammen arbeiten, sonst wird das nichts udn zwar wie gesagt in C UND! FORTRAN. Es ist echt erschreckend, wie viel Software noch auf FORTRAN setzt. Ergo so lange das nicht supported wird, ist das Konzept in dem Bereich tot...

[|MatMan|]

Ja das ist genau der Punkt. Es braucht zum Launch einen funktionierenden Software-Stack, nicht erst angekündigt für ein Jahr später oder so. Man kann sich ja erstmal auf C / C++ beschränken.
Wenn du selbst einige Beispiele kennst, wo eine APU helfen könnte, wird AMD doch wohl auch Kontakte zu Anwendern haben, wo der APU-Einsatz richtig durchschlägt und kann mit etwas Manpower eine optimierte Software entwickeln. Eine generische Bibliothek wie das deep learning Zeug wäre natürlich besser...
Notfalls würde es auch eine optimierte BOINC App tun (Seti@Home oder Einstein oder so), aber das ist nicht wirklich professionell und eher was für den Consumer Markt...

[Skysnake]

Naja, Einstein@home schlägt in diese Kerbe, und das wird auf durchaus großen Clustern mit >100 Knoten laufen gelassen. Aber das wären die FALSCHEN! Anwendungen. Von der Art der Probleme sind das eher Probleme, die auch gut auf einer dGPU laufen. Zumindest erwarte ich da keinen sonderlichen Vorteil mit iGPUs im Allgemeinen.

APUs mit HSA haben insbesondere da eine chance auf signifikante Vorteile, wenns um Strong-Scaling geht. Bzw. Wenn man eben einfach recht feingranulare Probleme hat, wo man nur einige ms rechnet zwischen synchs.

Wegen 10% Leistungsvorteil lockste niemanden hinterm Ofen vor.

[|MatMan|]

Ja die Einstein@Home GPU Apps laufen schon ziemlich gut. Es gibt aber nicht für alles dort eine GPU App, vielleicht weil es wegen zu viel CPU - GPU Kommunikation aktuell noch nicht skalieren würde. Mir ging es gar nicht speziell um Seti oder Einstein, die waren nur als Beispiele für aktiv entwickelte GPU Apps gedacht. Ja man braucht durchschlagende Anwendungen (eben nicht nur 10%), die fallen halt nicht von allein vom Himmel, wenn man nur zeigt wie toll die Hardware ist...

[Skysnake]

Das Problem mit OpenCL/CUDA ist halt, das man oft schon ziemlich große Teile auf die GPU portieren muss, da zwar einzelne Funktionen leicht viel schneller sind, aber sobald man die Zeit fürs Daten hin und her schieben berücksichtigt, man kaum noch einen Geschwindigkeitsvorteil hat.

Bei dem Beispiel was ich mir z.B. vor einer Weile angeschaut habe, hätte ich >20 Funktionen neu schreiben müssen, wobei jede Funktion so 100 Zeilen Code waren, damit das realistisch gesehen wirklich was bringt... Das ist ein Projekt, wo du mal locker ein Mannjahr hättest rechnen können, bis es läuft. Die Zeit muss dir erstmal jemand geben...

[iuno]

Design and Analysis of an APU for Exascale Computing
http://www.computermachines.org/joe/publications/pdfs/hpca2017_exascale_apu.pdf

[deekey777]

Design and Analysis of an APU for Exascale Computing
http://www.computermachines.org/joe/publications/pdfs/hpca2017_exascale_apu.pdf

Vorgekaut und ausgespuckt: https://www.heise.de/newsticker/meldung/AMD-Entwickler-beschreiben-CPU-GPU-Kombi-fuer-Supercomputer-3632974.html

[AffenJack]

Die Gpu Chiplets passen auch gut in den Navi Spekuthread, denn ich glaube das genau das mit der Scalability da gemeint ist.