DevPandi schrieb:
Ampere sollte sich da mal nicht soweit aus dem Fenster lehnen:
Meltdown und
Spectre betreffen auch bestimmte und vor allem die größeren ARM-Designs genau so.
Aber irgendwie muss man fehlende Features doch als Vorteil verkaufen. Diese ganze Gerede von der moderneren Architektur ... Letztendlich kommt es darauf an in ob und in welchen Workloads die Prozessoren einen Vorteil bieten.
X86 ist etabliert. Damit die Anwender sich auf eine neue Architektur einlassen, muss diese schon einen deutlichen Vorteil bei den eigenen Workloads bieten.
DevPandi schrieb:
Im Desktop und Notebook-Bereich, genauso Workstations mit unterschiedlichen Workloads ergeben Hybrid-Designs wiederum Sinn, weil hier unterschiedliche Lasten auftreten können.
Das sieht man an sich bei Alder Lake und bei Raptor Lake.
Aber man darf nicht vergessen, das man dies so bewertet, weil sich AMD mit den CCXs und CCDs in eine Nische hineinoptimiert hat. AMD kann nur 8 oder 16 Kerne. Oder eben Kerne deaktivieren.
DevPandi schrieb:
x86 hat auch heute immer noch einen vorteil den ARM, RISC und Co nicht hat: Kompatiblität. Auch wenn sich das Thema mit der Zeit für ARM und RISC-V "verbessern" wird, aktuell ist ein Ende von x86 noch nicht absehbar.
Ein Ende kommt selten abrupt.
Aber man muss sich Mal in Ruhe anschauen in welchen Bereichen des CPU-Marktes X86 überhaupt noch vertreten ist.
Wenn man auf Client (Notebook, Desktop) und Server schaut dominiert X86. Natürlich verwenden einige Embedded Systeme auch X86. Aber für viele Designs ist X86 zu teuer oder passen die verfügbaren X86 CPUs nicht auf ins anforderungsprofil. Oder man kann gar keine X86 verwenden, weil man keine Lizenz bekommt, die es erlaubt einen X86 Kern mit der eigenen IP zu koppeln.
Beim Client haben wir Apple. Bei den Servern die Cloudanbieter und mit Ampera den ersten CPU-Hersteller. Nvidia kommt bald.
DevPandi schrieb:
Alles andere - also wirklich der "Kern" - anschließed ist überschaubar.Bei Zen4 nehmen die 32 MiB L3-Cache ca. 50 % der Fläche ein.
Das Verhältnis wird schlimmer weil SRAM von N5 auf N3E
nicht skaliert.
Hybrid Bonding kommt gerade noch rechtzeitig.
DevPandi schrieb:
AMD kann also hier aktuell sehr gut an den Kernen schrauben und gerade im Cloud-Bereich, für den Zen4c gedacht ist, ist L3 nicht mehr ganz so wichtig, weil hier die Kommunikation zwischen den Kernen überschaubarer ausfällt.
Hier gibt es die Hebel Menge von L3 und Anbindung des L3 an die Kerne. Und wie die Kerne untereinander gekoppelt werden.
Die Frage ist wie viel Silizium wird sonst noch mitgeschleppt, das für diese Workloads von geringem Nutzen ist.
DevPandi schrieb:
Etwas schwer verständlich, meinst du nicht im "Aber man benötigt nicht für alle Aufgaben große CPU-Kerne"?
Ja. Ich hätte Workloads anstatt Funktionen schreiben sollen. Außerdem hatte ich groß = wider issue und klein = smaller issue im Hinterkopf, und habe es mir damit zu einfach gemacht.
DevPandi schrieb:
Es kann schon Sinn ergeben, es kommt auf den Kern an. Wäre interessant, was die e-Kerne mit SMT leisten könnten.
Worauf ich hinaus will:
Wenn der Kern A kleiner als Kern B ist, weil weniger Cache, einfachere Steuerlogik und ein einfacher Branchpredictor verbaut sind, aber beide Kerne 4-issue sind, dann kann beim Kern A SMT beizubehalten sehr viel Sinn ergeben.
Wenn der Kern C kleiner als Kern D ist, weil Kern C als 4- und Kern D als 6-issue ausgelegt ist, wird SMT AFAIK bei Kern C weniger Nutzen bringen als im Kern D.
Und wenn dann die Fläche limitiert ist, wie es bei den E-Cores von Intel der Fall ist, muss man eben abwägen wo die Transistoren den größeren Nutzen bringen.
Man wird sehen welchen Nutzen AMD beim Zen 4c aus SMT zieht.
Es ist schon interessant wie gut Apple die 8-issue CPU-Kerne ohne SMT auslasten kann.
DevPandi schrieb:
Oh, das hat in dem Fall nichts mit den Stückzahlen zutun gehabt, sondern alleine damit, dass damals die Kompatiblität für x86 gesprochen hat und alte Software problemlos weiter verwendet werden konnte, ohne dass man sie - im besten Fall - neu kompilieren musste und im schlimmsten Fall vollständig neu programmieren.
Die 68000er waren weit verbreitet und es wurde sehr viel Software für die 68000er geschrieben.
Aber dann sind die X86 mit den Stückzahlen davongezogen. Das hat Intel natürlich ordentlich Einnahmen gebracht.
Als ich 1991/1992 im Spörle Katalog den Preis einer 68030-CPU gesehen habe, war mir eigentlich sofort klar, dass die Sache gegessen war. Aber eingestanden habe ich es mir damals noch nicht. Der 68040 war noch richtig gut. Der 68050 fiel aus und der 68060 war der Abschied. Damals haben alle von RISC geredet und die 68000er-Fraktion hat auf den 88000er geschiehlt. Aber der scheiterte gleich zu Anfang.
DevPandi schrieb:
x86 hat sich ja nicht durchgesetzt, weil es die "beste" Architektur war, sondern weil die Programme darauf liefen und das auch noch schnell.
Der 68000 war erheblich besser. Aber auch zu teuer, wesdhalb sich IBM für den X86 entschieden hat.
Motorola hat sich noch eine ganze Weile im Erfolg mit Workstations und im Embedded-Bereich gesonnt. Mac, Amiga, Atari ST haben sie IMO nicht so richtig geschätzt. Letztendlich lies Motorola die 3 im Regen stehen.
In den 90igern konnten Motorola gegen Intel nicht mehr mithalten und im Workstation-Markt wurde der 68000er von X86 und RISC ausradiert. Intel hat ab dem 386er einige sehr gute CPUs abgeliefert.
Im Embedded-Markt konnten die 68000er sich länger in Nischen halten. Auch heute laufen manche neu verkaufte Produkte noch mit 68000er.
DevPandi schrieb:
Die Ausgangslage ist heute eine andere: Software wird heute in der Regel in einer Hochsprache entwickelt und die Compiler sind heute viel besser als noch vor 20 oder 30 Jahren.
Der zweite wichtige Punkt sind die neuen Paradigmen, wie z B. GPU, Rechenwerke für AI, DPUs.
Bei einigen Geräten wie DPUs kommen intern auch CPUs zum Einsatz, aber es sind keine X86.
Der dritte wichtige Punkt ist auf dem Server Java und die Interpretersprachen. Mit einer guten Laufzeitumgebung hat man schon sehr viel erreicht.
DevPandi schrieb:
Ebenso geht der Trend - und Intel geht es ja bei Saphire Rapids bereits so und AMD hat mit den APUs auf Zen4-Basis diesen Schritt auch vorgestellt - von generalisten wieder hin zu Spezialisten. Mit AVX512 und AMX blähte und bläht intel die eigene Architektur auf, gleichzeitig zeigt Google, Apple und Co, dass kleine spezialisierte Zusatzkerne, die über einen Treiber/API angesprochen werden, bestimmte Aufgaben viel schneller und effizienter lösen können.
IMO sind AVX512 und AMX Sackgassen. Sie sind richtig toll in einigen Workloads, aber sie werden auch mitgeschleppt wenn man sie gar nicht benötigt. Und wie weit skalieren sie, wenn man richtig viel von dem Stoff braucht? Wenn man dann Spezialhardware reinpackt, bleibt das Silizium wieder ungenutzt.
Gerade im anbrechenden Zeitalter der Chiplets halte ich diesen Ansatz den CPU-Kern immer weiter aufzublasen für überholt. Eine schlanke*) CPU die darauf getrimmt ist die klassischen CPU-Lasten hoch effizient abzuarbeiten, eng gekoppelt mit GPU, AI-Engines, DPUs .... Das ganze mit ausreichend gemeinsamen Speicher ausgestattet. Was es braucht ist die Softwareunterstützung. Und dank Chiplets kann man die Recheneinheiten so konfigurieren wie man es benötigt.
*) Vom Funktionsumfang aus betrachtet, was ja nicht heißt dass man an den Integer ALUs sparen muss. Als Laie ist mir nicht klar was man an FloatingPoint-Leistung reinstopfen muss.
Der kritische Punkt ist so oder so die Software. Hier sind die AMD APUs leider das Negativbeispiel. Hardware bringt ohne Software die sie verwendet leider nichts. Man überlege Mal ganz kurz was mit Cuda für die Caveri-APU möglich gewesen wäre, ...
DevPandi schrieb:
AMD wird sich Xilinx nicht umsonst "einverleibt" haben.
Meiner Meinung nach war die AIE der Grund warum AMD Xilinx übernommen hat und warum sich Xilinx so bereitwillig von AMD kaufen lies. Dass AMD über Xilinx Zugang zu neuen Märkten bekommt und dass AMD die Abhängigkeit vom Client-Markt verringert war es erst in zweiter Linie. Dass es zwischen AMD und Xilinx keine Überschneidungen gab, hat die Sache erst ermöglicht.
AMD hatte bei AI ein riesiges Loch und Xilinx war zu klein um die AIE im erforderlichen Tempo zu verbreiten.
Beim Client steht und fällt es mit der Software.
Falls die AIE bei Phoenix Point ausgelastet wird, könnte sie einen gewaltigen Unterschied machen. Ein dickes Falls weil Software und AMD ... ich gebe aber die Hoffnung nicht auf dass Xilinx hier was beisteuert.
Auf der anderen Seite wird die Softwareentwicklung erheblich einfacher wenn man keine Spezialboards benötigt, sondern alles schon eingebaut ist. Vor allem um Einsteiger anzulocken. Schau'n wir Mal, ob Xilinx das auch so sieht.
DevPandi schrieb:
Wird man abwarten müssen. Für AMD und Intel ist x86 aktuell noch sehr wichtig und machen quasi das Geschäft aus.
Momentan. Aber viele Workloads, die momentan zunehmen sind nicht an X86 gebunden.
Ich erwarte dass Nvidia mit Grace Intel und AMD so richtig weh tun wird. Denn viele X86 CPUs werden verwendet um Nvidia-Karten zu bedienen. Nvidia wird dafür sorgen, dass Grace das besser als die X86-CPUs kann.
Und RISC-V drängt mit aller Macht nach. Sie werden nicht so lange wie Arm brauchen. Gewissermaßen hat Arm den Weg für RISC-V vorbereitet. Natürlich wird einiges an Zeit vergehen bis die anderen Architekturen z. B. bei Datenbankanwendungen überhaupt eine Alternative zu X86 sind.
Aber X86 hat die RISC-CPUs auch nicht in einer Generation verdrängt. Und der Zombie Power hält sich ja immer noch.
Genau deshalb ist es erforderlich dass AMD und Intel die Einfallstore für neue Marktteilnehmer verschließen. Und das funktioniert IMO nur wenn Kerne mit unterschiedlicher Charakteristik entwickelt werden.
Für mich war beim FAD 2022 der wichtigste Punkt, dass AMD angeboten hat AMD-Kerne und Customer IP zusammenzupacken. Wenn es AMD und auch Intel gelingt Kunden von diesem Weg zu überzeugen, hat X86 eine Chance. Falls nicht wird X86 immer mehr in eine Nische wandern.
Dabei halte ich wie gesagt den häufig angepriesene Effizienzvorteil von Arm und RISC-V eher für belanglos. Ob es nun 5 oder 10 Prozent sind. Viel wichtiger ist die Anzahl der verfügbaren Designs und dass sie viel besser auf die Workloads abgestimmt werden. Und dass eigene IP mit Arm bzw. RISC-V viel einfacher kombiniert werden kann.
