AMD K12 -Spekulation

[Duplex]

Penryn & Ivy Bridge habe ich absichtlich ausgelassen, das sind keine neuen Architekturen, sondern nur Ticks.

 

[unl34shed]

Wenn es so weiter geht, legt Skylake ~5% IPC drauf.

Und du verwekselst CMT mit Bulldozer
CMT skaliert nämlich recht gut.
Die schlechte Singlethread leistung und daraus auch Spieleleistung sind Desingentscheidungen, die mit der Technik CMT aber erstmal nichts zu tun haben.

 

[Atombossler]

AMDs CMT ist der größte reinfall von AMDs Geschichte gewesen, schwache Singlethread Performance, schlechte Performance in Games, gegen ein Server Modell von Intel mit 8C/16T braucht AMD mehr als 20 Kerne um Balken zeigen zu können, dabei sind die Prozessoren richtig ineffizient weil man keine gescheite Fertigung hat.

Das ist definitiv Schwachsinn. Man sollte eben wissen wofür man die Maschine braucht.
Vergiss mal den ganzen Daddelkram, das ist keine ernste Anwendung. An CMT per Se liegt es auch überhaupt nicht, allein die Umsetzung ist noch nicht ausgereift.
Guck einfach mal x264 an, was musst Du denn da einem FX9590 entgegensetzen um mithalten zu können, geschweige denn schneller zu sein ( und da ist die Zählweise
ganz egal, seien es nun 4 Module vs 6 Cores, oder eben 8 Threads vs deren 12). Fakt ist, es ist ein Vielfaches teurer mit Intel gleich schnell zu sein und in dem Falle
hat sogar der Intel die mehr Kerne ...
An irgend etwas nebenher noch damit machen zu wollen kannst du bei Intel dann gleich ganz vergessen, mit AMD absolut kein Problem, dank CMT.
Oder nimm eben Virtuelle Maschinen, wenn dir x264 zu AMD "freundlich" (?) ist, fahr mal einen Host mit 3 VM's und vergleich mal die Leistungsfähigkeit.
Da brauchts nicht mal einen Benchmark dafür, das ist sowas von "fühlbar", da erübrigt sich jede Diskussion.
Aber Hauptsache Skyrim läuft mit 500+ fps ...
Jo, schon klar.

 

[ONE_FOR_ALL]

Echt Duplex man kann deine Frasen schon nicht mehr hören.

 

[gruffi]

Du hast mich falsch verstanden, unabhängig von der Software, ich meinte nur das die Architektur von K12 & ZEN ähnlich ausfallen sollte, also viele Gemeinsamkeiten, (Pipeline, Cache, FPU, Taktraten) könnte bei beiden Designs ähnlich sein, nur das man bei K12 auf ARM Decoder und bei ZEN auf x86 Decoder setzt, also eine Architektur für beide Gebiete.

Das ist doch völlig irrelevant. Hier geht's um K12, der erst mal für ARM Server kommen soll (später vermutlich auch für ARM Clients). Und du verlinkst einen Artikel zu Broadwell-E, also eine Prozessorserie einer x86 Desktop High-End Plattform, um damit sinnfrei zu provozieren. Dass das nicht zusammenpasst, sollte doch auch dir auffallen. Welche Prozessoren im Server- und Clientmarkt ab 2016 miteinander konkurrieren werden, hängt auch nicht nur von der Architektur ab, sondern vom gesamten Design. Wenn Zen mit zB lediglich 2 Kernen kommt, dann wird das kein Broadwell-E Konkurrent sein. Wenn er mit 8 oder gar 16 Kernen kommt, dann kann das schon wieder anders ausschauen. An der Stelle interessiert es nicht im geringsten, ob K12 und Zen bis auf die Decoder gleich sein sollten.

Bezogen auf den x86 Markt sehe ich trotzdem kaum Fortschritte die sich im Vergleich zu Intel durchsetzen können

Du bist immer noch im falschen Thread. Hier geht's um K12 und der basiert bekanntlich auf ARM. Was willst du uns da mit x86 erzählen? Du hast im ursprünglichen Beitrag auch nichts explizit von x86 gesagt, sondern allgemein von Fortschritten gesprochen. Und da gibt's bei AMD wie gesagt genügend. Im Gegensatz dazu sehe ich von Intel ausser Quersubventionierung ihrer unterlegenen Tablet und Smartphone Prozessoren nicht viel. Eigentlich eine recht armselige Vorstellung von denen.

Die neuen Befehlssätze die der K10 nicht hat, die hat man wieder nur von Intel kopiert

Welche denn? XOP? Du wirst dich vielleicht nicht erinnern, aber AMD kam zuerst mit SSE5, wozu sich Intel genötigt gefühlt hat, AVX zu bringen. Man sollte AMD dankbar sein, dass sie es übernommen haben, damit nicht noch mehr Inkonsistenz hinzukommt.

Seit 6 Jahren gibt es bei AMD keine Fortschritte im x86 Bereich, die Leistung pro takt von Steamroller ist nicht höher als ein Phenom II von 01/2009.

Dafür hast du aber deutlich mehr Takt gegenüber einem X4 940 und bis zu doppelt so viele Threads. Bei Intel hast du weniger zusätzlichen Takt und halt etwas mehr IPC, die allerdings auch nichts wirklich rausreisst. An 4C/8T hat sich seit Nehalem Ende 2008 nichts geändert im Mainstreamsegment. Wo ist da bei Intel jetzt mehr Fortschritt? Die stagnieren deiner Argumentation nach genauso.

Bei Intel skaliert die Architektur bis jetzt ganz gut nach oben.

Core2 > Nehalem +30% > Sandy Bridge +15% > Haswell +10% > Skylake...

Das kann ich jetzt genauso für AMD machen. Ab 2006 (Core2):

K8 > K10 +20% > Thuban +35% > Bulldozer +20% > Zen...

Hey, AMD hat sogar 20% mehr gewonnen im Laufe der Zeit. So kann man immer wieder neue Server & Desktop Modelle mit mehr Leistung verkaufen.

AMDs CMT ist der größte reinfall von AMDs Geschichte gewesen

Wieder mal völliger Schwachsinn. Du verstehst CMT einfach nur nicht und flüchtest dich in haltlose und abgedroschene Phrasen. CMT ist mit das beste an Bulldozer und skaliert deutlich besser als Intels Hyperthreading. Genauso wenig kann man Bulldozer per se als ineffizient abstempeln. Wenn man die Taktraten hoch genug dreht, wird jeder Chip irgendwann recht ineffizient. Vielleicht solltest du langsam mal kapieren, dass es nicht nur FX-8150/8350 gibt. Es gibt auch Modelle mit weniger Takt, die gemessen an ihrer Leistungsaufnahme sehr gute Performance liefern. Sieht man auch gut bei den APUs. Und mittlere Last oder Niedriglast ist auch nochmal eine andere Geschichte als die von Testseiten oft kolportieren Extremlastszenarien.

 

[hot]

Dass es grade Spiele trifft, weist eindeutig auf I/O und Latenzen hin, da Spiele keine hohe Rechenleistung brauchen. Nicht der Durchsatz, nicht die Cluster, nicht CMT, nicht die FPU ist die Schwäche des BD, es ist I/O-Hub mit zu niedrigen Takt, Cache-Struktur, Frontend. Frontend wurde entschärft, die anderen Punkte wiegen jetzt um so schwerer. Bei XV sieht es jetzt so aus, als würde der Cache entschärft. Allerdings passt der fette BD einfach nicht ins Interposer-Konzept, das ist meiner Ansicht nach der Grund, warum er aussortiert wird.

 

[gruffi]

Das sage ich ja schon lange. Die Architektur ansich ist sehr leistungsfähig. Es klemmt bei der I/O bzw konkret Speicheranbindung. Auch wenn das einige nie hören wollten. Intel hat einfach deutliche Vorteile beim Cache. Das hat schon dem Core2 ordentlich geholfen. Und seit Intel den FSB mit Nehalem über Bord geworfen hat, haben sie bei der RAM Anbindung keine Nachteile mehr. Im Gegenteil, sogar einige Vorteile. Wobei AMD da auch wieder etwas angezogen hat mit den letzten Generationen. Mit Steamroller haben sie auch den L2 entschärft. Dessen Durchsatz liegt absolut auf Augenhöhe mit Haswell. Die Latenz ist allerdings nach wie vor schlechter.

 

[WindHund]

Dass es grade Spiele trifft, weist eindeutig auf I/O und Latenzen hin, da Spiele keine hohe Rechenleistung brauchen. Nicht der Durchsatz, nicht die Cluster, nicht CMT, nicht die FPU ist die Schwäche des BD, es ist I/O-Hub mit zu niedrigen Takt, Cache-Struktur, Frontend. Frontend wurde entschärft, die anderen Punkte wiegen jetzt um so schwerer. Bei XV sieht es jetzt so aus, als würde der Cache entschärft. Allerdings passt der fette BD einfach nicht ins Interposer-Konzept, das ist meiner Ansicht nach der Grund, warum er aussortiert wird.

Was beinhaltet den der I/O-Hub alles?
Darf ein Cache nicht langsamer sein wenn er ein vielfaches an Volumen aufweist?
Ein Eimer Wasser kannst auch schneller tragen, wenn er leer ist.

 

[tex_]

Nein ein Cache darf nicht langsamer sein wenn er größer ist. Nach der Logik bräuchte man ja nur den RAM und keinen Cache, der ist schließlich auch langsamer und größer als jeder Cache.
Prinzipiell gillt also eher je mehr Cachstufen desto besser. Bei Sandybridge hat man ja gesehen, dass vor allem der schnelle L3 mit vollem CPU-Takt zu deutlichen Verbesserungen geführt hat. Und Bulldozer hat die 2 Probleme, dass der L1D zu klein ist (schon alleine wegen der auf Intel optimierten Software) und dann der L2, der nicht wirklich viel schneller ist als Intels L3 dabei aber kleiner. Auf eine 3. Cachestufe muss man bei den APUs ja auch ganz verzichten. Da war leider die Cachestruktur vom Phenom2 noch deutlich besser. Der hatte vergleichsweiße riesige L1 Caches, einen ausgewogenen L2 einen relativ großen wenn auch nicht besonders schnellen L3.

Ich bin schon gespannt, was AMD hier mit dem K12 anstellen wird. Von Jim Keller ist ja eher wieder was K10 artiges zu erwarten wie man auch am Cyclone gesehen hat. Wenn man der ARM Konkurrenz vorraus sein möchte wird man hier warscheinlich auch nicht um 3 Cachestufen herum kommen.

 

[gruffi]

Cachegrösse alleine ist aber auch nicht alles. Sieht man ja bei Intels mickrigem L2. Daher bin ich nicht wirklich überzeugt davon, dass der L1D bei Bulldozer ein Problem ist. Steamrollers L2 ist auch deutlich schneller als Intels L3. Wie gesagt, da hat man deutlich hinzugewonnen gegenüber Piledriver.

Es ist einfach so, dass erstens die Latenz und zweitens die Diskrepanz zwischen Lese- und Schreibrate bei AMD nach wie vor höher ist, sowohl bei L2 als auch L3. Die L1 und L2 Leserate ist allerdings sehr gut, absolut auf Augenhöhe mit Intel bzw teils sogar besser.

Man kann auch nicht sagen, je mehr Cache-Stufen desto besser. Mehr Stufen erhöhen Komplexität und Transistorbudget. Irgendwann lohnt sich das nicht mehr und man investiert dieses Transistorbudget lieber in andere Sachen, die mehr bringen. Ich denke die Cache-Hierarchie von Bulldozer ist schon gut so. Wobei mir die von Jaguar persönlich besser gefällt. L3 ist was für Serverprozessoren. Client-Prozessoren brauchen das nicht. Erst recht mit Stacked Memory. Lieber weniger Cache-Stufen, dafür aber knackig und mit einer guten Balance aus Grösse und Latenz. Für das Transistorbudget eines grossen L3 hätte ich lieber ein paar Kerne mehr. Da darf man ruhig auch die Taktrate etwas runterschrauben, um die TDP nicht zu sehr zu strapazieren. Bei singlethreaded Workloads sollte es dank Turbo eh keine Abstriche geben.

 

[WindHund]

@tex_
Wenn der Cache größer ist hast doch auch längere signalwege.
Der L1D Cache ist bei Intel nur größer ohne HTT bzw. SMT.

Sent from my arm.

 

[Stryki]

Ich würde ja vermuten das es beim L1 am meisten Sinn macht sich an der Größe von Intel zu orientieren bzw größer zu sein wenn man das ohne Geschwindigkeitsverlust hinbekommt. Ich hab zumindest immer mal wieder gelesen das der kleine L1 beim Bulldozer ein Problem sei bei der bestehenden Software.
Die Evolution müsste wenn das so stimmt dann dahin führen den L1 wieder größer zu machen , das anpassen der Softwarelandschaft ist schon bei HSA schwierig genug.

 

[tex_]

Der K10 L1D mit 64 kB hatte auch nur eine Latenz von 3/4 Takten. Das wäre also nicht das Problem. Gegen den 8way 32 kB L1 bei Intel hat Bulldozer mit 16 kB 2way im Zweifel immer das nachsehen. Wenn es um Singlethread Leistung geht hat Intel eben auch die kompletten 32kB für einen Thread.
Der L2 von Steamroller mag jetzt auch einen besseren Durchsatz haben, aber die Latenz ist nicht besser als bei Intels L3 mit ca. 20 Takten. Und Intel kann es sich da sogar leisten einen "mickrigen" L2 als zusätzliche Cachestufe mit einzubauen.
Die Chipgröße ist natürlich letztendlich immer der begrenzende Faktor und mehr Logik macht auch immer nur in einem begrenzten Umfang Sinn. Grob kann man aber trotzdem sagen, dass wenn eine zusätzliche Stufe sich von der Geschwendigkeit her deutlich von 2 vorhandenen unterscheidet, dann bringt sie auch was. Und ich will da jetzt mit Absicht keine festen Grenzen vorgeben.

K12 um den es hier geht hat als Konkurrenz aber erst mal den Cortex-A57 und Konsorten, welche in der Regel auch schon auf 64kB große L1Ds setzen. Die Last Level Caches gehen auch schon bis 2/4 MB. AMD will in seine ersten ARM Chips mit den A-57 ja sogar einen noch größeren L3 unterbringen. Das werden sie denke ich nicht später wieder unterbieten.
Jim Kellers letztes Design, Apples Cyclone, hatte als Cachestufen 64kb/512kB/4MB. Wie man hier schon sieht also recht ähnlich zum K10. Ich kann mir kaum Vorstellen, dass K12 jetzt Richtung Bulldozer geht. Die Frage ist wohl eher ob man auf viele etwas kleinere Cores mit entsprechend kleineren L1/L2s setzt oder ob der L2 möglichweise zwischen einer größeren Anzahl an Cores shared, wie z.b. in Jaguar. Oder geht man gleich in Richtung von mind. 1 MB per Core mit zusätzlichem shared L3?
Was dann natürlich auch mit den Fragen zusammenhängt, ob man vlt. SMT oder etwas derartiges nutzen wird und welche Taktraten man erreichen möchte.

 

[Opteron]

@tex_
Wenn der Cache größer ist hast doch auch längere signalwege.

Jo, aber AMD hat den BD-L1 trotzdem nur mit 4-Takten Zugriff entworfen.
Schon witzig - aus dem vergleichsweise riesigem 64kB L1 des K10 waren die Daten dagegen schon nach 3 Takten da.
Lag natürlich auch am anvisiertem Takt, aber naja ... die nötigen 220W TDP rechtfertigen das dann am Ende auch nicht mehr.

Es wird wohl zukünftig wieder auf 64kB rauslaufen, hätte den Vorteil, dass man bei SMT noch die L1-Größe Intels hätte, auf die in den letzten Jahren vermutlich einiger Code optimiert wurde.

Man kann sogar von mehr träumen, 14nm schafft ja einiges an Platz und Steamroller hat ja schon in 32nm nen krummen 3way-96kB L1I-Cache. 4way-128kB wären also möglich. Einerseits schon verdammt viel, andererseits sind 64kB bei den ARM-Cortex schon Standard. Von denen wird sich AMD aber absetzen wollen und falls man z.B. 4fach-SMT implementieren würde, weil das Design noch breiter als Apples Cyclone wird, sollte es sich unterm Strich rechnen.

Aber naja, mal abwarten, wie besagt nur ne Träumerei, die 64kB sind sicherlich wahrscheinlicher.

Edit: tex_ war schneller

Edit2: @tex_:

Die Frage ist wohl eher ob man auf viele etwas kleinere Cores mit entsprechend kleineren L1/L2s setzt oder ob der L2 möglichweise zwischen einer größeren Anzahl an Cores shared, wie z.b. in Jaguar.

Solche Cluster wie bei Jaguar sind eindeutig die Zukunft, ein Bulldozer Modul war ja auch nix anderes. Auf die Spitze treibts aktuell Oracle deren neue Sparc-Kerne sind in Gruppen eingeteilt, bei denen sich 4 nen L2I und 2 nen L2D teilen...
http://www.theregister.co.uk/2014/08/18/oracle_reveals_32core_10_beeellion_transistor_sparc_m7/

 

[gruffi]

Die Chipgröße ist natürlich letztendlich immer der begrenzende Faktor und mehr Logik macht auch immer nur in einem begrenzten Umfang Sinn. Grob kann man aber trotzdem sagen, dass wenn eine zusätzliche Stufe sich von der Geschwendigkeit her deutlich von 2 vorhandenen unterscheidet, dann bringt sie auch was.

Aber halt auch nur, wenn die jeweilige Anwendung so viele Daten umherschaufelt, dass diese zusätzliche Stufe ausgenutzt wird. Bei 2 MB oder mehr L2 wird's da schon schwierig in typischen Client Anwendungen noch nennenswerte Zugewinne mit einem L3 zu erzielen. Da kommen dann vor allem speicherhungrige Anwendungen in Frage wie Packen oder Verschlüsselung. Und da reicht dann selbst ein L3 nicht mehr aus, so dass man sowieso in den RAM zurückfällt.

K12 um den es hier geht hat als Konkurrenz aber erst mal den Cortex-A57 und Konsorten, welche in der Regel auch schon auf 64kB große L1Ds setzen. Die Last Level Caches gehen auch schon bis 2/4 MB. AMD will in seine ersten ARM Chips mit den A-57 ja sogar einen noch größeren L3 unterbringen. Das werden sie denke ich nicht später wieder unterbieten.

Den L3 gibt's aber nur für Serverdesigns wie Seattle. Vermutlich werden die Client-Designs keinen L3 bekommen, wie auch jetzt die APUs. Wie gesagt, die Rolle des L3 übernimmt hier in Zukunft HBM.

 

[hot]

Bei Zen sitzt der L3 eh nicht mit auf dem Die, sondern im Interposer.

 

[FredD]

Bei Zen sitzt der L3 eh nicht mit auf dem Die, sondern im Interposer.

Bei den bisher dürftigen Informationen über "Zen" wäre da schon eine Quellenangabe angebracht.

 

[hot]

Bei den bisher dürftigen Informationen über "Zen" wäre da schon eine Quellenangabe angebracht.

Quatsch Quellenangabe, sowas gibts natürlich nicht. Aber AMD arbeitet schon seit längerem mit großen Trara daran, jede Veranstaltung gibts Folien darüber. Natürlich werden Zen, K12 und post-GCN Interposer-Architekturen sein.

 

[FredD]

Quatsch Quellenangabe, sowas gibts natürlich nicht. Aber AMD arbeitet schon seit längerem mit großen Trara daran, jede Veranstaltung gibts Folien darüber. Natürlich werden Zen, K12 und post-GCN Interposer-Architekturen sein.

Ich habe bisher keinen Artikel gefunden, der die "Zen" Architektur und Interposer auf der gleichen Seite nennt. Falls du auch keinen derartigen (halbwegs fundierten) Artikel findest, würde ich das "natürlich" zu "Spekulation" herabstufen.

Mit "Interposer" meinst du vermutlich "3D Interconnect Interposer" als Vorstufe zu TSV in der Umsetzung einer gestapelten ("3D") statt planaren Integration, z.B.: https://www.semiwiki.com/forum/content/3003-amd-goes-3d.html (?)

Meine persönliche Meinung: so selbstverständlich sehe ich das nicht.

 

[WindHund]

@tex_
K12 liegt sowieso unter K15 (Bully) von daher wird ZEN wohl kein HighPerformaceCompute Design.

Jo, aber AMD hat den BD-L1 trotzdem nur mit 4-Takten Zugriff entworfen.
Schon witzig - aus dem vergleichsweise riesigem 64kB L1 des K10 waren die Daten dagegen schon nach 3 Takten da.
Lag natürlich auch am anvisiertem Takt, aber naja ... die nötigen 220W TDP rechtfertigen das dann am Ende auch nicht mehr.

Sind die 4-Takten mit 4-issue zu Vergleichen?
Naja, ohne L2 und L3 Cache wären es gewiss keine 220W TDP.
Aber 8MByte L2 mit vollem Kerntakt von 8x 4.7GHz ist das vom Werk aus schon "fett".

@FreD

 

[gruffi]

Was heisst "K12 liegt sowieso unter K15"? K12 und auch Zen sollen beides High Performance Kerne werden. Ich kann mir kaum vorstellen, dass man damit lediglich Dual- oder Quad-Core Designs @ 2 GHz macht. Vom K12 Serverdesign erwarte ich auf jeden Fall deutlich mehr Performance als von Orochi. Egal ob gleiche oder niedrigere TDP. Sowas in der Art wie 8-16 Cyclone Kerne @ 3-4 GHz. Nur mal ein paar grobe Zahlen zum Vergleich. Orochi @ 4 GHz schafft in Geekbench >16k Int / 15k FP. 8 Cyclone Kerne @ 3 GHz würden voraussichtlich >25k Int / >25k FP schaffen, 16 Cyclone Kerne @ 4 GHz >65k Int / >65k FP. Bei Zen muss man abwarten. Da weiss man einfach noch zu wenig.

 

[amdfanuwe]

Vom K12 Serverdesign erwarte ich auf jeden Fall deutlich mehr Performance als von Orochi.

Mehr Performance/Watt erwarte ich auch. Ist halt nur die Frage, ob sie die Taktraten hoch genug bekommen um auch eine ordentliche single Core Leistung zu erreichen. Da würde ich bei K12 und bei ZEN nicht zu viel erwarten.
Werden vielleicht super Kerne bei 3GHz und darunter. Aber mal abwarten, was die erste Generation an 16/14nm FF an Takt liefert ohne zu saufen.

 

[Woerns]

Hab den Link schon bei den Tabletarchitekturen gepostet, aber eigentlich kann man das Thema besser im Zusammenhang von K12 diskutieren.
Microprocessors: Will ARM Rule the World?
MfG

 

[Meckel]

Habe gerade gelesen das die ARM-ISA fast jeden Befehl konditional ausführen kann. Bei Code der das nutzt sollte doch einiges an Einsparungen bei der Sprungvorhersage etc. möglich sein.

Wieviel % der Diegrösse könnten das sein?

 

[gruffi]

Ich denke das ist so wenig, dass man es in Prozent kaum sinnvoll angeben kann. Bei bedingten Anweisungen brauchst du doch im Grunde immer nur ein Bit zusätzlich mit durchzuschleifen. Von Frontend zu Backend wird das eh über uops gemacht. Und im Backend brauchst du dann lediglich eine Bypass Logik vor den Ausführungseinheiten. Das sollte nicht viel kosten.

Trotzdem sollte man beachten, bedingte Anweisungen machen nur bei kurzen bedingten Sequenzen Sinn. Damit bedingte Anweisungen effektiv sind, sollte der Compiler also gut optimieren. Hat man längere bedingte Sequenzen, sind Sprünge effektiver.