News Ampere Altra Max („Mystique“): 128 ARM-Kerne für Cloud und Server

[Chismon]

Ampere, so so , schon erstaunlich, dass man nVidia den gleichen Namen fuer die GPU-Generationen nutzten laesst, ich kann mich noch erinnern, dass Apple eine Klage wegen der Nutzung des Namens "Apple" fuer das eigene Baby (bei Gwyneth Paltrow war es, glaube ich) angedroht hat.

"Mystique" klingt nach von Matrox abgekupfert und, um auf nVidia zurueck zu kommen, da koennte sich bei nVidia dann ebenso ein tieferer Einstieg in die ARM-CPU Entwicklung anbahnen, weil man die Technik ja sowieso schon nutzt, bspw. bei den Tegra-Konsolen-SoCs, und man keine x86er Lizenz mehr braucht (nicht, dass ich mir das unbedingt wuenschen wuerde).

Intel, AMD und VIA sind also jetzt wohl gefordert innovativ zu sein und ARM-CPU Entwicklern den Schneid abzukaufen bzw. die Vormachtstellung zu verteidigen.

 

[opake]

Ja das wohl, aber so ein Teil kann ich mir nicht ins Wohnzimmer stellen um damit etwas zu experimentieren. Ich hätte gerne was zwischen nem Raspberry Pi 4 und nem 128-Kern Server ^^.

Ich habe mir mal den Nvidia Jetson geholt.

 

[Giana]

@Tzk Der Vergleich ist noch kruder, es werden nämlich Kerne auf Ampere-Seite nicht mit Kernen bei Intel und AMD verglichen, sondern mit Threads, und der Knick dürfte genau die Stelle sein, wo ein Thread nicht mehr einen ganzen Kern zur Verfügung hat, sondern sich den Kern teilen muss.

 

[Mr.Powers]

Bei den Plots sind die x-Achsen nicht identisch. Bei dem ARM Prozessor steht 'Cores' und bei AMD und Intel 'Threads'.
Der ARM Prozessor hat kein SMT. Hier werden also nur echte Kerne gezählt, während bei Intel und AMD auch virtuelle Kerne eingerechnet werden. Manche Anwendungen profitieren aber nicht von SMT (z.B. BLAS routinen), teilweise wirken sich SMT sogar negativ aus.

Für einen fairen Vergleich darf man die Plots von Intel und AMD also nur bis zur Hälfte betrachten. Und siehe da, sie skalieren auch linear.

Den 'Benchmark' kann man also getrost in die Tonne kloppen!

 

[yummycandy]

Etwas Hintergrund zu den Slides:

This is one of the performance slides Ampere sent out. It’s intended to shore equivalent core scaling between Intel, AMD, and Ampere, but the tests were run using the Linux tool stress-ng. I don’t normally test in Linux, but the stress-ng page notes: “it has never been intended to be used as a precise benchmark test suite, so do NOT use it in this manner.”

https://www.extremetech.com/computi...ores-3-3ghz-clocks-with-128-cores-coming-soon

 

[Hayda Ministral]

@pipip: Skybridge war nicht X86 und ARM in einem Design sondern mit kompatibler Plattform aka Sockelkompatibel.

Nicht das es was ändern würde, aber an ähnlichem (Itanic und Xeon Sockelkompatibel) ist auch Intel gescheitert.

 

[DerHalbmann]

Ich will jetzt nicht sagen, wer den Namen von wem klaut. Also wer zuerst da war.

A64FX ist eigentlich AMD aber ja nun doch nicht und Ampere ist eigentlich Nvidia aber ja nun doch nicht.

schmeißt mich jetzt n Mod ins Aquarium oder fällt das noch jemandem auf, der hier mehr zu sagen hat als ich?

ich freue mich also auf den kommenden ARM Pentium K6 Prozessor.

 

[Hayda Ministral]

@pipip
ARM bedeutet eine Umstellung auf komplett neue Software.

Mit diesem trostreichen Pseudo-Argument vor Augen weinen sich heute noch diejenigen MinesweeperConsultantsSolitaireExperts (MCSE) und Windows-Admins in den Schlaf die es nicht geschafft haben sich auf Linux umschulen zu lassen.

Scherz beiseite. Die großen Anwendungen laufen und liefen traditionell auf verschiedenen Architekturen (MIPS, Sparc, Power, Itanic, x86) und mussten dafür frühzeitig fit gemacht werden. Die werden kein Problem damit haben auf eine neue Architektur zu schwenken. Und die kleineren, agilen, OpenSource Anwendungen gleich gar nicht. Die haben alle ihre Hausaufgaben vor 10 Jahren gemacht - oder sind heute nur noch in der Geschichtsschreibung relevant.

 

[Piktogramm]

@SV3N

"Refer to end notes for details" impliziert, dass es zu diesen Folie noch Details gibt. Schau mal bitte ob du diese veröffentlichen kannst. Wäre interessant zu wissen, was da getestet wurde, denn auf den ersten Blick scheint Ampere "mal eben" Amdahl's Law überwunden zu haben. Was die größere Meldung als die Vorstellung einer CPU wäre..

 

[lokon]

Die großen Anwendungen laufen und liefen traditionell auf verschiedenen Architekturen (MIPS, Sparc, Power, Itanic, x86) und mussten dafür frühzeitig fit gemacht werden. Die werden kein Problem damit haben auf eine neue Architektur zu schwenken. Und die kleineren, agilen, OpenSource Anwendungen gleich gar nicht.

Ein Problem ist aber wenn für jede exotische Architektur ein genauso teurer Rechner zum Testen und zur Entwicklung gebraucht wird.
Bei ARM gibt es eine große Fragmentierung und quasi jedes Feature kostet Lizenzgebühren.
Raspberry Pi hat zB. keine crypto-Erweiterung. Andere Pi-ähnliche Arm-SoCs dagegen schon.
Außerdem kann die Implementierung der "Arm-IP" Prozessorkerne auch subtil unterschiedlich sein.
Die Fehler auf der Hardwarebene sind im Linux-Kernel teilweise dokumentiert und müssen je nach Board/Plattform auch berücksichtigt werden.
Große Firmen können sich diese Entwicklungsabteilung mit eigner HW leisten - aber kleine Entwickler nicht.

Das ist ja auch bekannt - Indirekt wird sehr viel für Server oder Cloud gesponsert mit freien AWS Programmen oder Cloud-Accounts. Oder indem eine Softwareemulation geschrieben wird.
Deshalb gibt es auch "Spieltagen" an der Universität, wenn IBM Mainframe Wettbewerbe veranstaltet werden oder auf einmal gratis COBOL Lehrmaterial veröffentlich wird, das vorher für viele €€€ "geheimes" Fortbildungsmaterial war.

Selbst große Anwendungen, die ganz agil wie nodejs sind, werfen auch ganze Architekturen zeitweise aus der Kompatibilitätsliste: zB Mips

Außerdem ist die News nur über den Prozessor.
Da fehlt also schonmal der "Rest" - Board (Formfaktor), Peripherie usw.
Diese sind meiner Meinung bei x86 besser standardisiert - CPUs sind pinkompatibel, Stromversorgung ist standard usw - viele ARM Entwicklerboards (die für Privatpersonen erhältlich sind) gibt es eher im Bastelbereich.

 

[SoDaTierchen]

@BxBender : Das Apple-Ökosystem ist etwas robuster und schon länger geplant, als das ARM dort zwingend ein Flop wird. Viele Apps laufen ohnehin abstrahiert von der Architektur und daher naiv auf ARM und x86 gleichermaßen. Und die anderen Anwendungen werden sich anpassen. Im Gegensatz zu Linux ist Apple nicht offen und im Gegensatz zu Windows muss Apple um keinen Markt kämpfen. Die entscheiden einfach "ab jetzt ARM". Firmen, die für Apple entwickeln, tun dies häufige hauptsächlich oder gar exklusiv, wenn die nicht mitziehen, ist der Verlust zu schmerzhaft. Hier kann Apple problemlos die Firmen zwingen, weshalb der Erfolg von ARM auf der Apple-Plattform keine Frage der Architektur, sondern nur von Apples Durchsetzungsvermögen ist.

 

[Nebula123]

Hier sieht man z.B., dass auch ARM gut Strom ziehen kann wenn's drauf ankommt.

@die Apple-Jünger, die glauben beim Umstieg auf ARM-Macs Desktop-/WS-leistung zum Smartphone-Verbrauch zu bekommen.

 

[Teralios]

Wäre interessant zu wissen, was da getestet wurde, denn auf den ersten Blick scheint Ampere "mal eben" Amdahl's Law überwunden zu haben.

Amdahls Gesetz ist in dem Fall ja auch kein ultimatives und alleingültiges Gesetz. Amdahl ist für seine Aussagen auch entsprechend kritisiert worden, weil es zu "pessimistisch" ist.

Nach Gustafson ist eine entsprechende Skalierung, wir sie hier angegeben wird, durchaus möglich, bedingt aber eine etwas andere Vorgehensweise.

Amdahls Gesetz beschreibt ein Problem mit einer fest definierten Größen mit x % seriellen und y % parallelen Anteil. Entsprechend rennt man damit früher oder später an eine Grenze, da man immer zumindest die Zeit benötigt, die der serielle Code teil benötigt.

Gustafsons hingegen gehen - was Amdahls Gesetzt nicht wieder spricht - zeigt auf, dass man durch mehr Ressourcen die Größe des Problems anpassen kann bei einer fest definierten Zeit.

Die Grafik hier von Ampere zeigt also eine "perfekte" Skalierung, wie man sie von Gustafson kennt.

Die Realität liegt zwischen beiden Gesetzen.

 

[AlphaKaninchen]

@Nebula123 Ich fühle mich angesprochen...

Nein ich glaube nicht den Stromverbrauch eines Smartphones zu bekommen, ich würde mir aber wünchen das die MacBook Air Serie Passiv wird also ungefähr auf dem Level eines Core M beim Stromverbrauch, für Menschen die Leistung wollen gibt es ja Pro.
Und am besten kommt dann noch ein 16" MacBook Air 🥳

 

[Piktogramm]

@Teralios
Stimmt, wobei Gustafson Gesetz auch Dinge auslässt (Kommunikation / Synchronisierung), die typischerweise genau die Stellen sind, die bei massiv parallelen CPU Designs problematisch sind. Damit sich diese Dinge vernachlässigen lassen, müsste man einen Lastfall finden der nahezu isoliert auf einzelnen CPUs läuft oder aber ein sehr mächtigen und damit energiehungrigen BUS verwenden. Ein solcher BUS würde den ehrgeizigen Zielen bei der Energieeffizienz jedoch entgegenlaufen und ist derzeit eines der Probleme bei AMD und Intel, das die Bereiche die nicht direkt Rechenwerke bzw. CPU-Cores darstellen (uncore) einen wesentlichen Anteil am Energiebedarf haben.

Deswegen vermute ich eher, dass der erste Fall als Test herhalten musste. Wobei dann fraglich ist wieso AMD und Intel im Vergleich zu Ampere so aussehen. Da ist viel denkbar Power und Temperatur Target zum Beispiel oder aber Ampere hebelt über den Cache. 1MB L2 je Core bei Ampere gegen 256Kbyte bzw. 512Kbyte bei AMD/Intel. Wenn man da Lastfälle wählt, wie wenig Kommunikation benötigen aber massiv von lokalen Caches profitieren hilft das schon ungemein. Ein solcher Fall würde auch dazu passen, dass AMD besser skaliert als Intel.

Aber alles nur Vermutungen und ich wäre @SV3N dankbar, wenn er da mal das Kleingedruckte veröffentlichen könnte.

PS: Ja, wenn mir jemand Graphen vorlegt und nicht direkt verrät wie die zustande kommen, nehme ich immer an, dass da jemand zu seinen Gunsten aggiert.

 

[Teralios]

@Piktogramm
deswegen schrieb ich ja, dass die Wahrheit dazwischen liegt. In der Regel bewegen wir uns bei Programmen die sich gut parallelisieren lassen zwischen diesen beiden Gesetzen. Perfektes Beispiel sind hier ja die GPUs, die sich immer perfekt zwischen beiden Gesetzten befinden.

Eine leistungsstarke GPU wird bei 1080p durch die CPU eingebremst und schafft so die "60fps", wie das langsamere Modell, sobald aber die Auflösung zunimmt, zieht die starke GPU der schwachen davon.

Also ja, das Bild dort zeigt nur bedingt die Realität, denn so eine Skalierung kommt halt auf das Problem an.

 

[SVΞN]

Aber alles nur Vermutungen und ich wäre @SV3N dankbar, wenn er da mal das Kleingedruckte veröffentlichen könnte.

Kommt gleich, bin dabei. ^^

 

[boonstyle]

@Piktogramm
deswegen schrieb ich ja, dass die Wahrheit dazwischen liegt. In der Regel bewegen wir uns bei Programmen die sich gut parallelisieren lassen zwischen diesen beiden Gesetzen. Perfektes Beispiel sind hier ja die GPUs, die sich immer perfekt zwischen beiden Gesetzten befinden.

Eine leistungsstarke GPU wird bei 1080p durch die CPU eingebremst und schafft so die "60fps", wie das langsamere Modell, sobald aber die Auflösung zunimmt, zieht die starke GPU der schwachen davon.

Also ja, das Bild dort zeigt nur bedingt die Realität, denn so eine Skalierung kommt halt auf das Problem an.

Bin auch der Ansicht, dass sich beide ergänzen und auch wenn amdahl als pessimistisch bezeichnet wird aufgrund der Annahme linearer Steigerung hat er grundlegend Recht mit der Aussage, daß es immer einen Anteil gibt der sich nicht paralellisieren lässt (Schlagwort Race for resources). Vielmehr deckt amdahl die Lücken von Gustafson hiermit ab. Auch sind viele Probleme nicht gleichermaßen in kleine Probleme die unabhängig sibd zerlegen und damit parallelisieren, was bei bruteforce, compiling oder reiner datenbankarbeit absolut einfach ist, gestaltet sich bei komplexeren Sachverhalten eben komplett anders.

 

[SVΞN]

@Piktogramm wie versprochen, der Slide mit den Details zu den Benchmarks respektive Leistungswerten.

 

[Teralios]

@SV3N
danke, aber das bestätigt meinen Verdacht ein wenig. Da wurde auf der CPU ein relativ einfacher Workload geladen, bei dem man die Größe des Problems recht gut und beliebig skalieren kann.

Was hier dann für ARM sprechen würde wäre, dass der Verwaltungsaufwand geringer ausfällt. Bei Intel als auch AMD wird da wohl SMT dazwischen funken und der damit verbundene Verwaltungsaufwand.

Vielmehr deckt amdahl die Lücken von Gustafson hiermit ab.

In dem Fall ist es aber - historisch betrachtet - genau anders rum. Gustafson erweitert Amdahls Betrachtungsweise um eine einen weiteren Blickwinkel und das ist hier auch wichtig.

Und nein Amdahl deckt hier nicht Gustafsons Lücke ab, sondern beide Gesetze behandeln dasselbe Thema, gehen aber von zwei unterschiedlichen Blickwinkeln darauf zu.

Amdahl betrachtet ein Problem fester Größe und gibt dafür an, dass man abhängig von der Parallelität nur einen maximalen Speedup erwarten kann. Dazu definiert Amdahl ein paar feste Variabeln und ich werde nun ein nicht nur theoretisches Beispiel benutzen, dadurch ergibt sich für tp auch eine Feste Grenze.

Ein Programm soll 5000 (n) Bilder berechnen. Die Initialisierung des Programmes benötigt immer 10 Sekunden (ts). Jedes Bild wiederum benötigt 5 (tp(min)) Sekunden, mit der Anzahl der Bilder er gibt sich jedoch ein tp(max). Nach Amdahl habe ich nun zwei "Grenzwerte": T(max) und T(min).

T(max) = ts + tp(max) | tp(max) = tp(min) * n.
T(min) = ts + tp(min)

Er gibt hier für T(max) = 25010 Sekunden und für T(min) = 15 Sekunden. Daraus kann ich nun den maximal zu erwartenden Speed-Up berechnen und der liegt bei 1667. Mehr werde ich nie erreichen, egal wie viele Kerne (c) ich hinzutue.

Der Speed-Up (S) für die einzelnen Kerne errechne ich nun wie folgt:
S = T(max) / (ts + tp(max) / c).

Wir wissen nun, der maximale theoretische Speed-Up liegt hier bei 1667, wir wissen wie viel Zeit wir maximal benötigen und wie viel Zeit der parallele Teil braucht, also Formen wir um und können c(max) berechnen (c(min) ist 1. ): c(max) ist hier 5000. Also, egal wie ich hier vorgehe, besser wird es nicht. (Ergibt sich aus tp(max) / tp(min).)

Da aber CPU-Kerne Verwaltungsaufwand bedeuten, sagen wir, dass nun auch noch die Zeit für die Verwaltung (tv) hinzukommt und die beträgt pro Kern (Einfachheit) 2 Sekunden. Daraus kommen wir nun zu:
S = T(max) / (ts + tv * c + tp(min).

Da wir bereits wissen, unser c(max) ist 5000, können wir damit nun den realen Speed-Up bei maximal möglichen Kernen berechnen.

S = 25010 / (10 + 2 * 5000 + tp(min)). Ist hier nun 2,5.

Und das ist das, ist mal Amdahls Gesetz in Anwendung.

Gustafson gibt mir nun - in diesem Beispiel vor: Du hast T = 25010 Sekunden. ts = 10 Sekunden und tp(min) = 5 Sekunden. Nun nimm mehr Kern (c) und schau wie viele Bilder (n) herauskommen. Habe ich die letzte Zahl, kann ich auch hier ein Speed-Up berechnen.

Die idealisierte Formel für die Anzahl der Bilder:
n = (T - ts / tp(min)) * c.

Nehme ich nun 1 Kern, komme ich wieder auf die 5000 Bilder, nehme ich 2 Kerne, komme ich auf 10000 und so weiter. Ich erhalte also eine lineare Skalierung, da ich nun die Menge der Bilder, die ich in der fest vorgegebenen Zeit erhöhen kann. Auch hier handelt es sich um eine theoretische Skalierung. Wie bei Gustafson kann ich nun auch hier einen Verwaltungsaufwand mit ein beziehen. Nehmen wir wieder die 2 Sekunden pro CPU-Kern an, dann weiß ich, dass irgendwann tv meine T auffressen wird.

n = (T - ts - tv * c / tp(min)) * c. Die maximale Kernanzahl hier wird also durch tv bestimmt. Maximaler tv ist hier 24995 T - tp(min) - ts. Daraus ergibt sich, dass wir maximal 12497 Kerne nutzen können, sonst frisst der Verwaltungsaufwand die Zeit vollkommen aus.

Man kann nun bis zu den 12497 Kernen die einzelnen Speed-Ups berechnen und dann auch den maximalen Speed-Up finden.

Zwei Blickwinkel auf dasselbe Problem, nur einmal nehme ich die Anzahl der Bilder als Fest an, einmal die Zeit.

-- edit --

Wegen des "Verwaltungsaufwandes" ergeben sich im übrigen bei beiden dann ein S(max) und damit ein optimaler C-Wert, danach gehts wieder runter.

Nur - und das ist wichtig - der Verwaltungsaufwand hängt von der CPU, dem OS als auch dem Problem selbst ab. Dieser ist also variable.