News ARM-Server-Prozessor: 40 Modelle des ThunderX2 mit bis zu 32 Kernen verfügbar

[Volker]

Cavium will mit über 40 Varianten des ThunderX2 mit maximal 32 Kernen Intels Skylake-SP angreifen. Dies soll in erster Linie über Preis/Leistung gelingen, denn der Maximalausbau wird bei Cavium nur 1.795 US-Dollar kosten – bei Intel sind dafür bis zu 13.011 US-Dollar nötig.

Zur News: ARM-Server-Prozessor: 40 Modelle des ThunderX2 mit bis zu 32 Kernen verfügbar

 

[racer320kmh]

Wie ist bei denen die Leistung gegenüber AMD-/Intel-x86 Server-CPUs?

 

[konkretor]

ich will das zeug endlich mal zu einem vernünftigen preis kaufen können, der einzige wirklich größere hoster der arm server anbietet ist meines wissens nach scaleway.

 

[Rickmer]

Klingt ja spannend, aber ohne weitere Details kann man nur spekulieren...

Wie ist bei denen die Leistung gegenüber AMD-/Intel-x86 Server-CPUs?

Wichtiger noch: wie ist die Energie-Effizienz?

 

[SoDaTierchen]

ARM-CPUs kann man nur ganz oberflächlich mit x86-CPUs vergleichen, also die Leistung im Vergleich zu Skylake-EP / Epic ist ein unsinniger Vergleich. ARM-Software läuft nicht auf x86-Architektur und umgekehrt.

Ich habe aber mal gelesen, dass die Leistung der ARM-Modelle den x86-Modellen gleichen Preises leicht überlegen ist. Nimmt man Modelle gleicher Spezifikationen, dann verlieren die ARM-Modelle ausnahmslos. Der Wert Watt/Leistung war bei ARM minimal besser, aber kaum der Rede wert. Selbst für den 24/7-Betrieb kaum der Rede wert.

Ich finde aber leider die Quelle nicht mehr. Aus dem Gedächtnis würde ich sagen: Bei gleichem Preis ARM 30% schneller, 5-10% weniger Stromverbrauch. Bei gleichen Specs (Kerne & Takt) war x86 etwa doppelt so schnell. Aber ohne Quellen sind diese Angaben mit Vorsicht zu genießen, wie gesagt, ich weiß nicht mehr, wo ich das gelesen hatte.

 

[BLJ]

(...) ARM-Software läuft nicht auf x86-Architektur und umgekehrt.
[...]

Man kann Quell-Code sehr wohl für ARM als auch für x86 kompilieren.
"Intermediary Language" Programme (wie Java, .Net) und interpretierte Sprachen (Python, Javascript, PHP,....) laufen selbst verständlich auch auf einer ARM CPU (so lange es denn einen entsprechenden interpreter gibt, und die gibt es i.d.R.).

Einzig wahr ist, dass ein x86 Kompilat nicht auf ARM läuft und umgekehrt.

 

[Particle010]

Wichtiger noch: wie ist die Energie-Effizienz?

Bei Cloudflare überlegt man wohl, langfristig ganz auf ARM umzusatteln: https://www.golem.de/news/cpu-architektur-cloudflare-koennte-komplett-auf-arm-cpus-wechseln-1803-133478.html

In unserer Analyse haben wir festgestellt, dass es selbst dann sinnvoll wäre, zu ARM zu wechseln, wenn Intel uns die Chips kostenlos zur Verfügung stellen würde, weil die Energieeffizienz so viel besser ist.

Das wird natürlich aber auch von den Workloads abhängen.

Man kann Quell-Code sehr wohl für ARM als auch für x86 kompilieren.

Eben. Linux läuft schon lange prblemlos auf ARM und neuerdings sogar wieder Windows, wenn auch nicht besonders toll.

 

[Prinzenrolle_]

Ich finde schon, dass man gewisse Sachen vergleichen kann sollte.

Es muss ja nicht ein Benchmark sein. Aber ich will wissen, wie lange hat CPU A für eine Aufgabe im Vergleich mit CPU B und wie viel Energie haben diese dann verbraucht.

 

[Knut Grimsrud]

"Beworben wird die neue Prozessorfamilie mit einem 256 KByte großen L2-Cache pro Kern, der gesamte SoC wird dabei flankiert von einem gemeinsam genutzten 32 MByte großen L2-Cache und acht Speicherkanälen, ..."

Ich denke, ihr meintet hier L3-Cache.

 

[leipziger1979]

Cavium will mit über 40 Varianten des ThunderX2 mit maximal 32 Kernen Intels Skylake-SP angreifen.

Wie soll das gehen ?
Wenn ich eine x86-x64 Umgebung habe wird das nichts.
Es macht nur Sinn wenn ich schon ARM nutze oder entsprechend umsteigen kann.

 

[Jesterfox]

Aber gerade im Serverbereich gibt es viele Anwendungsfälle die problemlos umsteigen könnten. Einerseits sind viele Server-Anwednungen OpenSource und oft auch auf ARM kompilierbar, andererseits wird viel auf Interpreter- (PHP, Phython, Ruby, Perl, JS) oder IM-Sprachen (Java, .NET) gesetzt die man auch auf ARM laufen lassen kann.

 

[Piktogramm]

Wie soll das gehen ?

gcc march=armv8-a

Was für erstaunlich viele Fälle sehr gut funktioniert. Wenn dann noch kritische Bibliotheken von den CPU Anbietern mit optimiertem Assembler ausgestattet werden können ist da ein sehr großer Markt da.

 

[Hayda Ministral]

@leipziger1979: Die CPUs um die es hier geht zielen auf Server und HPC. In beiden Feldern sind bereits viele Anwendungen von Windows nach Linux portiert und können daher mit in der Regel verhältnismäßig geringem Aufwand auf jede von Linux unterstützte Zielarchitektur compiliert werden.

 

[yummycandy]

gcc march=armv8-a

Was für erstaunlich viele Fälle sehr gut funktioniert. Wenn dann noch kritische Bibliotheken von den CPU Anbietern mit optimiertem Assembler ausgestattet werden können ist da ein sehr großer Markt da.

Funktioniert nur, solange die Quelldateien auch für ARM angepasst wurden, sowie ein passendes Makefile erstellt wird.

 

[helionaut]

Wenn ich eine x86-x64 Umgebung habe wird das nichts.

Das passt zu deinem Profilbild

 

[Teralios]

...

Man muss da schon unterscheiden. BLJ hat es ja schon angesprochen. Heutige Programme werden jedoch seltens noch in Assembler oder Maschinencode geschrieben, sondern in einer mal mehr oder weniger nahen Hochsprache.

...

So ganz stimmt es nicht mehr, was du da zu PHP, JavaScript oder Phyton. Schau dir mal Googles JavaScript Engine v8 an. Ebenso PHP oder auch Pyhton. Die bedienen sich heute doch sehr ähnlichen Ansätzen wie es zum Beispiel auch bei Java genutzt werden. Quelltext wird in Bytecode übersetzt und zwischen gespeichert und anschließend durch einen JIT-Compiler in Maschinencode umgewandelt und ausgeführt. (Bei PHP bin ich mir nicht ganz sicher ob der JIT-Compiler schon umgesetzt wurde, aber es war angedacht.)

Was JavaScript von Java - mal die Sprachleicheneigenschaften wie Typisierung außen vorgelassen - primär unterscheidet ist halt, dass die "Programme" als Quelltext ausgeliefert werden, während Java halt als "Bytecode" vorliegt. Aber selbst daran wird ja zum Teil schon wieder gearbeitet.

...

Die Anpassungen an Quelltexten (C++, Rust und Co) fällt in der Regel zwischen verschiedenen Architekturen (hier nun ARMv8 und x86_64) doch eher überschaubar aus und ist in der Regel für die meisten nicht vorhanden, da sie selbst mit C++ nicht so Hardware nah programmieren. Wenn man zu dem auf die Spezialbibliothek der Hersteller verzichtet und in der Regel OpenSource-Alternativen nimmt oder ggf. sich selbst Wrapper schreibt, fällt eine "generelle" Anpassung des Quelltext an eine Architektur eigentlich weg und die Hauptarbeit wird vom Compiler übernommen..

Ich persönlich finde es weit komplizierter für Windows oder Linux zu programmieren, da dann wirklich massiv viele APIs vorhanden sind, die sich wirklich stark unterscheiden.

 

[Piktogramm]

Funktioniert nur, solange die Quelldateien auch für ARM angepasst wurden, sowie ein passendes Makefile erstellt wird.

Wie schon geschrieben wurde, der überwiegende Teil C / C++ Code ist ausreichend weit abstrahiert, dass Architekturspezifisch kaum etwas angepasst werden muss. Die Ausnahmen habe ich bereits beschrieben .

Im Makefile ist es dann überwiegend auch nur eben jene Anpassung des GCCFlags "march=$arch" und sehr viele Scripts die Makefiles erstellen sehen so oder so vor, dass march als Parameter übergeben werden kann.

Ergänzung (7. Mai 2018)

[...]auf Server und HPC. In beiden Feldern sind bereits viele Anwendungen von Windows nach Linux portiert [...]

Also in dem Bereich sieht die Realität seit einigen Jahren eher so aus, dass für *Nix entwickelt wird und mit Glück Ports für Windows existieren und so richtig Spaß machen das dann oft auch nicht.




@Teralios

JIT für PHP kommt wohl erst mit PHP8. Wobei Facebooks HipHop bereits einen JIT Compiler für PHP bietet.
Und wenn du dich schon so in den Details verlierst. Bei ARM konnte man mit Jazelle und später mit ThumbEE Java Bytecode bedingt direkt auf die CPU werfen.
https://en.wikipedia.org/wiki/ARM_architecture#Thumb_Execution_Environment_(ThumbEE)

 

[helionaut]

Von den Top 500 Supercomputer liefen im November 2017 jedenfalls 100% mit Linux .

In der Praxis hatte ich nie grössere Probleme, Anwendungen auf ARM lauffähig zu bekommen. ASM findet man heute nur noch in Spezialfällen und selbst dann könnte man diese in einem Emulator laufen lassen.

 

[Piktogramm]

@eremit007

Naja ASM findet man doch noch an einigen Stellen. Der Cryptokram hat sehr oft handgeklopften Assembler und die Maintainer für die entsprechenden Bibliotheken sind dann gern mal @intel, @arm, @$cpuvendor. Aber darauf kommt es halt auch an, einfach ne gute CPU auf den Markt werfen hilft wenig. Das Ökosystem muss auch vorhanden sein und der Anbieter muss glaubhaft machen, dass der Support auf hohem Niveau bleibt.

 

[helionaut]

@Piktrogramm
Was für Cryptokram?

Aus dem Umfeld aus dem ich komme, ist die Architektur quasi egal. Früher war alles für SPARC optimiert, aber als x86 immer mehr Marktanteile gewonnen hatte, wurde alles neu geschrieben und dabei wurde Wert auf Platformunabhängigkeit gelegt.
Auch in anderen Feldern (Hosting, Storage, Datenbanken, etc) spielt die Architektur sogut wie keine Rolle.