x86-Generationen: Wo stehen wir? [Archiv]

Osmoses

2014-05-02, 18:09:21

Hallo!

Ich habe es bisher so verinnerlicht gehabt:
Vom 8086 bis zum 80486 war es noch leicht die Generation zu erkennen (auch wenn es manche 486er gab, die eigentlich aufgebohrte 386er waren).
Dann kam der Pentium und teilweise waren CPUs der 5. Generation für 486er Systeme verfügbar.
Mit etwas Fachwissen konnte man aber auch da den Überblick wahren.

Der Pentium Pro leitete das 80686er Zeitalter ein und Dank Super Socket 7 war auch die Grenze zwischen 80586 und 80686 nicht mehr so klar.

Pentium II/III und M sind für mich gemeinsam mit dem Pentium Pro 80868er.
K5 80586 und K6/2/3/+ 80686.

Pentium 4/D wären demnach 80786er, oder?
Und Athlon / XP demnach ebenfalls 80786?

Was ist dann mit den Core / 2? Da auf dem Pentium M basierend wohl 80686, oder?
Athlon 64 ist dann welche Generation?

Die Core iX XXX Serie 80886? Und die iX XXXX 80986?
Oder sind dies ebenfals noch 80686er?

Mir ist das 80x86er Schema schon immer lieber gewesen (jaja, Marketing) ;)

Coda

2014-05-02, 18:10:10

Zahlen sind Schall und Rauch.

Osmoses

2014-05-02, 18:14:29

Zahlen sind Schall und Rauch.

Ok und jetzt bitte wieder zum Thema!

Leonidas

2014-05-02, 19:33:01

Es ist spätestens ab Nehalem nicht mehr sinnvoll, in diesen alten Kategorien zu denken. Kann man machen, aber dann wird es eher zum Zwang.

Und wenn, dann ist der Core 2 und auch der Pentium M eher eine 8. Generation, keine 6. Die Entfernung zum Pentium Pro ist zu groß.

PS: Ich kann mich noch an Zeiten erinnern, da war "Nehalem" ein weit entferntes Zukunftsgerücht (als Pentium-4-Fortsetzung mit Taktraten von 5-10 GHz beschrieben). Nun ist Nehalem inzwischen längst vorbei ...

Shink

2014-05-02, 19:59:22

Und wenn, dann ist der Core 2 und auch der Pentium M eher eine 8.
Naja. Pentium M "kann" weder 64 Bit (die zusätzlichen Register schaden ja nicht...), PAE wird beim Banias nicht per CPUID gemeldet und XD-Bit gibt es auch keines. So gesehen... hätte ich da dann doch lieber nen Core oder Core 2.

Coda

2014-05-02, 20:07:59

Ok und jetzt bitte wieder zum Thema!
Das ist beim Thema. Damit ist eigentlich wirklich alles gesagt.

BlackBirdSR

2014-05-02, 21:14:48

Ok und jetzt bitte wieder zum Thema!

Es gibt keine allgemein gültige Generationseinteilung.
Man mag anhand von Registerbreiten, Adressraum und besonderen Features noch zwischen 286, 386, 486, 586 unterscheiden können, aber bereits beim AMD K5 wird das ganze plötzlich sehr verworren.

Den Pentium Pro und seine Nachfolger (P2, P3) mag man noch einfach vom Pentium trennen können (OoOE, µOps, Scheduling etc.) aber danach werden Änderungen so komplex und zugleich undurchsichtig, dass eine Einteilung einfach nur sinnlos wird.

Ich würde die ganzen P4, K7, K8, K10, Nehalem, Sandy etc. sogar noch alle eher in die Generation Pentium Pro stopfen.
Man könnte noch 64-Bit IA als neue Generation definieren, aber das geht im Prinzip auch mit einem In-Order-P45C Pentium Kern... ooops!

S940

2014-05-03, 14:52:06

HMm, muss man den Generationenbegriff so technisch eng sehen?
Würde es mir einfach machen und Generationen nur an Vorgänger/Nachfolger festmachen und nur grob die Architektur betrachten.

Der P4 fällt als komplett neues µDesign raus, dafür kann man die Yonahs mit in die Familienhistorie nehmen, die µOp-Fusion einführten.

Mitbewerber würde ich nicht aufführen, sind maximal Cousinen und haben nichts im direkten "Stammbaum" zu suchen, die bekämen nen Nebenzweig. Bis 486 waren es ja die gleichen Architekturen, danach aber nicht mehr, da macht es keinen Sinn das irgendwie unter einen Hut zwängen zu wollen.

ENKORE

2014-05-03, 15:04:33

Wärs nicht eher sinnvoll, die Generationen an den Erweiterungen des Befehlssatzes festzumachen?

Matrix316

2014-05-03, 17:57:47

86
286
386
486
Pentium 586
Pentium 2 686
Pentium 3 786
Pentium 4 886
Core 2 Duo 986
Core i 1086 - Nehalem / Lynnfield
Core i-2 1186 - Sandy Bridge / E
Core i-3 1286 - Ivy Bridge / E
Core i-4 1386 - Haswell
?

;)

Shink

2014-05-03, 19:15:42

Coda

2014-05-03, 19:21:45

Spart euch einfach die Energie darüber nachzudenken, es ist völlig sinnlos.

Loeschzwerg

2014-05-05, 07:55:56

Der 3er ist sicher keine eigene Generation.
Geht es eigentlich auch etwas besser begründet mit den Aufzählungen?
Ach ja: Wikipedia sagt:
http://de.wikipedia.org/wiki/X86-Prozessor#Liste_der_x86er_Generationen

Interessant: K7 eine Generation nach Intel Core? Und Bulldozer ist einen Schritt vor Core i. Naja, zumindest die heterogen-Geschichte sollte man AMD irgendwie anrechnen.

Naja Core "1" war letztendlich nur ein etwas aufgebohrter Pentium M, darf man nicht mit Core-2 verwechseln.

Interessant finde ich da eher:
"Intel Core i-Serie (Das i als neunter Buchstabe im Alphabet soll auf die neunte Generation hindeuten)"

Matrix316

2014-05-05, 10:52:52

Ein Core 2 war auch nur ein aufgebohrter Pentium M bzw. Pentium 3 so gesehen und die Core i sind ja auch eher in dieser Linie als in der Pentium 4 Linie. Und was ist jetzt mit dem Itanium?

BlackBirdSR

2014-05-05, 11:20:05

Ein Core 2 war auch nur ein aufgebohrter Pentium M bzw. Pentium 3 so gesehen und die Core i sind ja auch eher in dieser Linie als in der Pentium 4 Linie. Und was ist jetzt mit dem Itanium?

Itanium gehört nicht zur x86 Reihe und konnte auch nur in der ersten Iteration x86 in HW-Ausführen.

VergesdtVergesst die Generationssache es gibt nicht mehr genug differenzierte Merkmale an denen man das festmachen könnte.

Loeschzwerg

2014-05-05, 12:23:13

Ein Core 2 war auch nur ein aufgebohrter Pentium M bzw. Pentium 3 so gesehen und die Core i sind ja auch eher in dieser Linie als in der Pentium 4 Linie. Und was ist jetzt mit dem Itanium?

Richtig, Core "1" würde ich aber dennoch als Zwischenschritt zur eigentlichen Core Architektur sehen, die dann ja als Core-2 vermarktet wurde. Da hat sich schon einiges getan.

YfOrU

2014-05-05, 12:48:27

Allein schon im Kontext von Micro und später Macro Ops Fusion. Vom PIII ist Core 2 eigentlich schon weit weg und es finden sich auch essentielle Entwicklungen aus dem P4 wieder. Wo der Schnitt zum PIII gezogen werden sollte ist halt eine Frage der Auslegung. Nehalem würde ich damit aber auf jeden Fall nicht mehr in Verbindung bringen.

Matrix316

2014-05-05, 13:56:15

Ab Hyperthreading würde ich den Schnitt ziehen. Core, 2 Duo und Quad waren ja noch ohne und erst ab dem Nehalem kam HT wieder.

Coda

2014-05-05, 14:40:51

Lebt der Thread wirklich immer noch?

ndrs

2014-05-05, 15:51:10

Lass sie doch spielen :D

Leonidas

2014-05-05, 16:31:00

ndrs

2014-05-05, 16:49:54

Ich wär dafür zu definieren, dass jedesmal, wenn sich die Anzahl der Pins im Sockel um mindestens 5 erhöht hat eine neue Generation gegeben ist :)

YfOrU

2014-05-05, 16:56:09

pff und dann entdeckt wer BGA und MCP :D

StefanV

2014-05-06, 00:46:45

Naja, wenn sowieso gespielt wird:

Gen 1: 86/186/286
Gen 2: 386
Gen 3: 486
Gen 4: Pentium
Gen 5: Pentium Pro/2/3
Gen 6: Pentium 4
Gen 7: Pentium M + Core 1/2
Gen 8: Nehalem
Gen 9: Sandy/Ivy Bridge + Haswell/Broadwell

Gute Alt-Infos (bis P4) siehe hier:
http://ht4u.net/old/2001/pentium4_2ghz/index3.php

Da geht u.a. draus hervor, das zwischen 8086 und 80286 fast nix passierte. Womit gleichmal bewiesen wäre, das selbst in den "guten alten Zeiten" man sich nicht auf die Generations-Benennung verlassen konnte.
Und wo war jetzt der Unterschied zwischen 80386 und 80486? Außer, dass letzterer 'nen bisserl mehr Cache und die FPU integriert bekam??

Letztendlich ist dieser Thread nicht wirklich sinnvoll, da selbst die 'Hersteller' aufgegeben haben, nach diesem alten Nummernschema zu denken, eben weil es wenig bis gar keinen Sinn macht...

Leonidas

2014-05-06, 06:59:57

Integrierte FPU ist aus heutiger Sicht schon sehr bedeutsam.

Shink

2014-05-06, 07:56:55

Und wo war jetzt der Unterschied zwischen 80386 und 80486?
Der 486er operiert nicht mehr direkt mit den x86-Befehlen, sondern übersetzt nach RISC. Dadurch kann man erstmal einen Befehlscache einbauen.

Ich verstehe auch nicht, warum 8086 und 80286 die selbe Generation gewesen sein sollen: Der 80286 war erstmals für moderne Betriebssysteme geeignet mit Protected Mode und Segmentierung.
Insofern halte ich den Artikel für "so toll auch wieder nicht", aber wofür gibt es Wikipedia?:freak:

StefanV

2014-05-06, 08:13:19

Der 486er operiert nicht mehr direkt mit den x86-Befehlen, sondern übersetzt nach RISC. Dadurch kann man erstmal einen Befehlscache einbauen.
äh, nein. Das war erst beim Pentium PRO der Fall.

Shink

2014-05-06, 08:49:06

Der wichtigste Unterschied in Bezug auf seinen Vorgänger war der 32-Bit-Integer-RISC-Core, welcher häufig verwendete Instruktionen als RISC implementierte und somit für diese Befehle auf einen Microcode verzichtete.[1] Dies ermöglichte es der CPU, einige Befehle in nur einem Takt auszuführen, machte jedoch die Integration eines First-Level-Caches (L1-Cache) in die CPU notwendig.
Naja, so etwas in der Art halt...

StefanV

2014-05-06, 08:59:58

Nein, das ist bullshit. Den "RISC Kern" gab es bei Intel erst mit dem P6 Design. Bei AMD etwas früher mit dem K5.
auf der englischen Wikipedia (http://en.wikipedia.org/wiki/Intel_80486) steht auch nix dergleichen. Auch die Sache mit dem Microcode gab es zu 80486er Zeiten nicht, den gab es auch erst später.

hier steht noch mal das ganze in deutlich (http://en.wikipedia.org/wiki/P5_%28microarchitecture%29#Major_improvements_over_i486_microarchitecture).
Some RISC proponents had argued that the "complicated" x86 instruction set would probably never be implemented by a tightly pipelined microarchitecture, much less by a dual pipeline design. The 486 and the Pentium demonstrated that this was indeed possible and feasible.

robbitop

2014-05-06, 09:30:29

Das meine ich auch, dass es so gewesen ist.

Coda

2014-05-06, 11:04:56

Und wo war jetzt der Unterschied zwischen 80386 und 80486? Außer, dass letzterer 'nen bisserl mehr Cache und die FPU integriert bekam??
Wenn man keine Ahnung hat, einfach mal...

Matrix316

2014-05-06, 13:35:47

Ich wär dafür zu definieren, dass jedesmal, wenn sich die Anzahl der Pins im Sockel um mindestens 5 erhöht hat eine neue Generation gegeben ist :)
Hmmm, Sockel 1156 -> 1155 -> 1150? :ugly:

z3ck3

2014-05-06, 15:29:33

1156/1155/1150
Versteh auch irgendwie nicht warum Intel die CPUs nicht Pinkompatibel gemacht hat. Hat da eigentlich ernsthaft etwas gegen gesprochen, oder war das eine reine Entscheidung um den Verkauf von entsprechenden Boards und damit Chipsätzen zu steigern? Vor allem 1156->1155.

Entsprechend würde ich auch Nehalem, Sandy Bridge, Ivy Bridge, Haswell und Broadwell in einen Topf werfen. Bis auf ein paar Detailverbesserungen, anderes Fertigungsverfahren und ein paar mehr oder weniger wichtige Befehlssatzerweiterungen sind nicht passiert.

286 -> 386/486 -> Pentium -> Pentium Pro/2/3 -> P4 (Sackgasse Netburst)
286 -> 386/486 -> Pentium -> Pentium Pro/2/3 -> Pentium M + Core Solo/Duo -> Core 2 -> Core i

CyLord

2014-05-06, 17:09:38

Ist doch ganz einfach zu beantworten. Intel möchte verkaufen.

Leonidas

2014-05-10, 11:43:15

Entsprechend würde ich auch Nehalem, Sandy Bridge, Ivy Bridge, Haswell und Broadwell in einen Topf werfen. Bis auf ein paar Detailverbesserungen, anderes Fertigungsverfahren und ein paar mehr oder weniger wichtige Befehlssatzerweiterungen sind nicht passiert.

Zwischen Nehalem und SB gab es einen heftigen Zugewinn an Pro/MHz-Leistung ...
http://www.3dcenter.org/artikel/launch-analyse-intel-sandy-bridge/launch-analyse-intel-sandy-bridge-seite-3

... zudem auch klar höhere Taktraten, wesentlich besseres OC und die dann automatisch integrierte gfx.

peddapille

2014-05-11, 17:10:59

Hallo,

die Frage ist: "wie ist eine Generation definiert". Da müsste man die Prozessorhersteller befragen, oder Wikipedia glauben schenken:

"CPU generations are not strict - each generation is characterized by significantly improved or commercially successful processor microarchitecture designs."

Eine mögliche Einteilung findet sich hier: Wikipedia (http://en.wikipedia.org/wiki/X86).

Im deutschen Wiki steht noch, dass das "i" der 9. Buchstabe des Alphabets gleichzeitig die 9. Prozessorgeneration (nach Intels Zählweise) widerspiegelt.

OBrian

2014-05-12, 00:52:25

Also spätestens ab K5 muß man Intel und AMD trennen, vorher hat AMD (und viele andere) ja Klone gebaut.

Wenn man evolutionäre Schritte zusammenfaßt, daß kann man bei Intel eine schrittweise Entwicklung von Pentium Pro über Pentium M und Core zu den heutigen CPUs sehen, der P4/Netburst und die VLIW-Architektur der IA64-CPUs (war ja auch längerfristig als Desktopablösung vorgesehen) waren beide völlig unabhängig davon, d.h. da hat man mit einem weißen Blatt Papier angefangen.

Bei AMD kann man mit K5 anfangen, bis K6-III+ ist das eine Weiterentwicklung, K7 dann ein kompletter Neuanfang, der sich dann bis K10.5 weiterentwickelt hat. Und Bulldozer ist dann wieder ein Neuanfang "from scratch", der sich in Piledriver, Steamroller, Excavator fortsetzt, ebenso wie die Bobcat->Jaguar->Puma-Reihe.

Sieht bei AMD also hektischer aus, war es wohl auch, aber nur weil Intel die finanziellen Mittel hat, langfristige Fehlentwicklungen nicht nur auszusitzen, sondern auch die alten Sachen weiterzuentwickeln (den Pentium 3 zum Pentium M und zum Core, während der P4 sein Leben gelebt hat). AMD mußte eben wohl und wehe auf eine Architektur setzen und das alte fallen lassen. Nur wenn man im Sturm aus Verzweiflung von einem Boot auf das andere springt, weil man glaubt, das neue sei besser, und dann feststellt, daß es nicht besser ist, dann springt man nicht zurück, wenn das neue zumindest brauchbar ist. In diesem Bild hätte Intel aber eine ganze Flotte von Flugzeugträgern und noch eine Sturmberuhigungsmaschine (aka Subventionen für die Großkunden).

Daß AMD jetzt seit einiger Zeit auf mehrere Architekturen setzt, erweist sich als ungeheuer weise: Bulldozer ist ein Rohkrepierer, aber Bobcat war sehr brauchbar, also geht nicht die ganze Firma den Bach runter.

Wenn man keine Ahnung hat, einfach mal...Dafür, daß Dir das Thema hier scheinbar total am Allerwertesten vorbei geht, postest Du reichlich oft hier rein. Man könnte auch formulieren "Wenn man keine Lust hat, einfach mal..." ;)

robbitop

2014-05-12, 10:06:15

Der K5 hat nichts mit dem K6 gemeinsam. Der K5 ist eine AMD Entwicklung und der K6 eine von NexGEN (die man dann aufgekauft hat und das Design leicht modifiziert hat und es als K6 rausgebracht hat).

K5 war aus Architektursicht gar nicht so verkehrt. Der war bereits superskalar, OoO und war bereits ein RISC Chip mit Decodern. Ähnelt in diesen Hinsichten also mehr dem P6 (Pentium Pro, 2, 3) als dem P5 (Pentium, MMX).

Ich habe vergessen, warum er so "langsam" war. Der K6 war auch eine sehr sehr feine Architektur. Allerdings war seine Archilles Ferse seine FPU, die nicht pipelined war. Damit schafft man viel weniger Durchsatz. Die 3DNow! Instructions beim K6-2 sollten das etwas abschwächen - aber damals wurden die einfach noch (fast) nicht genutzt.

Damals war FP Rechenleistung bei Spielen nicht unwichtig, weil die Transformation damals noch über die CPU (und nicht über die GPU wie seit NV10) erledigt wurde. Das wäre per SIMD FPU natürlich super gut abarbeitbar gewesen und hätte die skalare FPU sehr entlastet.

IIRC gab es auch einen Patch für Quake 2, der das mal demonstriert hat. Da war der K6-2 dann IIRC sogar schneller als ein gleichgetakteter Pentium 2.

Erst der K7 brachte eine gepipelinete FPU und natürlich ein viel breiteres Design, was auch höher taktbar war als der K6. (aufgrund des low latency Designs ging da irgendwann ab ~550-600 MHz einfach nicht mehr)

Es gab sogar ein paar Testmuster von K6-3+ in 180 nm mit Copperinterconnects. Die dienten als Testwafer für die Inbetriebnahme der ehemaligen Fab 30 in Dresden (die heißt heute nur anders).
Keine Ahnung, ob es ein paar von denen auch mal zu ebay und zu einem Übertakter geschafft haben...

Coda

2014-05-12, 11:28:10

Dafür, daß Dir das Thema hier scheinbar total am Allerwertesten vorbei geht, postest Du reichlich oft hier rein. Man könnte auch formulieren "Wenn man keine Lust hat, einfach mal..." ;)
Reiner Altruismus. Ich möchte euch die absolute Verschwendung von wertvoller Lebenszeit ersparen.

Leonidas

2014-05-15, 14:00:27

IIRC gab es auch einen Patch für Quake 2, der das mal demonstriert hat.

Exakt. Daraus haben dann findige Leute Patches für Half-Life und andere Spiele abgeleitet (das bestand darin, nur die INI-Datei zu verändern, der Rest blieb gleich, d.h. es wurde die DLL vom Quake-Patch benutzt).

In der 3DCenter-Urzeit hab ich selber an so was rumgebastelt. Ich kann mich noch an "meinen" 3DNow-Patch für Heretic 2 erinnern - ob ich auch noch anderes gemacht habe, hab ich leider nicht mehr im Kopf.

StefanV

2014-05-15, 16:51:09

Ich habe vergessen, warum er so "langsam" war.
War er nicht, ganz im Gegenteil. Mit dem K5 hat AMD auch das PR Rating angefangen, da die CPU bei gleichem Takt deutlich flotter war als der Pentium. schau mal hier (http://www.cpu-museum.de/?m=AMD&f=K5)....
Das Problem war halt, wie bei allen nicht Intel CPUs dieser Zeit die FPU, die nicht soo flott zur Werke ging...

Erst der K7 brachte eine gepipelinete FPU und natürlich ein viel breiteres Design, was auch höher taktbar war als der K6. (aufgrund des low latency Designs ging da irgendwann ab ~550-600 MHz einfach nicht mehr)
...wobei der K6 auch arge Probleme mit Windows 95 mit der Zeit hatte...
Das ganze war aber eher M$ Schuld, die irgendwelche Timer so programmiert haben, dass es bei zu hohem Takt zu Problemen kommen kann. Das war beim K6 relativ früh der Fall. Bei 'anderen Designs' war es etwas später der Fall.
Wo genau das war, weiß ich nicht mehr genau....
War beim K6 aber wesentlich geringer als bei Intels bzw dem K7.

Es gab sogar ein paar Testmuster von K6-3+ in 180 nm mit Copperinterconnects. Die dienten als Testwafer für die Inbetriebnahme der ehemaligen Fab 30 in Dresden (die heißt heute nur anders).
Keine Ahnung, ob es ein paar von denen auch mal zu ebay und zu einem Übertakter geschafft haben...
Ja, K6-3+ und K6-2+ (mit verringertem L2 Cache) gab es auch in 'Freier Wildbahn', das waren dann aber in der Regel mobil CPUs, die mit um die 2V oder sogar weniger liefen...
Es ist nicht auszuschließen, dass man das gelassen hat, weil viele Boards offiziell nicht weniger als 2V zugelassen haben und die CPUs daher nicht wirklich in den Freien Handel kamen. Es gibt sie aber durchaus...
Gut, der K6-3+ ist wirklich selten, der K6-2+ weniger...

€dit:
Oh und zu diesem 'Flip Chip Bullshit': DAS ist ein verdammt alter Hut, denn bevor Intel mit den FC-PGA CPUs kam, waren schon andere Hersteller vor denen auf die Idee gekommen, das Die auf die Oberseite zu bauen (und dort dann 'nen Deckel drauf zu tun).
Der erwähnte K6 ist zum Beispiel so ein Beispiel. Wobei hier der Deckel richtig bescheiden war...
Einen K6-166 konnt man ohne Deckel 'mal eben' so mit 233MHz laufen lassen...

robbitop

2014-05-15, 17:12:39

Ich meine keine regulären K6-2+/+3. Die hatten Aluminium-Interconnects. Ich meine schon ganz wenige spezielle Testwafer, die durch die Fab30 liefen.

Ich habe nochmal ein wenig nachgelesen und habe rausgefunden, dass damalige Software häufig für den Pentium optimiert war, wodurch es die Mitbewerber deutlich schwerer hatten.

Intels Pentium war eigentlich keine besonders tolle µ-Arch, wenn man bedenkt, dass der K5 und der 6x86 von Cyrix damals schon OoO Architekturen hatten, die zumindest im Int-Bereich bis zu 50 % mehr IPC hatten.
Aber die Pentiums waren oftmals höher taktbar und die SW war für sie besser optimiert.

War die K5 FPU auch nicht pipelined?

z3ck3

2014-05-16, 06:41:59

Ich habe nochmal ein wenig nachgelesen und habe rausgefunden, dass damalige Software häufig für den Pentium optimiert war, wodurch es die Mitbewerber deutlich schwerer hatten.

Wenn ich mich richtig erinnere gab es solche Optimierungsprobleme öfters und auch noch später. Zuletzt hatte ich das mal im Zusammenhang mit VIA und Intel Compilern gelesen wenn ich mich richtig erinnere.

Ich kann mir vorstellen das durch fehlende Optimierungen für AMD Prozessoren diese alleine dadurch 5-10% weniger Leistung erbringen. Aber ist natürlich reine Spekulation. Fakt ist natürlich das bei einer solchen Marktübermacht auch gerne aus finanziellen Gründen die Alternativen stiefmütterlich behandelt werden, hauptsache es läuft.

Exxtreme

2024-04-14, 22:11:25

xCBrtopAG80

ThePrimagen verreisst mit Casey Muratori einen Artikel im Internet. Da erfährt man aber so viel wie x86 funktioniert. IMHO sehr empfehlenswert auch wenn das über eine Stunde dauert.

][immy

2024-04-14, 22:55:20

https://youtu.be/xCBrtopAG80

ThePrimagen verreisst mit Casey Muratori einen Artikel im Internet. Da erfährt man aber so viel wie x86 funktioniert. IMHO sehr empfehlenswert auch wenn das über eine Stunde dauert.

Ist im Grunde aber Quatsch. Heutige Limitierungen haben nichts mit x86 zu tun, sonst wären andere schon vorbei gezogen.
X86 ist sowieso nicht mehr das, was es vor 30 Jahren war.

Probleme ergeben sich eher durch Inkompatibilitäten, ließe sich aber mit emulation weitestgehend beheben. Bisher gab es auf alle Fälle keine Architektur die so vielseitig und gleichzeitig performant war. Und sobald man mit arm & Co in die gleichen Phären kommt ist man auf ähnlichen Energieleveln oder extrem großen und teuren Dies.

Ganon

2024-04-15, 09:24:43

Der zugrundeliegende Artikel ist aber auch schon Quark^10 und voller Fehler bzw. fehlerhafter Annahmen. :ugly:

Sonyfreak

2024-04-15, 09:45:23

Ein interessanter Artikel zu dem Thema: https://chipsandcheese.com/2024/03/27/why-x86-doesnt-need-to-die/

mfg.

Sonyfreak

Badesalz

2024-07-13, 10:19:30

Hat Jim Keller - schon bei RISC-V - in irgendeinem YT-Interview einmal nicht erzählt, daß der x86 auch nochmal eine andere Nummer wäre, wenn man alles an Kompatibilität zu dem was mit und halt auch vor Win98 lief und heute noch funktioniert, komplett wegwerfen würde?

robbitop

2024-07-13, 10:30:47

Klar - x86 schleppt viele Altlasten mit und die haben auch Einfluss darauf welche Randbedingungen es für die Decoder gibt.

Aber der große Nimbus der ISA zuzuordnen ob damit eine sparsame oder besonders schnelle CPU möglich ist, ist praktisch eine urbane Legende (zumindest in Zeiten moderner CPUs mit decodern und so modernen nodes dass der Unterschied zwischen denen quasi nicht mehr relevant ist - in den 80ern und 90ern hat das sicherlich noch gestimmt).

Heute ist ARM bei den meisten Leuten für Energieeffizienz im Hinterkopf. Liegt aber nicht an der ISA sondern daran, dass die CPUs für Smartphones alle dieses Instructionset haben und man einen CPU Core auslegen musste, der bei besonders niedrigen Powerenvelopes gut skalierte. x86 CPUs waren lange Zeit im Desktop und im Notebook zu Hause. Entsprechend haben sie eine Größenordnung mehr TDP zur Verfügung in denen sie gut skalieren konnten.

Man kann auch eine ARM CPU für Desktop TDPs entwickeln die sich dann in etwa so verhält von der Effizienz wie heute x86 CPUs und umgekehrt.

CPUs sind Auslegungssache. Sie skalieren nur über einen gewissen TDP Bereich gut. Will man darüber oder darunter muss man eine andere CPU entwerfen.
Mit unterschiedlichen CPU Cores in einem Die kann man theoretisch viel breiter skalieren - also über eine breitere Skalierung im guten Betriebspunkt bleiben. Intels bisherige Ansätze waren dazu nicht besonders gut umgesetzt. Bei ARM selbst war es auch nicht so toll weil die small Cores nicht so extrem sparsam für ihre kleine Leistung waren (in order cores bis heute). Einzig Apple hat das bis dato sehr gut umgesetzt.

Fliwatut

2024-07-13, 11:28:00

Kann man die Altlasten denn nicht mal rauswerfen? Dann sind neue CPUs eben nicht mehr mit uralter DOS-Software kompatibel, die Kompatibilität könnte man doch softwareseitig emulieren.

Der_Korken

2024-07-13, 11:50:56

Kann man die Altlasten denn nicht mal rauswerfen? Dann sind neue CPUs eben nicht mehr mit uralter DOS-Software kompatibel, die Kompatibilität könnte man doch softwareseitig emulieren.

https://www.pcgameshardware.de/CPU-CPU-154106/News/x86S-Intel-neuer-Befehlssatz-64-Bit-Systeme-1420206/

Pläne gibt es, aber so einfach dürfte das nicht werden, weil in jeder x86-Binary ja theoretisch noch irgendeine Legacy-Instruktion drinstecken kann. Es würde vieles brechen - zwar nicht so wie der Schritt x86 -> ARM, aber trotzdem nichts, was man mal eben schnell ändern könnte.

robbitop

2024-07-13, 11:57:58

Die Frage ist auch ob es viel bringen würde.

Badesalz

2024-07-13, 12:25:02

Exxtreme

2024-07-13, 12:26:58

Kann man die Altlasten denn nicht mal rauswerfen? Dann sind neue CPUs eben nicht mehr mit uralter DOS-Software kompatibel, die Kompatibilität könnte man doch softwareseitig emulieren.

Die Altlasten sind da drin weil sie nützlich sind. Warum also nützliche Dinge rauswerfen und die Abwärtskompatibilität brechen? Nur so als Selbstzweck?

Fliwatut

2024-07-13, 12:34:21

Um Platz und Strom zu sparen? Ich stelle mir eine OS-Schicht vor, die den alten Kram emuliert, bei Apple geht das doch auch.

robbitop

2024-07-13, 12:37:08

Ja? In jenem Interview sagte er lachend, daß wenn man einem Laien eine noch recht grobe Abbildung zeigen und erklären würde, er den x86 eher für ein EEPROM als für eine CPU halten würde :wink:

Sonst hätte ich gesagt, daß ein Jim Keller eher nicht für urban legends bekannt ist... Auch wenn er damit nicht meinte, sowas würde dann die M von Apple vernichten. Darum ging es auch nicht bei der Aussage.

Jim Keller hat iirc in dem Interview nichts gegenteiliges zu dem von mir geschriebenen gesagt. Er meinte iirc dass die x86 ISA verglichen mit riscv und ARM komplexer/komplizierter ist. Aber dass das heutzutage noch echte Relevanz für das Endprodukt hat hat er nicht gesagt. IIRC hat er sogar eher angedeutet, dass man mit allen ISAs gute CPUs bauen kann. Und wenn man sich bei einem modernen Core in einem leading edge Prozess mal anschaut wie wenig Fläche ein decoder einnimmt - dann gibt es da auch aus Flächensicht nicht so viel zum Einsparen mehr relativ zu anderen IP Blöcken auf modernen SoCs.

Exxtreme

2024-07-13, 12:42:14

Um Platz und Strom zu sparen? Ich stelle mir eine OS-Schicht vor, die den alten Kram emuliert, bei Apple geht das doch auch.

Es ist fraglich ob das großartig Strom spart. Und Emulation auf OS-Level ist beträchtlich teurer denn Funktionalität direkt in Hardware.

Der_Korken

2024-07-13, 13:02:24

Und wenn man sich bei einem modernen Core in einem leading edge Prozess mal anschaut wie wenig Fläche ein decoder einnimmt - dann gibt es da auch aus Flächensicht nicht so viel zum Einsparen mehr relativ zu anderen IP Blöcken auf modernen SoCs.

Die ISA wirkt sich nicht nur auf die Decoder aus. Wenn du eine organisch gewachsene ISA mit zig Extensions hast, dann hast du wahrscheinlich einen ineffizient genutzten instruction space. Bei variable length encoding müssen die Instruktionen ja präfixfrei sein, um sie eindeutig dekodieren zu können. Das verschwendet also Platz im L1I. Außerdem kann eine ISA z.B. durch die Anzahl der logischen Register limitiert sein. Die Compiler können nur diese Register nutzen und alles was nicht reinpasst, muss über Loads/Stores ausgelagert werden. Die CPU muss dadurch entweder viele Daten in den Cache schaufeln, obwohl vielleicht noch jede Menge ungenutzte physische Register vorhanden wären oder den Code selbstständig analysieren, um Store-Load-Kombinationen im Voraus zu erkennen und die Daten eigenmächtig in Registern unterbringen. Auch das ist sicher nicht gerade leicht.

Ansonsten wäre es sicherlich auch mal angebracht die 4K Page Size aufzustocken. Das ist zwar nicht so ganz ISA-spezifisch, da Intel und AMD auch 2M- und 1G-Pages für x86 unterstützen, aber wenn man schon Änderungen an der ISA macht, könnte man auch gleich eine größere Page Size als default etablieren (z.B. 64K).

Fliwatut

2024-07-13, 13:55:03

Es ist fraglich ob das großartig Strom spart.
Warum laufen dann Notebooks mit Apples M-Chips so lange auf Batterie und haben kaum einen Leistungseinbruch, wenn man sie vom Netz trennt?

HOT

2024-07-13, 13:58:45

Die Altlasten (das A20 Gate ist ja vor Jahren rausgefolgen, das war wirklich Mist) sind von Größe und Verbrauch her komplett irrelevant. Intel gehts nicht darum, die Architektur zu verschlanken sondern um Patentschutz.

Exxtreme

2024-07-13, 14:28:20

Warum laufen dann Notebooks mit Apples M-Chips so lange auf Batterie und haben kaum einen Leistungseinbruch, wenn man sie vom Netz trennt?

Weil Apple bei den M-Chips andere Prioritäten setzt als Intel und AMD.

Skysnake

2024-07-13, 14:35:59

Mit der eigentlichen ISA haben die heutigen HochleistungsCPUs nur noch wenig zu tun.

Da wird nen Haufen Shit gemacht. Ein Vorteil von CISC ist halt die hohe Informationsdichte im Code. Hat alles seine Vor/Nachteile.

Und mit Microcode bekommt man auch viel RISC feeling nah an den Execution Einheiten.

Ich würde mir da absolut nichts erwarten, was auch nur irgend eine verlorene Kompatibilität rechtfertigen würde.

Zudem wurden Komplexe Sachen wie die x87 FPU ja auch schon rausgeworfen. Das emuliert man aber halt nicht auf OS Level sondern direkt in der CPU. Die ist heutzutage eh flexibel genug um das zu können.

Badesalz

2024-07-13, 14:37:51

IIRC hat er sogar eher angedeutet, dass man mit allen ISAs gute CPUs bauen kann.Du bist doch genauso erwachsen wie ich.. Es ist wohl klar, daß wenn er jetzt bei Tenstorrent am RISC-V schraubt, er nicht über x86 herziehen wird und will. Diese ultrabreite Flanke an Kritikpotenzial an einem selbst wird er mit Sicherheit nicht öffnen. Glasklar oder?

Weil Apple bei den M-Chips andere Prioritäten setzt als Intel und AMD.Das ist keine Erklärung für die gestellte Frage :usweet:

Exxtreme

2024-07-13, 14:42:55

Das ist keine Erklärung für die gestellte Frage :usweet:

Natürlich ist es das. X-D

Es ist so wie robbitop das geschrieben hat: eine CPU-Architektur skaliert nicht unendlich von supersparsam zu extrem schnell. Man muss Prioritäten setzen was einem wichtiger ist. Apple hat die Priorität auf extrem gute Sparsamkeit gesetzt und dem so ziemlich alles untergeordnet. AMD und Intel machen das halt nicht. Die setzen auf maximale Rechenleistung.

Badesalz

2024-07-13, 15:01:24

Apple hat die Priorität auf extrem gute Sparsamkeit gesetzt und dem so ziemlich alles untergeordnet.D.h. du hast noch garnicht mitbekommen wie Apple grad auch in den Anwendungen die es - teils auch schon ewig - für Wintel wie OSX gibt, gegenüber x86 performt? :|

Fliwatut

2024-07-13, 15:04:00

Weil Apple bei den M-Chips andere Prioritäten setzt als Intel und AMD.
Welche Rolle soll das spielen? Du meintest, es wäre fraglich, dass das großartig Strom spart. Apple hat aber bewiesen, dass es Strom spart, bei gleichzeitig besserer Leistung und weniger Abwärme.

Exxtreme

2024-07-13, 15:14:37

D.h. du hast noch garnicht mitbekommen wie Apple grad auch in den Anwendungen die es - teils auch schon ewig - für Wintel wie OSX gibt, gegenüber x86 performt? :|

Anwendungen vielleicht, Spiele aber schonmal nicht.

Hier einige Vergleiche:
https://www.golem.de/news/macbook-pro-14-mit-m3-und-m3-max-im-test-perfektion-ist-nicht-guenstig-2311-179196-2.html

robbitop

2024-07-13, 15:16:21

Die ISA wirkt sich nicht nur auf die Decoder aus. Wenn du eine organisch gewachsene ISA mit zig Extensions hast, dann hast du wahrscheinlich einen ineffizient genutzten instruction space. Bei variable length encoding müssen die Instruktionen ja präfixfrei sein, um sie eindeutig dekodieren zu können. Das verschwendet also Platz im L1I. Außerdem kann eine ISA z.B. durch die Anzahl der logischen Register limitiert sein. Die Compiler können nur diese Register nutzen und alles was nicht reinpasst, muss über Loads/Stores ausgelagert werden. Die CPU muss dadurch entweder viele Daten in den Cache schaufeln, obwohl vielleicht noch jede Menge ungenutzte physische Register vorhanden wären oder den Code selbstständig analysieren, um Store-Load-Kombinationen im Voraus zu erkennen und die Daten eigenmächtig in Registern unterbringen. Auch das ist sicher nicht gerade leicht.

Ansonsten wäre es sicherlich auch mal angebracht die 4K Page Size aufzustocken. Das ist zwar nicht so ganz ISA-spezifisch, da Intel und AMD auch 2M- und 1G-Pages für x86 unterstützen, aber wenn man schon Änderungen an der ISA macht, könnte man auch gleich eine größere Page Size als default etablieren (z.B. 64K).

Ich sage ja nicht dass kein Optimierungsspielraum besteht. Aber das ist pro Core auf N3 sicherlich <<1 mm2.

robbitop

2024-07-13, 15:18:03

Du bist doch genauso erwachsen wie ich.. Es ist wohl klar, daß wenn er jetzt bei Tenstorrent am RISC-V schraubt, er nicht über x86 herziehen wird und will. Diese ultrabreite Flanke an Kritikpotenzial an einem selbst wird er mit Sicherheit nicht öffnen. Glasklar oder?

Tenstorrent nutzt riscv. Es gibt zu x86 also keinen Interessenskonflikt der für mich sichtbar ist. Außerdem ist Jim dafür bekannt ziemlich straight forward zu sein und kein typischer Manager mit Sinn für policy.

Ganon

2024-07-13, 15:26:16

Kann man die Altlasten denn nicht mal rauswerfen? Dann sind neue CPUs eben nicht mehr mit uralter DOS-Software kompatibel, die Kompatibilität könnte man doch softwareseitig emulieren.

Siehe: https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

edit: Huch, da war ja noch eine zweite Seite im Thread hier.

Der_Korken

2024-07-13, 16:25:56

Welche Rolle soll das spielen? Du meintest, es wäre fraglich, dass das großartig Strom spart. Apple hat aber bewiesen, dass es Strom spart, bei gleichzeitig besserer Leistung und weniger Abwärme.

Darüber kann man nur spekulieren, aber ein Blick auf die Blockdiagramme der betroffenen Cores sagt vielleicht schon einiges aus (Post von regularhandluke ganz unten):

https://www.reddit.com/r/computerarchitecture/comments/1czh4az/where_to_find_cpugpus_architecture_block_diagrams/?rdt=39540

Was auffällt: Der M4-P hat 10 Decoder, 8 INT-Ports und eine ROB-Size von >900, wenn ich das richtig interpretiere. Zen 4 hat z.B. nur 4 INT-Ports, 4 Decoder und 320 ROB-Size. Andererseits haben beide nur 4 FP-Pipes und 3 Load-Units, wobei AMD 64B/c aus dem L1 laden kann (Intel sogar 128B/c), während Apple nur 48B/s schafft. Daraus schließe ich, dass Apples FP-ALUs nur 128b breit sind, während AMDs seit Zen 2 schon 256b breit sind (und Intel seit Haswell, also >10 Jahre). Zudem sind AMDs FP-Register auch alle 512b breit, bei ARM kenne ich mich nicht so aus, aber 512b werden es bei den schmalen ALUs wohl nicht sein.

Soll heißen: Apple spart da, wo es ordentlich Strom, Platz und Takt kostet, nämlich viel IO und breite Vektoroperationen (man darf nicht vergessen, dass AMD deutlich höher taktet und ein Gleichstand bei der FPU-Breite somit ein Vorteil für AMD ist). Dazu kommt, dass Apple es sich durch den hohen IPC-Vorsprung "leisten" kann, ihre Kerne nicht auszufahren und dadurch gerade bei ST-Lasten extrem effizient ist. So effizient, dass die Kerne auch im Akkubetrieb nicht merklich runtertakten müssen.

Ich denke, dass AMDs Kerne das auch könnten, denn man sieht ja am 7800X3D wie sparsam so eine CPU selbst unter Volllast sein kann (wenn man den saufenden Dektop-SoC und die Verluste über die Chiplet-Anbindung mal abzieht). Hätte AMD aber Zen 4 bei 4,7Ghz gedeckelt, wie z.B. beim 8400F (https://www.pcgameshardware.de/Ryzen-7-8700F-CPU-280504/Tests/APU-Mobile-Desktop-Phoenix-Review-1450790/3/) mit 5W/Core unter Volllast, würden jetzt alle über die schwache ST-Leistung jammern. Sparsam wären die aber gewesen.

Mit ARM vs x86 hat das imho nur am Rande zu tun. Hätte AMD bei Zen 5 komplett auf AVX geschissen und stattdessen nur in ST-Decode, INT-ALUs, ROB und Sprungvorhersage investiert und vllt. 25-30% IPC in leichten Nicht-Vektorlasten rausgeholt, wären sie in ähnlichen Gefilden gelandet wie Apple. Offensichtlich ist AMD aber AVX-Power und SMT-Performance wichtiger, weil das in Servern gebraucht wird - zu Lasten der Desktop-User.

Ich sage ja nicht dass kein Optimierungsspielraum besteht. Aber das ist pro Core auf N3 sicherlich <<1 mm2.

1mm² pro Core ist schon sauviel, da Zen 4 ohne L2 und L3 schon <3mm² groß ist :tongue:

Aber im Ernst: Ja, es würde in Summe nicht viel sparen und wenn es sich lohnen würde, würden es Intel oder AMD stärker pushen. Ich denke aber, dass die Altlasten mit jeder Generation ein kleines bisschen stärker zwicken und irgendwann der Punkt erreicht sein wird, wo man die ISA aufräumt, weil man dadurch 1-2 CPU-Generationen an Flächen-/Energieeffizienz rausholt.

robbitop

2024-07-13, 16:51:48

Jo und es wird dadurch noch einfacher weil der legacy Kram von Jahr zu Jahr immer älter und immer mehr an Bedeutung verliert.

Badesalz

2024-07-13, 22:03:00

Anwendungen vielleicht, Spiele aber schonmal nicht.Wenn ich mich über etwas ernsthaft unterhalten will was nicht mit Spielen zu tun hat, dann rede ich auch nicht von Spielen. Ehrlich mal...

Tenstorrent nutzt riscv. Es gibt zu x86 also keinen Interessenskonflikt
Doch mal so garnicht nicht verstanden... OK :rolleyes:

ChaosTM

2024-07-13, 22:08:36

https://youtu.be/xCBrtopAG80

ThePrimagen verreisst mit Casey Muratori einen Artikel im Internet. Da erfährt man aber so viel wie x86 funktioniert. IMHO sehr empfehlenswert auch wenn das über eine Stunde dauert.

Es wird und muss passieren, auch wenn das viele nicht haben wollen.
Erinnert mich an die Verbrenner vs. E-Mobilitäts-Geschichte -> weils ja immer schon so war !?

Bin froh, dass Apple den Schnitt gemacht hat

.

Der_Korken

2024-07-13, 22:11:26

Es wird und muss passieren, auch wenn das viele nicht haben wollen.
Erinnert mich an die Verbrenner vs. E-Mobilitäts-Geschichte -> weils ja immer schon so war !?

.

Ein kruderer Vergleich ist dir wohl nicht eingefallen?

Exxtreme

2024-07-13, 22:12:19

Es wird und muss passieren, auch wenn das viele nicht haben wollen.
Erinnert mich an die Verbrenner vs. E-Mobilitäts-Geschichte -> weils ja immer schon so war !?

Die Verbrenner vs. E-Auto Geschichte ist eine ganz andere. Erstens, E-Autos sind älter als Verbrenner, also viel unmoderner. Und zweitens, x86 ist da weil es sich auf dem Markt durchgesetzt hat. E-Autos sind nur da wegen Staatsinterventionen.

robbitop

2024-07-13, 22:17:31

Doch mal so garnicht nicht verstanden... OK :rolleyes:

Dann erkläre es. ;)

ChaosTM

2024-07-13, 22:19:59

Momentan brauchts noch Investitionen (in die Zukunft), da es noch nicht genug EE und günstigeren Speicher gibt, aber das Problem löst sich in den nächsten paar Jahren von selbst.

Die Dino Lobby (Petro und CISC) versucht natürlich alles um das zu verzögern. Sie können aber nicht gewinnen auf längere Sicht.

Das effizientere System setzt sich früher oder später immer durch.. -> Evolution

Badesalz

2024-07-13, 22:24:13

Dann erkläre es. ;)Das würde am Telefon gehen ;) Ein Geschreibsel zu DEM Thema sprengt hier selbst meine Lust am hämmern. Sorry.

Leonidas

2024-07-22, 07:10:52

Ich kann mich noch an Zeiten erinnern, da war "Nehalem" ein weit entferntes Zukunftsgerücht (als Pentium-4-Fortsetzung mit Taktraten von 5-10 GHz beschrieben). Nun ist Nehalem inzwischen längst vorbei ...

Geschrieben am 2. Mai 2014. Wiedergefunden am 22. Juli 2024 ;)

Badesalz

2024-07-22, 07:49:06

Die Dino Lobby (Petro und CISC) versucht natürlich alles um das zu verzögern. Verpeilt. daß so ein Rajsän nur noch ganz am Rande ein CISC ist?

Zossel

2024-07-22, 10:21:57

...wobei der K6 auch arge Probleme mit Windows 95 mit der Zeit hatte...
Das ganze war aber eher M$ Schuld, die irgendwelche Timer so programmiert haben, dass es bei zu hohem Takt zu Problemen kommen kann. Das war beim K6 relativ früh der Fall.

Integer Überlauf in einer Verzögerungsschleife, Compilate von Borland Compilern hatten auch dieses Problem.
Damals war auch die Verfügbarkeit von brauchbaren HW-Timern in in PCs, gelinde gesagt, schwierig, es gab nur den PIT (https://de.wikipedia.org/wiki/Programmable_Interval_Timer) der lediglich ~18,2 mal (ganzzahliger Teiler eines Never The Same Color Taktes) pro Sekunde einen Interrupt auslösen konnte.

Das war damals die einzig nutzbare Zeitbasis in PCs.

Zossel

2024-07-22, 10:34:13

[immy;13524961']Probleme ergeben sich eher durch Inkompatibilitäten, ließe sich aber mit emulation weitestgehend beheben. Bisher gab es auf alle Fälle keine Architektur die so vielseitig und gleichzeitig performant war. Und sobald man mit arm & Co in die gleichen Phären kommt ist man auf ähnlichen Energieleveln oder extrem großen und teuren Dies.

Das Design von ARM ist allerdings auch schon veraltet:

This decision is motivated in the fact that flags or other means of handling it add a lot of complexity to Out-of-order micro architectures.

https://stackoverflow.com/questions/70999565/why-does-risc-v-not-have-an-instruction-to-calculate-carry-out

Zossel

2024-07-22, 10:39:53

Um Platz und Strom zu sparen? Ich stelle mir eine OS-Schicht vor, die den alten Kram emuliert, bei Apple geht das doch auch.

Auch Treiber (Z.b. für USB-Gadgets) im Kernel-Space?

Zossel

2024-07-22, 10:42:50

Exxtreme

2024-07-22, 10:45:24

Verpeilt. daß so ein Rajsän nur noch ganz am Rande ein CISC ist?

Und der Witz ist, dass selbst RISC-CPUs nicht wirklich RISC sind. Auch diese haben Decoder, die ihre Anweisungen noch weiter zerlegen.

nonharderware

2024-07-22, 11:06:43

Ich denke die CPUs der Zukunft werden immer weniger CPU sein.
Eher dCPUs - deCentralProcessingUnits.

Wo ein kleiner Managementhub mit einem rudimentären 2c Chip sitzt, welcher alle weiteren Teile des Rechenwerks nur noch nach Bedarf einschaltet.

---

Mir kommt schon das Grauen, vor "dCPUs as a service" - du kaufst 2030 um EUR 100,- (inflationsbereinigt wären dies heute EUR 2,58 :freak:) so eine CPU und dazu ein Abo - welches dir eben gewisse Rechenwerke gönnt.
Für die richtig G'stopften gibt es dann die Flatrate dCPU für ein Jahresghehalt und dann sicher noch ein Abo, bei denen du nach Nutzung der Rechenwerke zahlst...
Also einmal einen rechenintensiven Bench angeschmissen? Pech, dann pfänden sie dir morgen die Einrichtung...

Echt, mich kotzt diese Entwicklung sowas von an :P

Badesalz

2024-07-23, 08:57:50

Und der Witz ist, dass selbst RISC-CPUs nicht wirklich RISC sind. Auch diese haben Decoder, die ihre Anweisungen noch weiter zerlegen.Auch andere Ansätze haben sich eher nicht durchgesetzt :wink:
" Itaniums EPIC-Architektur stellte den radikalen Versuch dar, Hardwarekomplexität in die Softwareoptimierung zu integrieren. Die gesamte Arbeit zur Bestimmung der parallel auszuführenden Anweisungen wurde vom Compiler erledigt, ehe die CPU auch nur ein Byte an Code ausführte."

https://www.elektronikpraxis.de/epic-fail-20-jahre-intel-itanium-a-e9ef14fb2ac60c6620bd2790f1359de7/
https://www.bernd-leitenberger.de/Itanium.shtml

Jetzt aber auch mal kurz enger am Topic :smile:
Wo steht nicht nur der x86,sondern die CPU überhaupt? Das ist bisher immer so gewesen und auch weiter so (?), daß die Consumer vom Gabentisch der Serversparten gefüttert werden. Die Frage wäre jetzt wie sich da diese Situation weiterentwickelt.

Es sieht so aus, als wenn die CPU als solche an Bedeutung verliert, weil sie auf die Art wie sie ihre Sachen macht, hinter den Anforderungen nicht mehr hinterherkommt. Ohne jetzt KB-weise den Gedanken zu erklären, zwei rhetorische Fragen dazu:
Warum hat AMD Pensando und Xilinx gekauft?
Was ist Bluefield + Doca?

Auch Intel weiß es. Daher gibt es da einen ganzen Haufen von CPU + X. DSA, QAT, IAA, XMX, (AVX bekanntlich), DLB und, vRAN Boost (ufff :usad:) Das ist echt so einiges...

Und wenn man doch rein mit compute ballern will, scheint die Lösung immer mehr ein Mi300A zu sein. Oder wenigstens sowas wie GB200. Und die gelten nicht nur der KI-Blase (*)

Könnte es also sein, daß sich zukünftig die klassische CPU, der Verteilung der Aufgaben folgend, und der damit gesunkenen Notwendigkeiten, eher ähh..., leicht rückentwickeln wird? :freak:
Beobachten wir das nicht schon ähnlich und im Kleinen (und Speziellen) bei den Game-Engines? Ok als Ex-Gamer schätze ich das grad nur, aber mir scheint es, als wenn das Verhältnis für sinnige Paarungen zwischen GPU-Leistung und der CPU-Leistung eher konstant größer wird im Vergleich zu früher.

(*) Wieviel machen "sequential algorithms" und "complex statistical computations" in den Rechenzentren noch aus?