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

[Piktogramm]

Danke @SV3N
Edit: Danke Sven!


Ok, die größte Begründung für die Knicke im Graphen für x86 CPUs ist, dass da fröhlich Threads auf virtuelle SMT Cores schmeißt. Damit zeigen die Graphen vor allem, dass SMT keine Skalierung von 1 hat, wobei AMD bekanntermaßen etwas besser mit SMT skaliert als Intel. Gezeigt an einem Stresstest, dessen Nichteignung als Benchmark gleich am Anfang der Dokumentation steht. Zudem passt stress-ng seine Arbeitsgröße an die lokalen Caches an und blendet damit die Leistungsfähigkeit des Interconnects zwischen den Cores und externer Anbindung aus.
Also mehr oder weniger sinnloses Marketinggeblubber

@Teralios
SMT hat eigentlich keinen nennenswerten Overhead, das ist ja der Trick von SMT, dass alle Daten des virtuellen Kernes lokal bleiben. Caches und Register bleiben beim Wechsel zwischen den CPU-Threads ja lokal.

tv als konstant anzunehmen ist schon eine deutliche Vereinfachung. Typischerweise ist es ja eher so, dass mit Zunehmender Anzahl an Prozesse die Wahrscheinlichkeit für Kollisionen bei Ressourcenzugriffen exponentiell steigt. Selbst bei eigenständigen Prozessen kommt es dazu, dass Zugriffe auf gemeinsame Caches, Memory, Festspeicher, Netzwerk etc. problematisch sein können.

 

[Teralios]

Typischerweise ist es ja eher so, dass mit Zunehmender Anzahl an Prozesse die Wahrscheinlichkeit für Kollisionen bei Ressourcenzugriffen exponentiell steigt. Selbst bei eigenständigen Prozessen kommt es dazu, dass Zugriffe auf gemeinsame Caches, Memory, Festspeicher, Netzwerk etc. problematisch sein können.

Muss ich jetzt ernsthaft noch erklären, dass diese Variable individuell für jedes Problem bestimmt werden muss und ich hier einfach nur mal der Einfachheit wegen einen fiktiven Wert genommen habe, damit ich hier verdeutlichen kann, dass beide Gesetzte einmal eine theoretische und dann eben auch eine praktische Komponente haben, mit der man rechnen kann und dass der erwartete Speed-Up, besser die Skalierung davon abhängt, unter welcher Prämisse man ran geht?

Man kann doch einfach mal sagen, dass man sich bei der Aussagekraft eines Gesetztes ein wenig vertan hat? Ist ja nicht schlimm, aber was ist daran so schwer einfach zu sagen: "Danke, okay Amdahls Gesetz passt hier nicht, hast recht ist das andere." Denn bei den Grafiken hier wird kein Problem mit einer festen Größe verglichen, sondern ein Problem, dass mit jeder CPU größer wird.

Aber nein ... man muss ja jetzt noch darüber diskutieren, ob ich tv richtig gewählt habe in einem fiktiven Beispiel. ... Je einfacher das Problem, umso weniger Verwaltungsaufwand habe ich. ...

Und zum Thema Overhead in SMT: Lese! Viel Spaß.

Und Entschuldigung, wenn du das jetzt abbekommen hast, aber es ist einfach nervig.

 

[Piktogramm]

tv ist eben nicht nur Abhängig vom Problem bzw. der Problemstellung sondern eben auch von der Auslastung vorhandener Ressourcen. Wo insbesondere jene Ressourcen zum tragen kommen, die annähernd seriell arbeiten. Wobei das Amdahl auch nicht berücksichtig und auch statisch modelliert.
Ich gebe dir uneingeschränkt recht, dass Gustavson ein valides Modell hat und je näher dieses Modell das Verhalten eines realen Falles beschreibt, desto eher lohnt es sich das Problem von der CPU in Richtung GPU oder vergleichbarer Systeme zu schieben. Für typische Anwendungen auf einer CPU, wäre das Modell Gustavson meiner Erfahrung nach untypisch. Ausnahmen gibt es, und ein typischer Ansatz wäre den Workload sinnvoll zu vergrößern bei deutlich langsamer steigendem Overhead, was aber Gustavson auch beschreibt.
Oder anders, Gustavson ist mir für die meisten CPU Workloads zu optimistisch

Das Paper was du verlinkt hast, beschäftigt sich mit dem Overhead von SMT in Punkto Flächenbedarf auf dem Die in Relation zum Gewinn an Ausführungsgeschwindigkeit bzw. Auslastung der Ausführungseinheiten. Das ist interessant, hat aber mit dem Verwaltungsaufwand beim Wechsel zwischen CPU-Threads (den Overhead den ich meinte und jener der für die Anwendungsentwicklung interessant ist) fast nichts zu tun.
Interessant ist das Paper allemal, danke

Um dich auf die Palme zu bringen. Imperativ, Präsenz, Aktiv, Indikativ von "lesen" ist "lies"
https://de.wiktionary.org/wiki/Flexion:lesen

PS: Ja ich bin nervig

 

[boonstyle]

@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.


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.

Freudscher Verschreiber

 

[Teralios]

Um dich auf die Palme zu bringen. Imperativ, Präsenz, Aktiv, Indikativ von "lesen" ist "lies"

Klappt in dem Fall nicht, weil mein Fehler in dem Fall nicht der Imperativ ist, sondern das Auslassen wichtiger Worte.

Da sollte stehen: Das mal lesen! Nicht nur Lesen! Oder kurz: Ich hab so schnell geschrieben, dass ich an der Stelle schon so weit war, dass ich was ausgelassen habe. Mea-Culpa. Also, ja du hast recht, aber ich wollte was ganz anderes schreiben.

Das Paper beschreibt jedoch auch die Technik und gibt an, welcher Aufwand betrieben werden muss. SMT ist nicht nur auf die Fläche mit Overhead verbunden, sondern auch in der Ausführung. Denn die beiden Threads müssen gegen einander auch abgesichert werden, so dass man nicht auf die Daten des jeweils anderen zugreifen kann. Und das ist es, was ich als Verwaltungsaufwand meinte.

Manchmal muss man, wenn man merkt, das man etwas aneinander vorbei redet, neu ansetzetn.

 

[abcddcba]

@SV3N evtl. lohnt sich ja bei Gelegenheit (nach den Feiertagen oder so) mal ein Update von dem Artikel hier basiered auf diesem aktuellen Test: https://www.anandtech.com/show/16315/the-ampere-altra-review
Zusammengefasst findet man die Benchmarks gegen Xeon und Epyc auch hier: https://www.golem.de/news/ampere-altra-80-kerniger-arm-gleichauf-mit-64-core-epyc-2012-152956.html

 

[maxik]

Sowas in kleiner für ein NAS/Homeserver wäre schon was