News AMDs 64-Bit-ARM-Server-Prozessor ab März als Sample

[Felixxz21]

Im Prinzip muss man dann eher Silvermont dagegen stellen bzw. der Avoton 8Kern bei 20W (deutlich weniger real). Intel hat mit X86 teils ARM schon getoppt bezüglich Effizienz. Geht ein 50+ Kern Knights Landing nicht in dieselbe Richtung, aber noch kompakter? Viele Kerne und Fokus auf max Perf/W bei hochparalleln Aufgaben.

ARM Server CPUs sind nicht für hochparalleles Numbercrunching wie MIC sonder für einfache Aufgaben wie Cloud, Webhosting etc. wo es auf maximale Effizienz ankommt. Also grob für viele Webanwendungen.

 

[Krautmaster]

Deswegen gilt Intels Phi ja auch als extrem flexibel da es ja nicht wie ne klassische GPU angesehen werden kann sondern ne gute Mischung aus beiden Welten bietet.

GPU entwickeln sich ja auch zu immer aufgeblaseneren, universelleren Recheneinheiten die weniger rein zum Crunchen gut sind. Aber nun gut, ich bin kein Experte aber ein guter Forumuser hat hier mal ne Serie perfekte Posts abgelassen die sehr aufschlussreich waren.

 

[Simon]

Knights Landing ist tatsächlich eher als Beschleunigerkarte für Supercomputer und Workstations gedacht.
Die Opteron A bzw. X-Series oder auch die Atom C2000 sind eher für CDNs (Content Delivery Networks) in Form von Mikro-Servern konzipert.

Aber Krautmaster hat schon recht. Die Avoton-SoC sind schon die direkten Gegner gegen die Opteron A-Serie und sind bereits erhältlich. Erschwerend kommt hinzu, dass Intel vermutlich noch im 4. Quartal die ersten 14-nm-Atoms auf Airmont-Basis sampled oder gar shipped, während AMD hier noch mit 28 nm spielt.

 

[Krautmaster]

ich rufe mal diesen guten Kommentar in die Erinnerung

Mal etwas ausführlicher, inhaltliche Kritik oder Fragen nach ausführlicheren Erklärungen sind willkommen. Es war etwas problematisch das ganze inhaltlich "aufzurollen", da alles mit allem irgendwie zusammenhängt. Ich hoffe es ist mir dennoch halbwegs gut gelungen:

-Höherer Prallelismus, breiteres/anderes Hardware-Multithreading: Moderne GPUs benötigen je nach Anwendungsfall wegen ihrem Hardware-Multithreading mehrere 1000 Threads um gut ausgelastet zu sein (Titan kann maximal 29 000 Threads gleichzeitig bearbeiten, bei modernen AMD-Karten sind es 60k+ ), während Phi wenige 100 benötigt (Phi kann denke ich nur bis zu 300 Threads gleichzeitig bearbeiten). In den meisten Anwendungsgebieten ist der Parallelismus nicht aus dem Grund schädlich, weil man das Problem nicht genügend parallelisieren könnte, sondern aus anderen Gründen:
So benötigt man auf einer GPU wesentlich mehr Speicherplatz für die temporären Zwischenergebnisse aller Threads als auf einem PHI. Passt der Workingset der Zwischenergebnisse eines jeden Threads (auch die automatischen Variablen genannt) nicht mehr in die Register, müssen sie in in die Caches und den DRAM ausgelagert werden, was wiederum brutal Performance kostet. Dies wird als Register-Spilling bezeichnet. So kann man auf einer Titan beispielhaft schon mit Performanceeinbussen rechnen, wenn ein Thread mehr als 31 Zwischenergebnisse gleichzeitig zwischenspeichern muss. Des Weiteren führen mehr Threads unabhängig von Registerspilling auch zu chaotischeren globalen Speicherzugriffen (global = sämtlicher Speicher was sich alle Threads der GPU teilen wie Texturen, Vertexdaten, Hierarische Datenstrukturen), was wiederum der Cache-Effizienz schadet und brutal DRAM-Bandbreite kostet. Erschwerend kommt hinzu dass die GPU nur einen sehr kleinen L2-Cache besitzt (1.5 MB beim Titan), während der PHI einen sehr großen L2-Cache besitzt (Kernzahl* 2MB). Dadurch kann ein Algorithmus mit einem großen Working-Set für automatische und globale Variablen nicht mehr effizient auf einer GPU arbeiten. Meist kann man das zwar hinfriggeln, dass es irgendwie doch passabel oder eventuell sogar gut auf einer GPU funktioniert, was aber sehr viel Arbeit ist.
Allerdings ist diese Art des Hardware-Multithreading der GPU auch fallabhängig von Vorteil. Denn der Grund dafür, dass man ein Hardware-Multithreading einbaut ist immer der, dass man dadurch Latenzen besser überbrücken kann und die unterschiedlichen (Rechen-)Ressourcen besser auslasten kann. Dies kann eine GPU wegen dem breiteren Multithreading dementsprechend auch besser als ein Xeon-Phi.


-SIMD: Ein Warp ist eine Gruppe von N Threads auf der GPU (N = 32 bei NVIDIA, 64 bei AMD). Eine GPU führt jeden Takt jeweils die nächste Instruktion eines Warps aus, wodurch ein und der selbe Befehl jeweils auf den unterschiedlichen Daten eines jeden Warpthreads ausgeführt wird (Single Instruction Multiple Data). Wollen mehrere Threads eines Warps wegen einem Sprungbefehl nicht an einem Befehl teilnehmen, so bleiben in diesem Fall die entsprechenden Rechenkerne unbenutzt und es geht Rechenleistung verloren. Dadurch reagieren GPUs sehr empfindlich auf Algorithmen mit chaotischen Sprungbefehlen. In den meisten Fällen kann man zwar die Sprungbefehle GPU-freundlich optimieren, was allerdings wiederum ein großes Gefriggel ist. Xeon-Phi besitzt ebenfalls SIMD-Instruktionen (eine Instruktion auf 16 SP-Werte gleichzeitig), jedoch beziehen sie sich auf die Daten eines einzelnen Threads. Hier muss man zwar den Quelltext auch etwas umgestalten, dass der Compiler diese SIMD-Instruktionen verwenden kann und Sprungbefehle können sich ebenfalls per Active-Mask, welche beschreibt welche der Daten überhaupt am SIMD-Befehl teilnehmen, negativ auf die Performance auswirken, aber afaik fallen die nachteiligen Auswirkungen von Sprungbefehlen auf die Performance wesentlich geringer als bei GPUs aus.


-Shared Memory: GPUs haben einen kleinen Scratch-Pad-Speicher auf dem DIE (ähnlich zu dem eDRAM auf den Konsolen). Diesen kann man nach belieben befüllen und auslesen, und dadurch die zu kleinen Caches etwas kompensieren. Allerdings ist es in den meisten Fällen ein großes Gefriggel den zu verwenden.

-Besondere Caches auf der GPU: GPUs haben besondere Read-Only-Caches (Texture-Cache, Konstanten-Cache), deren dazugehörige Daten während der gesamten Programmausführung nicht verändern dürfen. Diese Caches muss man explizit und "richtig" verwenden, was einen Mehraufwand bei der Programmierung bedeutet, jedoch aus Performancegründen wesentlich ist. Gleichzeitig muss man dafür sorgen, dass sich die Daten nicht verändern, was die Programmierbarkeit einschränkt.


-Vielzahl von Hardwarelimitierungen: Eine GPU besitzt für viele Aufgaben Spezialhardware. Verwendet man diese, was wiederum in den meisten Fällen empfehlenswert ist, so muss man die dazugehörigen Hardware-Limitierungen in Kauf nehmen. Stören diese Limitierungen bzw. stößt man an deren Grenzen so muss man *irgendwie* beim Programmieren darauf eingehen.


-Occupancy: Während bei dem Hardware-Multithreading auf Prozessoren jeder Thread seinen eigenen Registersatz hat (also bei 4 Fach bei einem PHI-Kern) teilen sich die Threads eines Multiprozessors auf der GPU einen Registersatz. Je mehr Register ein Thread auf der GPU benötigt, desto weniger Threads passen in einem Multiprozessor bzw. desto weniger Threads kann die GPU gleichzeitig bearbeiten. Wie bereits erwähnt, will man jedoch meist möglichst viele Threads gleichzeitig aktiv haben, um die Latenzen überbrücken zu können und die GPU gut auszulasten. So ist es in den meisten Fällein ein großes Gefriggel die Occupancy gut hinzubekommen. Auf einem PHI existiert das Konzept der Occupancy und die daraus resultierenden Probleme nicht.

-Keine Interrupts auf GPUs in Kombination mit Hardware-Scheduling: Ein Thread rechnet auf einer GPU so lange bis er terminiert; terminiert er nicht so rechnet er ewig (oder bis Windows den Displaytreiber zurücksetzt). Er kann sich auch nicht schlafen legen, die Kontrolle an einen anderen Thread abgeben, um auf ein bestimmtes Ereignis zu warten. Wenn er dennoch auf ein Ereignis warten muss, so muss er aktiv ständig die Bedingung abfragen, was Rechenleistung verschwendet. Diverse Anwendungen (wie Betriebssysteme) setzen auch voraus, dass man einen Thread per Interrupt unterbrechen kann. Diese Anwendungen sind auf der GPU ebenfalls nicht verwirklichbar. Auf einem PHI stellen sich wegen Interrupts diese Probleme nicht.

-x86 Architektur: Gerade bei kleineren Rechenaufgaben mit größerer und älterer x86-Code-Base mag es keinen Sinn machen sich einen Programmierer einzustellen, der das in mühevoller kleinarbeit auf die GPU portiert. Da mag es sehr vorteilhaft sein, sich einfach einen PHI zu kaufen und auf diesen den x86 Code direkt ausführen zu können.

Machst du es dir da nicht etwas zu einfach indem du sagst, dass sie da und da eine bessere Performance erzielt haben ist eine GPU-Lösung allgemein besser? Wenn ich mich für etwas entscheiden würde, würde ich folgende Punkte abarbeiten:

-Wie performant laufen die Algorithmen auf GPUs und wie performant auf CPUs (PHIs)? Generell gilt, dass komplexere Algorithmen weniger GPU und mehr CPU freundlich sind, während einfachere Algorithmen eher GPU freundlich sind.

-Worauf läuft die vorhandene Code-Base? Ist der Code bereits parallel in x86 vorhanden würde ich eher auf den PHI setzen, ist er nur parallel in CUDA/OpenCL vorhanden, was vermutlich der weitaus seltenere Fall sein wird, würde ich eher auf GPUs setzen.

-Wie viel Zeit und Geld kann man für das Portieren der vorhanden Code-Base aufbringen? Bei viel Zeit und Geld kann man sich die Hardware nach den anderen Gesichtspunkten aussuchen, bei wenig Zeit und Geld ist man auf die Hardware angewiesen, deren Code-Base man besitzt.


-Worauf laufen die Anwendungen, bei welchen man keinen Quellcode hat? Unterstützen die Anwendungen nur x86 dann kann man nur auf den PHI setzen (oder sie selbst neu schreiben!), während wenn die Anwendungen nur CUDA können, muss man auf CUDA setzen.

-Wie viel Zeit und Geld kann man für das Optimieren aufbringen? Bei viel Geld und Zeit würde ich eher auf GPUs setzen, während ich bei weniger Zeit und weniger Geld auf CPUs setzen würde, da bei GPUs im Allgemeinen mehr Optimierungsbedarf besteht.

-Wie teuer sind die Anschaffungskosten der Hardware und die Betriebskosten im Bezug auf die Performance?

-Willst du auf den Rechnern auch eine rechenintensive graphische Ausgabe (CAD, 3D-Design) haben? Wenn ja, dann würde ich auf GPUs setzen, da sie die graphische Ausgabe auch berechnen können.

All diese Gesichtspunkte kann man kombinieren um eine Kosten/Nutzen/Zeit Rechnung zu machen und das ganze mal z.T. durchzurechnen oder auch durchzuschätzen und dann gegebenenfalls abzuwägen.

Man könnte die Argumentation ja kritisieren und sagen die Entwicklungskosten, Potierungskoten und Optimierungskosten für den Quellcode sind irrelevant gegenüber den Hardwarekosten und den Stromkosten. Wenn man aber bedenkt, dass ein Programmierer einen Arbeitgeber wohl ca 4000-7000 € pro Monat kosten wird und bei der Portierung/Optimierung des Quelltexts sicherlich ein paar Personenmonate benötigt werden, so kommt sehr schnell ein Betrag von 100 000 € zusammen. Davon kann man sich bereits wieder recht viele Karten (PHIs, GPUs) kaufen, weshalb das Optimieren und Portieren gerade bei kleineren Clustern absolut unlohnenswert ist.

wie gesagt - ich bin da nicht so tief drin wie er, aber die 72 Knights Landing Kerne (Silvermont X86 a 4 Threads mein ich und auch als eigenständige CPU betreibbar) fallen doch viel eher in das Konzept wie die Server at topic als reine Cruncherkarten wie Bitcoin Mining auf ner HD5870.

Es ist immer eine gewisse Mischung aus "wie mächtig ist mein einzelner Kern und wie flexibel einsetzbar" und "wie hochparallel kann ich einzelne Aufgaben hocheffizient lösen"

 

[Dr. MaRV]

Ich versteh den ganzen Wattwahn nicht. RZ-Betreiber haben mitunter ihre eigenen Kraftwerke und die müssen auch ausgelastet sein. Ich kenne keinen RZ Betreiber den irgendwelche Verbräuche stören, haben sie kein eigenes Kraftwerk, haben sie gute Lieferverträge mit dem Energieversorger ihres Vertrauens. Verbauchen sie weniger als Vereinbart wird es teuer, siehe Microsoft. Um Stromverbrauch machen sich nur Selbstständige und Mittelständler sorgen, die einen 10 m² Raum mit 2 Rackservern und vielleicht ein paar TB Speicher ein RZ nennen. Und was in Großrechnern zum Einsatz kommt um Rekorde zu brechen wissen wir auch alle, häufig X86 kombiniert mit GPUs.

Ich würde die Entwicklung abwarten, bevor ich große Prognosen abgebe, vor allem wenn ich AMD heiße.

 

[Piktogramm]

@Simon: Wenn man komplexe Rechenwerke wie die dicken x86er Rechenwerke (da zähle ich Silvermont und Jaguar dazu!) und diese als RISC ähnliche Architektur auslegt heißt das aber auch, dass man massig Transistoren aufm Die hat, die im Normalzustand zwar an der Versorgungsspannung hängen aber zum eigentlichem Ergebnis nicht viel beitragen, solang der zu bearbeitende Befehl/Datensatz sie gerade nicht betrifft. Lungern da ganz viele Transistoren rum, verwandeln Versorgungsspannung mal Kriechstrom in Wärme.
Kann man mit ner arg aufwendigen, feingliedrigen Steuerung der Energieversorgung kompensieren, das macht die CPU aber auch nicht günstiger.

Unterm Schnitt hat man also entweder viel brachliegendes Silizium mit unnötig hoher Heizwirkung oder aber weniger Heizung, dafür aber noch mehr teures Silizium (Energieversorgung braucht Platz!).

Darum ging es mir. Nicht um den Overhead beim Arbeiten, der ist wirklich seit langem klein genug. Eher darum, dass die X86er zu dicke Kaliber sind für den Spatzenschwarm .

Eher sind Entwicklungen wie Intel Quarc/Xeon Phi und eben die ARM Kerne von AMD (und Anderen) ein Ansatz diesem Problem Herr zu werden.


@ Dr. MaRV: Jedes Kilowatt was anfällt kostet auch wenn man direkt an der Strombörse kauft ~500€ im Jahr (1kW*24h*365d*0,06€/kWh). Hinzu kommt, dass man wenn man Microserver bzw. die kleinen CPUs richtig einsetzt Hardwarekosten sparen kann. Bei Rechenzentren die Strom im Megawattbereich ziehen und Hardware für Millionen kaufen fällt das gebündel ordentlich ins Gewicht!

Vor allem heißt ein geringerer Energieverbrauch auch, dass man die USV Anlage kleiner dimensionieren kann!

 

[Toms]

Nein ... bsplw. bei AMD werden nicht genutzt Einheiten "geparkt" sodass diese kaum Strom verbrauchen

 

[thokra2008]

Interessante Entwicklung.

Wenn Dell deswegen wieder in die ARM Rechner o.ä. investieren sollte, hätte MS wieder mit Windows RT eine Chance?!?
Aber AMD kommt ein halbes Jahr zu spät, denn Dell ist im Herbst 2013 bei den Tablets ausgestiegen.

Aber warum sollten die Leute in ein totes BS investieren, aber wer weiß....

Andoid aufm Server ?!? .....

 

[[F]L4SH]

Jedes Kilowatt was anfällt kostet auch wenn man direkt an der Strombörse kauft ~500€ im Jahr (1kW*24h*365d*0,06€/kWh). Hinzu kommt, dass man wenn man Microserver bzw. die kleinen CPUs richtig einsetzt Hardwarekosten sparen kann. Bei Rechenzentren die Strom im Megawattbereich ziehen und Hardware für Millionen kaufen fällt das gebündel ordentlich ins Gewicht!

Falsch - es sind nach der Rechnung sogar 1000€, weil jedes Watt Stromverbrauch mit einem Watt Klimaanlage ausgeglichen werden muss.
Bei Heißwasserkühlung und ähnlichem würden natürlich andere Multiplikatoren (1,2 z.B.) anfallen


E:

Ach Keule - ich wollte deinem Argument doch nur beipflichten und dich nicht angreifen

Ich kannte nur die Formel, dass auf jedes Watt ein Watt an Kühlung kommt.

 

[Piktogramm]

Meine Aussage bezog sich auf "jedes anfallendes kW Dauerleistung" ob nun durch Klima, Beleuchtung, Server ist schnuppe! Das Installierte Leistung an Servern Klima folgen lässt ist eine andere Geschichte.

Ansonsten, eine Verdopplung des Energiebedarfs aufgrund des Kühlsystems ist unwahrscheinlich. Da müssten die Wärmepunpen eine wirklich ungünstige Temperaturdifferenz bewältigen. Also hohe Außentemperaturen oder aber ein sehr kaltes Rechenzentrum! Ohne wirklich ZWINGENDE Gründe baut aber Niemand Rechenzentrum in derart warme Regionen und unter übliche Raumtemperaturen kühlt man die Dinger auch nicht . Üblich sind dann eher, dass man größere Wärmetauscher nimmt, diese befeuchtet etc. pp.

 

[CaptainCrazy]

AMD vernachlässigt immer mehr die x86 Architektur und die Entwicklung steht dort schon seit Bulldozer still, einfach erbärmlich.

Stimmt. x86-Server sind die Zukunft. Deshalb hat IBM die x 86 Server-Sparte auch verkauft und Google entwickelt ARM-Server auch nur aus Spaß am Basteln. AMD, IBM und Google liegen alle falsch. Hätten sie doch bloß auf dich gehört.....

 

[Sontin]

Ach, man muss einfach AMD lieben.

Powerpoint Slides mit "Market leader" Scherze. Immerhin hat man noch Humor in einer Firma, deren x86 Geschäft innerhalb von 2 Jahren 25% an Wert verloren hat. Und natürlich wird man Leader im ARM Markt mit den Standardprozessoren. Macht auch sinn, wenn die ganze Welt einem Custom-Core basierend auf der ISA bringt.

Aber hey, wir wissen auch, dass AMD Market leader im "new device" Sektor werden will. Und das ganze ohne Geräte.

 

[Mr.Kaijudo]

Stimmt. x86-Server sind die Zukunft. Deshalb hat IBM die x 86 Server-Sparte auch verkauft und Google entwickelt ARM-Server auch nur aus Spaß am Basteln. AMD, IBM und Google liegen alle falsch. Hätten sie doch bloß auf dich gehört.....

Die denken halt nur blind und kurzsichtig an schnellen Gewinn als an das was sich am Ende durchsetzen wird oder besser gesagt hält man sich hier nicht einmal wichtige Optionen offen, nein man handelt einfach.

 

[Krautmaster]

Jup vor allem kann nicht jeder der grad Bock hat mal eben X86 fertigen lassen, während bei ARM ja die Architektur verkauft wird
... Es gibt kein einfaches "besser"

 

[Toms]

Naja, VIA könnte es jedenfalls nochmal versuchen Die halten ja noch ne x86 und AMD64 Lizenz

 

[Blediator16]

Ach, man muss einfach AMD lieben.

Powerpoint Slides mit "Market leader" Scherze. Immerhin hat man noch Humor in einer Firma, deren x86 Geschäft innerhalb von 2 Jahren 25% an Wert verloren hat. Und natürlich wird man Leader im ARM Markt mit den Standardprozessoren. Macht auch sinn, wenn die ganze Welt einem Custom-Core basierend auf der ISA bringt.

Aber hey, wir wissen auch, dass AMD Market leader im "new device" Sektor werden will. Und das ganze ohne Geräte.

Frage mich wieso du bei Tegra nicht so eine Scheisse daherschreibst. Kannst deinen Beitrag nämlich 1zu1 auf das komplette Tegrafail ummünzen.

 

[pipip]

Krautmaster
Ich traue zu wetten dass es bald auch APUs auf ARM Basis geben wird. Dass können dann nur gewisse Firmen in der Foundation oder NV Anbieten. Besser als nur ein Handvoll X86 die den Preis oder Markt diktieren.

Aber egal AMD vernachläsigt jetzt nicht gleich x86, immerhin kommt auch Berlin und Nachfolger. Mal sehen wie sinvoll HSA APUs sind.

 

[xyz-]

Ach, man muss einfach AMD lieben.

Powerpoint Slides mit "Market leader" Scherze. Immerhin hat man noch Humor in einer Firma, deren x86 Geschäft innerhalb von 2 Jahren 25% an Wert verloren hat. Und natürlich wird man Leader im ARM Markt mit den Standardprozessoren. Macht auch sinn, wenn die ganze Welt einem Custom-Core basierend auf der ISA bringt.

Aber hey, wir wissen auch, dass AMD Market leader im "new device" Sektor werden will. Und das ganze ohne Geräte.

warum wälzt du das nicht auf deine so hochgelobten FailTegra um?

 

[strex]

Natürlich wird auch Leistung bei Datentransfers benötigt. Woher kommt denn die Vermutung? Trotz offloading schaffen viele Xeon E3 und E5 nicht die NICs mit 10G zu befüllen, geschweige denn QDR bei infiniband.

Interessant wird es erst, wenn die Software zur Verfügung steht und da sieht es im Enterprise Markt nicht sonderlich rosig aus.

 

[Krautmaster]

Krautmaster
Ich traue zu wetten dass es bald auch APUs auf ARM Basis geben wird. Dass können dann nur gewisse Firmen in der Foundation oder NV Anbieten. Besser als nur ein Handvoll X86 die den Preis oder Markt diktieren.

Aber egal AMD vernachläsigt jetzt nicht gleich x86, immerhin kommt auch Berlin und Nachfolger. Mal sehen wie sinvoll HSA APUs sind.

was alle immer mit "APU" haben ^^ ein total überladeter Marketingbegriff. Ne APU ist auch nichts anderes wie relativ mächtige CPU Kerne (seis X86 oder ARM Kerne) + ne GPU die eher hoch-parallele, dafür weniger komplexe Aufgaben übernehmen kann.
Das is heute auch nicht groß anders wenn man in Supercomputern auch nicht ausschließlich GPUs betreibt sondern immer zusammen mit CPU.

Es ist immer die Frage was ich eben brauche. Viel Leistung ohne extreme Codeoptimierung und Parallelität (nicht alles lässt sich grenzenlos parallelisieren) - also eher CPU -lastig, oder ob ich Spezialaufgaben habe bei denen ich vergleichsweise unkomplexe Aufgaben speziell auf die Hardware zuschneidern kann und dann mit GPUs massiv an Leistung gewinne.

Nimm einen UVD als Beispiel, der macht diese eine Sache, Videos beschleunigen, super effizient da eben genau auf das optimiert und zurechtgestutzt - dafür dürfte es mit dem UVD schwer sein AES zu entschlüsseln. Genauso ist der AES Befehlsatz bei heutigen CPU direkt "verdrahtet" umgesetzt, Hardware nahe, und dabei dann Faktoren schneller wie alleinig auf CPU Kernen in Software gelöst.

Man kann aus einer HD5870 verhältnismäßig mehr Performance pressen (vor allem pro Transistor) als aus einer Hawaii, da sich letztere wieder mehr Richtung CPU entwickelt hat (generell die GPU der vergangenen Jahre im Hinblick auf Computing wo Flexibilität mehr gefragt war als reine Flops). Was ist nun HSA? Nicht viel mehr als wie eine FPU / Int / AES / UVD Einheit und nun kommt noch ne "GPU" Einheit dazu die für diverse Aufgaben durchaus Sinn ergeben kann, eben diese hoch-parallelen Tätigkeiten. Da dürften dann neue CPU Befehlsätze nütig sein um HSA quasi zuzuordnen.

Entscheidend ist am Schluss, wie gut es von der Software genutzt wird und wie hoch der Aufwand der Implementierung ist. Bei AMD heißt HSA und APU, woanders hats eben nen anderen Namen.
AMD und Nvidia bauen ihre GPU Architektur immer mehr Richtung CPU um, um eben gefragte Flexibilität zu erhöhen - Intel geht einen dezent anderen Weg, sie entwickeln auch ihre Shader (in den heutigen iGPU) - trimmen ihre kleinen X86 zunehmend zur GPU bzw extrem in die Breite wie z.B. Knights Landing. Lang nicht so "breit" wie GCN, aber dafür flexibler.

Im Prinzip könnte man doch das ganze jetzt vllt von Aufgaben von Universell - > Speziell ordnen

klassische CPU --> MultiCore CPU --> XEON Phi --> APU --> GPU (GCN) --> GPU (5D) --> Spezielle Schaltungen wie AES/UVD in HW

Man versucht natürlich ein möglichst breites Feld zu zu bedienen, und versucht bei einer APU beide Welten zu kombinieren. Das macht man aber schon heute auch und deswegen gibts Aufgaben bei denen eine reine GPU auf Basis 5D viel fixer is als ne APU, oder aber auch Aufgaben bei denen ein XEON Phi viel geeigneter ist als ne APU.

Die kleinen ARM Kerne in diesen Server Karten (Egal ob Intel ATOM oder ARM / AMD) würde ich irgendwo zwischen Multicore CPU und XEON Phi ansiedeln, eher ne klassische MultiCore CPU die auf maximale Effizienz getrimmt wird.