News AMD: Exascale-Vision mit 32 Kernen, GPU und Stacked DRAM

Parallelisierung ist schwer zu programmieren scheint. Und nicht alles lässt sich auf GPUs gut berechnen.

Besser gefällt mir das Konzept wo die CPU zwar mehrere Kerne besitzt aber nach außen hin nur als 1Kerner erscheint.

Nur mit dem Takt hapert es noch. Wenn mir jetzt noch einfiele wie die Architektur heißt .....
 
Steeeep schrieb:
Naja doch nur mit dem unterschied das Intel von Anfang an die GPGPU relevanten Vektoreinheiten gleich in den x86er Kern einbaut und somit den ganzen einschränkenden Grafikkartenursprung weglassen kann...

Ich lese grad Knights Landing wird sogar bis zu 16GB On Package Stacked RAM (mit 500GB/sec) haben und für die gesockelte Variante noch zusätzlich 6 Kanal DDR4 Speicherinterface. 2015 ist release also wenn dann AMD endlich mal was produziert wird Intel schon lange auf dem Markt sein.

Zuallererst, soll Knights Landing wenn überhaupt Ende des Jahres kommen und das ist HMC abhängig.
Der HBM Speicher wird als L3 Cache angebunden (Dieser besteht aus einem Installation Cache und einem HBM Speicher). Auch die APU hat einen DDR4 Bit Si, das aber nur mit 4 Channel also 256 Bit.
Weiteres kommen von AMD und NV auch noch 32GB HBM GPGPU Beschleuniger Karten und das in 16-14nm Finfet. Somit entfällt für Intel hier zum ersten mal der Fertigungsvorteil, denn sie bei den Vorgänger bisher hatten. Auch zieht NV ebenso nach mit NV-Link und Unified Virtual Memory.

Was Xeon Phi angeht. Der verwendet FPUs der Cores (die sind pro Core falls ich mich richtig erinnere mehrmals vorhanden) und der Vorteil ist, dass man einfacher Programmieren kann und es nur einen Arbeitsspeicher gibt, denn man verwalten muss. Bei den bisherigen GPGPU GPUs war ja das Problem, dass Daten herumkopiert werden musst (Arbeitsspeicher <=> Grafikkartenspeicher). Das hier ist aber eine HSA APU. Gut zugegeben, ich bin kein Experte, aber wo ist der Vorteil von Xeon Phi, wenn eine Anwendung nicht parallel abarbeiten lässt gegenüber eine HSA APU ? Denn hier ist nun mal jetzt auch ein CPU Core vorhanden und die CPU Cores und GPU Cores haben den selben Adressraum.
Die Konzepte sind also sehr ähnlich. Cores für Serial Aufgaben und Parallel Aufgaben. Nur wird bei Xeon Phi für das eine Integer Cores und für das andere die FPUs genützt. Bei AMD ist es ein Zen Core und GCN Stream Cores. Deshalb heißen die Dinger bei den aktuellen APUs auch Compute Cores.
http://www.tomshardware.com/reviews/a10-7850k-a8-7600-kaveri,3725-2.html
cores-treated-equally.jpg

By definition, a Compute Core is HSA-enabled, programmable, and capable of running at least one process in its own context and virtual memory space, independent of other cores.

nitnoS
VISC stimmt zwar, aber für was das V in Wirklichkeit steht, wurde nie wirklich erwähnt. Es wird nur angenommen dass das V für Virtual steht. (Auch wenn es sehr nachvollziehbar ist, eben wegen dem Front-End ect)
 
Zuletzt bearbeitet:
pipip schrieb:
Was Xeon Phi angeht. Der verwendet FPUs der Cores (die sind pro Core falls ich mich richtig erinnere mehrmals vorhanden) und der Vorteil ist, dass man einfacher Programmieren kann und es nur einen Arbeitsspeicher gibt, denn man verwalten muss.
Nein, die Karten haben eigenes RAM, der Vorteil des Xeon Phi ist, dass es x86er Kerne sind, die also den gleichen Befehlssatz haben wie die CPU auch und damit einen weitaus umfassenderen Befehlssatz als eine GPU ihn bietet.

pipip schrieb:
Bei den bisherigen GPGPU GPUs war ja das Problem, dass Daten herumkopiert werden musst (Arbeitsspeicher <=> Grafikkartenspeicher). Das hier ist aber eine HSA APU.
Der Ansatz der APUs ist je genau das zu vermeiden und damit auch die Auslagerung kleinere Aufgaben an die GPU Kerne zu ermöglichen, deren Abarbeitung auf der GPU sich sonst eben wegen der Zeit die beim Kopieren verloren geht nicht lohnt.
pipip schrieb:
Gut zugegeben, ich bin kein Experte, aber wo ist der Vorteil von Xeon Phi, wenn eine Anwendung nicht parallel abarbeiten lässt gegenüber eine HSA APU ?
Wenn eine Aufgabe nicht parallel bearbeitet werden kann, gehört sie nicht auf einen XeonPhi oder eine APU, sondern auf einen CPU Kern mit möglichst hoher IPC und hohem Takt, daher ja auch die Turbo-Technologie der modernen CPUs, die dann den Takt bei Auslastung nur einer Kerns möglichst weit anheben.


Mich würde mal interessieren was für Kerne das sein sollen und wie AMD die zählt, denn beim Bulldozer wurde ja ein Modul als 2 Kerne gezählt, bei Zen ist aber von SMT die Rede, also was Intel als HT bezeichnet und da zählt Intel pro Kern auch nur einen Kern aber zwei Threads. Wenn AMD dann auch 2 Kerne statt einem mit 2 Threads zählt und so wie sie da zuletzt kreativ die GPU Kerne mit reingezählt haben wäre das auch nicht verwunderlich, dann wäre es ein 16 Kerner und bei Intel gibt es sogar schon 18 Kerner. Statt deren massiven L3 Cache werden dann eben eine unbestimmte Anzahl GPU Kerne verbaut und das Stacked DRAM ersetzt den L3. Das wäre auch für Intel machbar, die Broadwell haben ja auch eDRAM welches als Cache für GPU und CPU gleichermassen funktioniert und ohne oder mit wenig L3 wäre auch Platz genug auf dem Die, zumal die 18 Kerne bei Haswells in 22nm vorhanden sind, Broadwells oder Skylakes aber mit 14nm noch mal kompakter sind.
 
Holt

Der Ansatz der APUs ist je genau das zu vermeiden
habe ich was anders gesagt ? Ich sage ja, es ist eine HSA APU. Das heißt kein kopieren. Und was den Turbo angeht, wieso soll das bei der APU nicht möglich sein ?

Es wurde von "zukünftigen" Architektur gesprochen. Somit kannst du mit Zen und K12 Core Varianten erwarten. Bei Zen Folie wurde bisher auch von einem Core + Hyperthreading gesprochen. Somit 32 Cores mit 64 Threads.
Wenn das nicht der Fall ist, dann wäre der kommende Zen FX mit 8 Cores dann ein Quadcore mit Hyperthreading.

Wenn AMD dann auch 2 Kerne statt einem mit 2 Threads zählt
Bei Bulldozer waren aber 2 integer Cores vorhanden auch wenn CMT eine form von Hyperthreading ist.
Aber AMD spricht doch auf ihrerer eigenen Präsentation über Zen von einem Core plus Hyperthreading.
Desweiteren wird von 2016-2017 gesprochen. Zufällig die Zeit wo Raven Ridge auf AM4 kommen sollen.

und das Stacked DRAM ersetzt den L3
Laut AMD Patent ist im HBM Controller ein SRAM verbaut.
http://www.google.com/patents/US20130346695
US20130346695A1-20131226-D00000.png


L3Cache (SRAM) and Memory Controller.

Diese Einheit erlaubt die Kommunikation mit den HBM + Main Memory Controller für den DDR4 RAM.
 
Zuletzt bearbeitet:
Oromis schrieb:
Dann hätte man drei Stufen:
- Der Teil ganz nicht parallelisierbare, aber wichtige Aufgaben: Die 2 ~4Ghz Kerne
- Nicht oder wenig parallelisierbar, aber braucht nicht die volle Geschwindigkeit: Die anderen Kerne bei den Serverüblichen 2-3 Ghz
- Voll parallelisierbar: Die Grafikeinheit

Fehlt da nicht was in der Aufzählung? Viele sehen die Grafikeinheit als eine Abarbeitsungseinheit für Daten, d.h. derselbe Code wird gleichzeitig durch alle Shader abgearbeitet. Bei einer Grafikberechnung ist das auch sinnvoll. Allerdings gibt es neben der datenparallelen Abarbeitung auch noch die Taskparallele. Mir scheint, dass das gerne vergessen wird. Selbst OpenCL kann das seit den frühen Versionen, d.h. man kann mehrere Kernel parallel abarbeiten (lassen). Weiterhin kann man schon lange OpenGL zusammen mit OpenCL laufen lassen (Context bzw. Datensharing, sodass Compute-Ergebnisse nicht erst über den Bus zur CPU/Memory kopiert werden müssen und dann wieder auf die Graka geschoben, um das Computing anzustoßen). Und letztlich zieht nun die Low-Level API DirectX12 hier nach, indem 3 Queues zur Abarbeitung auf einer GPU unterstützt werden, wovon nur eine die Grafikbefehle verarbeitet. Eine weitere kümmert sich um Mem-Copy-Aktionen und eine schließlich um reines Computing.


Simon schrieb:
Einfach nur Ausführungseinheiten aneinanderklatschen wird nicht allein ausreichen, um ein brauchbares ExaScale-System aufzubauen. Und nein, auch der fünfzigste Aufguss von 28 nm bei Global Foundrys wird sich dafür vermutlich eher nicht eignen...

Rebrand bestehender Produkte mit bestehender (äh... etablierter) Foundry-Prozesstechnologie :D
 
pipip schrieb:
Und was den Turbo angeht, wieso soll das bei der APU nicht möglich sein ?
Nein, oder habe ich was anders gesagt? Nur ob CPU oder APU, das ist der Weg zur SingleThread Performance und da eben nicht alle Probleme und Algorithmen parallelisierbar sind und noch nicht alle die es sind auch schon parallelisiert wurden, ist die SingleThread Performance weiterhin sehr wichtig.

pipip schrieb:
Wenn das nicht der Fall ist, dann wäre der kommende Zen FX mit 8 Cores dann ein Quadcore mit Hyperthreading.
Wir werden sehen, leider ist mir AMD zuletzt etwas zu krativ beim Zählen von Kernen in seine APUs, als dass ich blind darauf vertrauen würde das es nicht so wird.

pipip schrieb:
Laut AMD Patent ist im HBM Controller ein SRAM verbaut.
Das wird man schon alleine für die Verwaltungsdaten des Caches brauchen, man muss ja wissen welche Speicherbereiche dort drin gecacht sind. Bei der Größe sind das auch nicht so wenige Verwaltungsdaten, da macht ein SRAM um die zu speichern schon Sinn, denn die Information muss man ja möglichst schnell haben.
 
pipip schrieb:
Interessant ist doch, wie der Chip aufgebaut ist. Ist es ein Die, oder eher, kommt es eher dem Konzept nahe, das AMD für die Zukunft geplant hat. CPU, GPU ect Module die auf einem Interposer kombiniert wird.
Kann gut sein dass es 8 CPU Module (jeweils 4 Cores) 1 GPU Modul (Typ Greenland) und 4 HBM Stacks (mit HBM 2.0 sollten das 32 GB HBM sein).
1 Die sicher nicht, das wird viel zu riesig. Aber so kleinteilig wie du es malst wirds sicher auch nicht, das ist ja völlig ineffektiv. 4 Cores nehmen in 14 nm kaum Platz ein. Und riesige Mengen L3-Cache braucht man nicht mit HBM. Ohne I/O und GPU bekommst du wahrscheinlich 8 Kerne auf ~150 mm².
 
Zuletzt bearbeitet:
Ich verstehe immer noch nicht, warum nicht große Teile des OS-Schedulers schon in die Hardware integriert werden. Damit könnte man doch super die Arbeit zwischen GPU und CPU verteilen oder? Natürlich nicht die passenden Schritte.
 
bensen
Holt hatte kurz nach mir eh geschrieben, wenn dann 4 mal 8Cores. Was interessant ist, besteht dann so ein Core Modul auf jenen Die der auch für den kommenden FX verwendet wird ? Laut PCGH hat AMD auch mit CPU only + GPU Varianten experimentiert. Vorteile sollen sich aber für die APU Variante ergeben haben.
Kann aber gut sein dass kommende Server Varianten vllt bereits auf Interposer mit 16-32 Cores handeln könnte.
 
Folien.... könnte.... Zukunft....

Dass die noch die Ressourcen haben sich auf solche Folien statt ernsthaft auf einen neuen Kern und einen echten neuen Prozess (14nm) zu konzentrieren....

So macht man sich unglaubwürdig....

AMD verliert gnadenlos überall den Anschluss, außer in Folien zaubern....

Powerpoint muss wohl deren liebstes Tool sein....
 
yummycandy schrieb:
Ich verstehe immer noch nicht, warum nicht große Teile des OS-Schedulers schon in die Hardware integriert werden. Damit könnte man doch super die Arbeit zwischen GPU und CPU verteilen oder? Natürlich nicht die passenden Schritte.

Das ist vermutlich eben ein Tradeoff, schließlich soll direkt in Hardware realisierte Funktionalität sehr generisch sein und solch ein Scheduler, wie von Dir vorgeschlagen, fällt schon komplexer aus (und den wünscht sich vermutlich auch jedes BS anders parametrisiert... Scheduling-Verfahren, Warteschlangen, ...).

Hatte Apple nicht hier mal eine Abstraktion geschaffen? Das Ding hieß Grand Central Dispatch und konnte abstrakt definierte Code-Snippets auf die Kerne (CPU / GPU) zur Ausführung bringen.
 
PropagandaWars

2016 wird eine neue Core-Architektur mit den Namen ZEN in 14 nm Finfet GF (Samsung lizenziert) auf den Markt kommen. 8 Cores 16 Threads 95 Watt für den Desktop. Also früher als diese HPC APU.
 
HOT schrieb:
1x Greenland + 4 8-Kern-Zen-Module + 32GB HBM2 auf einem Interposer.

wenn amd bis dahin durchhält, wirst du sowas in 2017 sehen können.
 
Wenn AMD bis dahin durchhält? Sieh es doch anders: Irgendeine Firma wird den ZEN schon bringen :D Und wenn nicht AMD oder Samsung, dann schlägt vielleicht Apple zu?
 
AMINDIA schrieb:
Aktuell sucht man noch die Gravitationswellen. Trotzdem werden auch diese nicht schneller als Licht sein. Selbst mit Lichtgeschwindigkeit ist dieser vor kurzen bekannte erdänliche Planet 1400 Jahre entfernt. Aktuell könnten wir es in ca 140 Millionen Jahre schaffen wenn das Raumschiff 100000 km/h fliegt.
Das was wir von diesen Planet jetzt wissen ist also wie es vor 1400 Jahren war. Wenn es also dort Leben geben würde und dieses sich zeitgleich mit unserem entwickeln würde, könnten wir dies erst in ca 1300 Jahren erfahren. Radiowellen sind auch nur so schnell wie Licht.

Man braucht ja auch nicht schnell als das Licht reisen, um mehr Wegstrecke als das Licht in einer Zeiteinheit zurückzulegen. Es gibt ja bereits ein paar Ideen, wie man dies mittels raumkrümmung anstellen könnte. Man kürz sich den weg quasi ab. Mit Normaler geschwindigkeit durch einen gekrümmten Raum kann durchaus wesentlich schneller sein, als normal mit Lichtgeschwindigkeit zu reisen.

Allerdings sollte dies wenn überhaupt nicht in absehbarer Zeit möglich sein, vorher haben wir ExaScale-Cluster in Smartwatchformat ^^
 
Zurück
Oben