News Mars: 64-Kern-Prozessor in 28 nm auf 640 mm² aus China

[[F]L4SH]

Dann frag mal die Kinesen!

Jo und als nächstes fragen wir die Demokratische Volksrepublik Korea, wem die Republik Korea gehört und die Palästinenser, wem West-Jerusalem gehört

 

[Headcool]

Mars: 0.6 Teraflops FP single precision @ ~120W
Xeon Phi Knights Landing: ~6 Teraflops single precision @ ~200W

Da sieht man wieder mal wie unglaublich "effizient" die ARM-ISA wirklich ist.
So ein Teil würde ich nicht mal geschenkt nehmen.

Und das hier CB wieder mal Äpfel mit Birnen vergleicht ist mir auch nicht klar. Gerade wenn man doch erkannt hat, dass der Xeon Phi der Gegenspieler ist, wieso macht man dann einen Vergleich mit einem Xeon?

 

[Luffy]

Habe selbst beruflich 3 Jahre in China (Peking und Shanghai) gelebt und was soll ich sagen, ich mache einen großen Bogen um chinesische Produkte. Das wird bei chinesischen Prozessoren nicht anders werden.
Was soll ich mich über chinesische oder russische Prozessoren freuen? So etwas wollte ich noch nicht einmal geschenkt haben.

Wo ist dein Problem? Bist du ne zielgruppe für Russische und Chinesische CPU, ja ich freue mich über alternative. Und was bringt uns diese aussage?

 

[Simon]

Mal abwarten. Die Daten klingen fast schon zu gut um wahr zu sein.

Wenn man von 120 Watt TDP rückwärts rechnet:

120 Watt
- 24 Watt (16 x 1,5 Watt pro DDR3-1600-Controller)
- 6 Watt (2 x 3 Watt pro PCIe x16)
- 20 Watt (32 MB L2, 128 MB L3, Controller-Units und das restliche Chi Chi)

bleiben für jeden der 64 Kerne noch knapp über 1 Watt TDP übrig. Bei 2,0 GHz in der ARMv8 Architektur in 28 nm ein durchaus "sportlicher" Wert. Das muss man erstmal hinbekommen.

Nicht, dass ich denen das nicht grundsätzlich zutraue. Vielleicht hat ja tatsächlich jemand als kleines Startup eine zündende Idee gehabt und einen ordentlichen Fertigungspartner gefunden. Allerdings kommen für ein 640 nm Chip in 28 nm auch nicht so viele Namen in Frage...

 

[Mr.Seymour Buds]

Mars: 0.6 Teraflops FP single precision @ ~120W
Xeon Phi Knights Landing: ~6 Teraflops single precision @ ~200W

Da sieht man wieder mal wie unglaublich "effizient" die ARM-ISA wirklich ist.
So ein Teil würde ich nicht mal geschenkt nehmen.

Du solltest bedenken, dass die Herstellkosten für den MARS mit Sicherheit auch sehr viel niedriger sein werden. Die Chinesen bauen den dann halt 10 mal. Strom? Ist da eh egal, die haben billige Kohle aus Australien!

 

[Simon]

Auch die Chinesen können nicht zaubern. Ich vermute ja mal, dass der Mars bei SMIC im 28-nm-HKMG-Verfahren gefertigt wird. Das wäre zwar eine einheimische Firma, aber schlussendlich werden auch die auf Equipment zur Belichtung und Verarbeitung angewiesen sein. Und so viele Lieferanten für entsprechende Ausrüstungen einer 28 nm HKMG Lösung gibt es auf der Welt dann nun auch nicht.

Und am Ende entscheidet natürlich auch die Stückzahl über die Kosten.

 

[Headcool]

Du solltest bedenken, dass die Herstellkosten für den MARS mit Sicherheit auch sehr viel niedriger sein werden. Die Chinesen bauen den dann halt 10 mal. Strom? Ist da eh egal, die haben billige Kohle aus Australien!

Davon würde ich nicht ausgehen. Die größten Kosten bei der Halbleiterfertigung sind die Investionskosten nicht die laufenden. Sowohl der 14nm Fertigungsprozess von Intel, als auch der 28nm Fertigungsprozess von TSMC & Co haben sich schon längst amortisiert.

Bei HPC siehts anderst aus. Da sind die Betriebskosten sehr wohl relevant. Abgesehen davon ist der wohl wichtigste Punkt immer der Platzbedarf. Wenn etwas 10x soviel Energie benötigt, braucht es auch etwa 10x soviel Platz.
Abgesehen kriegst du viel schneller ein Problem mit der Parallelisierung. Je mehr Kerne desto schlechter skaliert das Ganze.

Abgesehen davon ist die chinesische Regierung eine der ersten und besten Xeon Phi Kunden. Die wechseln nicht so schnell, da ja auch das Personal entsprechend geschult ist und die Bibliotheken für x86 geschrieben worden sind.

 

[lynx007]

Das teil ist noch gar nicht drausen und da wird schon das neue China bejubelt das gekonnt der westlich kapitalistischen Erfolgreich die Stirn bietet.... ohhhh man

Das Teil existiert noch nicht in Serie und es wird von experten bezeifelt das es so überhupt realisierbar ist. Aber China und Gloria.... ^^

Also ich muss sagen, alles was auch in China entwickelt wurde, war auf jedenfall billiger. Leider aber nicht nur vom Preis, sondern auch von der Güte.

 

[VikingGe]

Da sieht man wieder mal wie unglaublich "effizient" die ARM-ISA wirklich ist.

Und was genau hat das jetzt mit der ISA zu tun? Xeon Phi hat auch nur deshalb so viele FLOPs, weil man das Ding mit 512 Bit-SIMD-Rechenwerken vollgestopft hat, wie man sie (noch) in keiner normalen x86-CPU findet. Dass der Prozessor hier offensichtlich gar keine SIMD-Einheiten hat, hat erstmal wenig mit den Befehlssatz zu tun.

 

[Headcool]

Und was genau hat das jetzt mit der ISA zu tun? Xeon Phi hat auch nur deshalb so viele FLOPs, weil man das Ding mit 512 Bit-SIMD-Rechenwerken vollgestopft hat, wie man sie (noch) in keiner normalen x86-CPU findet. Dass der Prozessor hier offensichtlich gar keine SIMD-Einheiten hat, hat erstmal wenig mit den Befehlssatz zu tun.

Skylake Xeons haben auch AVX-512 und in der nächtsten/übernächsten Generation wird es sicher auch die Core-CPUs Einzug finden.

Der Mars hat SIMD Einheiten, allerdings nur 128bit breit.
Mehr geht auch gar nicht, weil die ARMv8-ISA eben keine Instruktionen für 256/512 bit breite SIMD Einheiten hat.
Also ist die ISA definitiv ein Hauptgrund dafür, dass das Teil so schwach ist.
Natürlich liegt das nicht nur an den SIMD-Instruktionen, sondern auch an den Tausenden anderen Instruktionen welche in der x86 ISA vorhanden sind und in der ARM-ISA fehlen.

Abgesehen davon, würde das Teil mit breiteren SIMD-Einheiten auch wiederrum viel mehr Energie verbrauchen und so würde sich die Energieeffizienz kaum steigern.

Punkt ist, dass die ARM-ISA nicht energieeffizient und die x86-ISA nicht energiehungrig ist, auch wenn das oft behauptet wird.

 

[Fred_EM]

Die Anzahl der Kerne auf einem Chip sind nicht wirklich das Problem.

Das Problem ist das Bus-System. Daran scheitert es meistens.
Nette Übung zum Thema, mehr wird wohl nicht draus.

Erst wenn grundsätzlich neue Wege gefunden werden
Bus-Systeme effektiv zu integrieren wird das Thema Many-Core wieder interessant.

 

[VikingGe]

Mehr geht auch gar nicht, weil die ARMv8-ISA eben keine Instruktionen für 256/512 bit breite SIMD Einheiten hat.

Was man per (proprietärer) Erweiterung lösen könnte. Nochmal, das konnte x86 vor Xeon Phi auch nicht.

Der Mars hat SIMD Einheiten, allerdings nur 128bit breit.

Dann kann aber die Rechnung mit 0.6TFLOPS (SP) nicht passen. 64*4 (wg. 128 Bits) *2 (wg. zwei Einheiten) *2 (wg. FMA) * 2.0 GHz sind nach meiner Rechnung über 2 TFLOPS. Sofern die FPUs vernünftig gepipelined sind, aber davon kann man im Jahre 2015 wohl ausgehen.

Wo steht das eigentlich? Auf den Folien steht es offensichtlich nicht, oder ich überlese da was. Was ich da allerdings sehr wohl finde ist die Angabe mit 512 GFLOP/s Peak Performance. Irgendwie fehlt mir da jetzt gerade die Erklärung für den Unterschied um Faktor 4.

Edit: Da steht wohl, dass 128 Bit-Befehle unterstützt werden, aber das heißt nicht, dass auch 128 Bit-Hardware verbaut wird.

Punkt ist, dass die ARM-ISA nicht energieeffizient und die x86-ISA nicht energiehungrig ist, auch wenn das oft behauptet wird.

Fakt ist aber nunmal, dass bei x86-Hardware unheimlich viel Arbeit ins Frontend gesteckt wird und auch werden muss, weil die ISA einfach so fürchterlich kompliziert ist. Einer der Gründe, warum x86-Hardware heute relativ stromsparend relaisiert werden kann, ist eben, dass die ganze Decodiererei dank µop-Caches usw. nicht mehr für jeden Befehl separat ausgeführt werden muss.

 

[Dolph_Lundgren]

Chenesen

Dree Chenesen met nem Kentrebes...

 

[Headcool]

Was man per (proprietärer) Erweiterung lösen könnte. Nochmal, das konnte x86 vor Xeon Phi auch nicht.

Der Phi ist schon ziemlich alt und 256 bit SIMD gibts in x86 schon seit AVX (+AVX2) welches seit Sandy Bridge Einzug gefunden hat.
Propietäre Erweiterungen sind eine schöne Sache vor allem wenn man einen Alleingang wagt. Frag doch mal bei AMD nach wie SSE5 so läuft.

Dann kann aber die Rechnung mit 0.6TFLOPS (SP) nicht passen. 64*4 (wg. 128 Bits) *2 (wg. zwei Einheiten) *2 (wg. FMA) * 2.0 GHz sind nach meiner Rechnung über 2 TFLOPS. Sofern die FPUs vernünftig gepipelined sind, aber davon kann man im Jahre 2015 wohl ausgehen.

Wo steht das eigentlich? Auf den Folien steht es offensichtlich nicht, oder ich überlese da was. Was ich da allerdings sehr wohl finde ist die Angabe mit 512 GFLOP/s Peak Performance. Irgendwie fehlt mir da jetzt gerade die Erklärung für den Unterschied um Faktor 4.

Edit: Da steht wohl, dass 128 Bit-Befehle unterstützt werden, aber das heißt nicht, dass auch 128 Bit-Hardware verbaut wird.

Das Problem ist ganz einfach - du rechnest falsch. Du kannst nicht einfach FMA dazu multiplizieren, wenn du durch SIMD den Faktor 4 schon dazumultipliziert hast. FMA-Instruktionen sind letztendlich auch nur eine Art von SIMD-Instruktionen.
Da FMA aber nur 2 Operationen durchführt im Gegensatz zu den klassischen SIMD-instruktionen welche 4 durchführen, ist FMA für die Peak Performance irrelevant. Außerdem gehst du davon aus, dass alle Instruktionen eine Zyklus benötigen was auch nicht richtig ist.

Zur Integer-Performance:
Es sind 4 Integer-Einheiten verbaut welche einen Zyklus für simplere Integer-Berechnung benötigen.
--> 64 * 2.0G * 4 = 512G
Genau so wie es auch in den Folien steht

Zur Floating-Point-Performance:
Da muss man etwas spekulieren, da nicht alle benötigten Infos angegeben werden.
Es sind auf jeden Fall 2 SIMD Einheiten verbaut. Diese könnten 8 Operationen abarbeiten. Die benötigten Zyklen werden mit 3 für Addition bzw Multiplikation angegeben.
--> 64 * 2.0G * 8/3 = 341G
Das ist etwas niedrig. Es könnte sein, dass sich die Zyklen auf double-Precision-Operationen beziehen. Wenn man davon ausgeht, dass single-precision nur 2 Zyklen benötigen kommt man auf ein realistischeres Ergebnis:
--> 64 * 2.0G * 8/2 = 512G
Ist allerdings wie gesagt reine Spekulation.

Fakt ist auf jeden Fall, dass hier SIMD-Einheiten verbaut sind, bei FP ist es konkret angegeben, bei INT werden 4 seperate Ports spezifiziert, welche letztendlich auch wie eine SIMD Einheit genützt werden können.

Fakt ist aber nunmal, dass bei x86-Hardware unheimlich viel Arbeit ins Frontend gesteckt wird und auch werden muss, weil die ISA einfach so fürchterlich kompliziert ist. Einer der Gründe, warum x86-Hardware heute relativ stromsparend relaisiert werden kann, ist eben, dass die ganze Decodiererei dank µop-Caches usw. nicht mehr für jeden Befehl separat ausgeführt werden muss.

Es wird sicher mehr Arbeit ins x86-Frontend gesteckt als in ein ARM-Frontend, dass es aber "unheimlich viel" ist wage ich zu bezweifeln. Immerhin muss es mit jeder Iteration nur angepasst, nicht aber völig neu entworfen werden.
Abgesehen davon haben die vielen Instruktionen in der x86-ISA eben ihren Nutzen. Es können einfach viel mehr Funktionalitäten in Hardware gegossen werden und müssen nicht über Software emuliert werden.
Genau das macht x86 so effizient wie es eben ist.

 

[VikingGe]

Propietäre Erweiterungen sind eine schöne Sache vor allem wenn man einen Alleingang wagt. Frag doch mal bei AMD nach wie SSE5 so läuft.

Nur, dass SSE5 nie implementiert wurde, weil mit AVX schon etwas Besseres in Sichtweite war.

Bei so einem Chip hier könnte man den Schritt durchaus wagen, weil die Software, die darauf läuft, in der Regel doch recht speziell ist und darauf optimiert werden kann (und wenn es nur per Compiler-Flag ist).

Da FMA aber nur 2 Operationen durchführt im Gegensatz zu den klassischen SIMD-instruktionen welche 4 durchführen

FMA ist zumindest in der x86-Welt eine SIMD-Operation, die auf der vollen Vektorbreite arbeitet. Natürlich verdoppelt das die Peak-Leistung, und ich gehe mal davon aus, dass MARS das genau so handhabt.

Wie kommen denn die 6 TFLOPS (SP) von Knights Landing wohl zustande? Genau so:
72 Kerne * 2 vollwertige FMA-Einheiten * 16 SP-Komponenten pro Vektor bzw. Einheit * 2 wg. FMA * 1.3 GHz.

Außerdem gehst du davon aus, dass alle Instruktionen eine Zyklus benötigen was auch nicht richtig ist.

Das ist die Latenz, also die Anzahl der Takte, die benötigt wird, bis ein vom Ergebnis abhängiger Befehl ausgeführt werden kann. Sofern die Hardware gepipelined ist, kann aber jede Einheit pro Takt einen Befehl annehmen, insofern ist die Rechnung schon richtig.

Nebenbei sind die drei Takte Latenz für eine Addition und eine Multiplikation exakt dieselben wie bei Broadwell, die sind schon realistisch.

Es können einfach viel mehr Funktionalitäten in Hardware gegossen werden und müssen nicht über Software emuliert werden.

Nämlich?

x86-ISA hat in der Tat ein paar für Userspace-Code relevante Vorteile (z.B. das direkte Nutzen von Daten aus dem RAM, was bei RISC-Architekturen immer einen zusätzlichen Befehl braucht, ggf. die komplexe Addressierung), aber viele komplexe Befehle (z.B. das prinzipiell sinnvolle shld oder der angestaubte loop-Befehl) werden bei den meisten CPUs einfach in mehrere µops übersetzt und sind nicht schneller als die äquivalenten einfachen Operationen, je nach CPU sogar langsamer.

Auf der anderen Seite hat(te) x86 früher extrem wenige Register (bei x86_64 ist das kein großes Problem mehr und mit AVX-512 kommen nochmals so viele SIMD-Register dazu, dass man davon eigentlich mehr als genug haben müsste) und außer dem cmov-Befehl keinerlei Unterstützung für conditional execution für Integer-Befehle, um Sprünge zu sparen. Bei ARM geht das mit fast jedem Befehl.

 

[Headcool]

Nur, dass SSE5 nie implementiert wurde, weil mit AVX schon etwas Besseres in Sichtweite war.

Bei so einem Chip hier könnte man den Schritt durchaus wagen, weil die Software, die darauf läuft, in der Regel doch recht speziell ist und darauf optimiert werden kann (und wenn es nur per Compiler-Flag ist).

Ich meinte SSE4.a

Natürlich könnte man den Schritt wagen, aber die Wahrscheinlichkeit, dass es irgendwann in einer zukünftigen ARM-ISA aufgenommen werden würde ist sehr gering. Mit anderen Worten - alle Resourcen die man da hineinstecken würde, wären nach ein paar Jahren umsonst. Gerade im HPC-Bereich wo die CPU-Hersteller Bibliotheken bereitstellen müssen ist das nicht von Vorteil.

FMA ist zumindest in der x86-Welt eine SIMD-Operation, die auf der vollen Vektorbreite arbeitet. Natürlich verdoppelt das die Peak-Leistung, und ich gehe mal davon aus, dass MARS das genau so handhabt.

Wie kommen denn die 6 TFLOPS (SP) von Knights Landing wohl zustande? Genau so:
72 Kerne * 2 vollwertige FMA-Einheiten * 16 SP-Komponenten pro Vektor bzw. Einheit * 2 wg. FMA * 1.3 GHz.

Ja in x86 ist das so. Bei dem Mars ist das allerdings anderst. Da werden die benötigten Zyklen mit 6 angegeben, also genau doppelt so hoch wie eine einzelne Operation benötigen würde. Entsprechend erhöht FMA die Peak Performance hier nicht.

Das ist die Latenz, also die Anzahl der Takte, die benötigt wird, bis ein vom Ergebnis abhängiger Befehl ausgeführt werden kann. Sofern die Hardware gepipelined ist, kann aber jede Einheit pro Takt einen Befehl annehmen, insofern ist die Rechnung schon richtig.

Nebenbei sind die drei Takte Latenz für eine Addition und eine Multiplikation exakt dieselben wie bei Broadwell, die sind schon realistisch.

Es macht keinen Sinn die Latenz auf diesen Folien anzugeben. Die Latenz ist für den entsprechenden Anwendungsbereich komplett irrelevant. Ich denke eher, dass damit der Throughput gemeint ist.

Nämlich?

x86-ISA hat in der Tat ein paar für Userspace-Code relevante Vorteile (z.B. das direkte Nutzen von Daten aus dem RAM, was bei RISC-Architekturen immer einen zusätzlichen Befehl braucht, ggf. die komplexe Addressierung), aber viele komplexe Befehle (z.B. das prinzipiell sinnvolle shld oder der angestaubte loop-Befehl) werden bei den meisten CPUs einfach in mehrere µops übersetzt und sind nicht schneller als die äquivalenten einfachen Operationen, je nach CPU sogar langsamer.

Auf der anderen Seite hat(te) x86 früher extrem wenige Register (bei x86_64 ist das kein großes Problem mehr und mit AVX-512 kommen nochmals so viele SIMD-Register dazu, dass man davon eigentlich mehr als genug haben müsste) und außer dem cmov-Befehl keinerlei Unterstützung für conditional execution für Integer-Befehle, um Sprünge zu sparen. Bei ARM geht das mit fast jedem Befehl.

Zb spezielle Befehlssatzerweiterungen wie AES-NI. Man könnte zwar argumentieren, dass entsprechende Gegenstücke auch in der ARMv8-ISA Einzug gefunden haben, aber Einzug in eine RISC-Architektur werden sie niemals erhalten, da allein deren Präsenz unvereinbar mit der Idee von RISC sind.
Ein anderes Beispiel wäre RDRAND bwz RDSEED. Selbst die besten Software-Zufallszahlengeneratoren kommen nicht an die Qualität der von diesen Instruktionen erzeugten Zufallszahlen heran, brauchen aber trotzdem hunderte Male länger.
Weitere Instruktionen die x86 inhärent effizienter macht inkludiert Cache-Prefetch, Scatter & Gather, Transactional Synchronization Extensions, etc.

Natürlich gibt es ein paar Befehle die man nicht mehr nutzen sollte, da sie langsamer sind als die allgmeineren Befehle, wie beispielweise INC oder ENTER. Das liegt daran, dass x86 so ziemlich vollständig abwärtskompatibel ist, was das Design einschränkt, nicht aber an der Anzahl der Befehle. Solange die Compiler Designer sowas beachten ist das kein Problem.

Das x86 früher nicht das goldene vom Ei war ist mir klar. Aber in den letzten 10 Jahren hat sich da soviel weiterentwickelt. Es ist die einzige ISA die wirklich skalierbar ist. Von einem SoC für eine Smartwatch bis zur Spitze der Top500 Liste.

Die Möglichkeit jeden Befehl conditional zu machen hätte ich bei x86 auch gerne, aber man kann ja nicht alles haben

 

[VikingGe]

Ich meinte SSE4.a

SSE4a ist aber auch ein ziemlich schlechter Witz, wenn man mal von POPCNT und LZCNT absieht (die aber auch eigene CPUID-Flags haben und streng genommen nicht so wirklich dazu gehören). Mir fällt beim besten Willen kein einziges Anwendungsgebiet für die beiden Bitmanipulationsbefehle ein, und bevor ich irgendwas per movntsd in den RAM speichere, wird das eher in einem vollen Vektorregister gruppiert.

Weitere Instruktionen die x86 inhärent effizienter macht inkludiert Cache-Prefetch, Scatter & Gather,

Ich habe ARM ehrlich gesagt noch nie in Assembler programmiert, aber dass letzteres nicht existiert, wundert mich dann doch etwas.
Der Witz an unseren AVX-Instructions ist ja eigentlich, dass der Grundbefehlssatz ziemlich RISC-Like ist.

Transactional Synchronization Extensions

Die Intel ja bei Haswell so toll hinbekommen hat

Es macht keinen Sinn die Latenz auf diesen Folien anzugeben. Die Latenz ist für den entsprechenden Anwendungsbereich komplett irrelevant. Ich denke eher, dass damit der Throughput gemeint ist.

Es macht noch viel weniger Sinn, eine FPU zu bauen, die so sehr am Durchsatz krepiert.

Ich meine, 512 GFLOPs Peak-Performance bekommt man auch mit nem i7-6700K hin, da braucht man keine 64 Kerne für. Das werden die in China wohl auch wissen.

 

[terraconz]

Wie kann es denn angehen, dass das Teil halb soviel Leistung wie die zwei Xeons bringt, aber gegenüber einem Xeon 20% schneller ist?


Ansonsten schon interessant das Teil. Bin aber auch mal gespannt, wie das am Markt ankommt.

Weil einmal 1ARM core vs 1 Xeon verglichen wird und dann 64 ARM Cores vs einer Plattform mit 2x Xeon.
Steht ja so im Text

 

[Headcool]

Ich habe ARM ehrlich gesagt noch nie in Assembler programmiert, aber dass letzteres nicht existiert, wundert mich dann doch etwas.

Scatter & Gather gibt es soweit ich das gesehen habe nicht. Wobei es in x86 Gather auch erst seit AVX2 und Scatter bisher nur im Xeon Phi gibt.

Cache Prefetch gibt es wirklich in ARMv8. Aber es gibt ja auch noch jede Menge andere ISAs die es nicht beherrschen.

Der Witz an unseren AVX-Instructions ist ja eigentlich, dass der Grundbefehlssatz ziemlich RISC-Like ist.

Die einzelnen Operationen ja. Aber die Idee von SIMD widerspricht grundlegend der von RISC. Abgesehen werden ja nicht immer 4/8/16 gleiche Operationen durchgeführt, sondern auch teilweise Operationmixturen wie zB. + - + -.
Wenn man etwas nicht triviales mittels AVX parallelisieren will, muss man ja auch viel mit Masken & Co arbeiten.
Bei AVX512 wird es noch wesentlich deutlicher. Conflict Detection-, Prefetch-, Exponential-, Reciproc-, Ternary-Logic-, Permute-, FP-Decomposition-, etc-Instruktionen. Von RISC ist da keine Spur.
Bald kommen neue Instruktionen schneller als man dafür einen Verwendungszweck findet. Aber so wie es aussieht gibt es sonst wenige Alternativen die Performance weiter zu steigern.

Die Intel ja bei Haswell so toll hinbekommen hat

Nach diesem Vorfall weiß ich wieso die Xeons normalerweise mit den neusten ISA-Features ein Jahr hinterherhinken.

Es macht noch viel weniger Sinn, eine FPU zu bauen, die so sehr am Durchsatz krepiert.

Ich meine, 512 GFLOPs Peak-Performance bekommt man auch mit nem i7-6700K hin, da braucht man keine 64 Kerne für. Das werden die in China wohl auch wissen.

Naja die 512 GFLOPs sind nicht meine Erfindung, sondern stehen so in den Folien. Der Benchmark bestätigt das nur noch.

Wie gesagt - ich würde das Ding nicht mal geschenkt nehmen. Und wenn ich mir andere staatlich geförderte CPU-Projekte so ansehen wie Elbrus & Loongson, dann wundert es mich nicht, dass der Mars auch auf dem Papier nichts reißen kann.

 

[Miuwa]

Die einzelnen Operationen ja. Aber die Idee von SIMD widerspricht grundlegend der von RISC.

Wie kommst du dadrauf?