News Zen mit L0-Cache und µOp-Puffer

[Opteron]

Von ausnahmsweise belastbaren Informationen zu Zen weiß Matthias Waldhauer auf seinem Blog zu berichten. Mitte Februar tauchten wieder einige neue Codesegmente von AMD-Programmierern in Open-Sourcen-Projekten auf.
(…)

» Artikel lesen

 

[deoroller]

Der Pentium 4 hat auch einen µOp-Cache, wenn ich mich recht entsinne.

 

[genervt]

Klingt interessant. Mich hat "BTW have you ever heard of a processor core having 2 front ends and one shared back end?" mehr verwundert. Kann mich da eigentlich nur an AMDs GPUS mit 2x Frontend erinnern.

 

[Dresdenboy]

Der Pentium 4 hat auch einen µOp-Cache, wenn ich mich recht entsinne.

Richtig, aber als Trace Cache ausgelegt. Dort diente es dem Zweck, genügend µOp-Bandbreite bereitzustellen und am normalen Dekoder zu sparen (1 komplexer Befehl/Takt). Die Traces speichern Befehlssequenzen auch nach einem Sprungbefehl mit ab, wenn der Sprung recht wahrscheinlich ist. Das läuft etwas anders, als in den typischen µOp-Caches heute, die normale Dispatch-Pakete ablegen.

Mehr zum P4 hier: http://www.ecs.umass.edu/ece/koren/ece568/papers/Pentium4.pdf

 

[Locuza]

Der Pentium 4 hat auch einen µOp-Cache, wenn ich mich recht entsinne.

Ja, konzeptionell ähnlich war der Trace-Cache vom Pentium 4.
Erst ab Sandy-Bridge hat Intel die Idee wieder aufgegriffen, aber natürlich anders implementiert.
Ich bin gespannt auf die Umsetzung von Zen, neben allen anderen Dingen wie SMT.

Klingt interessant. Mich hat "BTW have you ever heard of a processor core having 2 front ends and one shared back end?" mehr verwundert. Kann mich da eigentlich nur an AMDs GPUS mit 2x Frontend erinnern.

Bei modernen GPUs hängen mehrere ALU-Arrays an einem Frontend-Modul und beim Backend sieht das vermutlich ähnlich aus.

 

[Opteron]

Richtig, aber als Trace Cache ausgelegt. Dort diente es dem Zweck, genügend µOp-Bandbreite bereitzustellen und am normalen Dekoder zu sparen (1 komplexer Befehl/Takt). Die Traces speichern Befehlssequenzen auch nach einem Sprungbefehl mit ab, wenn der Sprung recht wahrscheinlich ist. Das läuft etwas anders, als in den typischen µOp-Caches heute, die normale Dispatch-Pakete ablegen.

Mehr zum P4 hier: http://www.ecs.umass.edu/ece/koren/ece568/papers/Pentium4.pdf

David Kanter hatte das damals beim Sandy Bridge auch schön erklärt:
http://www.realworldtech.com/sandy-bridge/4/

Im Endeffekt wirkt es auch wie ein größerer L1-I-Cache, den musste AMD bei Bulldozer auch schon erhöhen. Falls er also bei Zen ebenfalls nur 32kB groß wäre, wäre etwas extra in Form eines L0-Caches sicher nicht verkehrt.

Preisfrage ist nun natürlich die Größe ... hat Intel den µOp-Cache bei Skylake eigentlich vergrößert? Ich finde nur Quellen zur Bandbreite.

 

[Onkel_Dithmeyer]

Der µOp-Cache hat sich seit Sandy nicht geändert: "1536 µops, 8 way, 6 µop line size, per core"

Quelle

 

[Opteron]

Der µOp-Cache hat sich seit Sandy nicht geändert: "1536 µops, 8 way, 6 µop line size, per core"

Quelle

Ach der gut Agner hat schon ein Update mit Skylake, Danke. Dann dürfte das geklärt sein .. wobei er die Bandbreitenerhöhung anscheinend verschlafen hat. Er schreibt bei Skylake immer noch von nur 4 µOps pro Takt...

 

[Dresdenboy]

Der µOp-Cache hat sich seit Sandy nicht geändert: "1536 µops, 8 way, 6 µop line size, per core"

Quelle

Die Line Size von 6 µops war dann ja eine gute Vorlage für die Erweiterung des Interfaces zum Dispatcher bei der Skylake-Mikroarchitektur.

Mal sehen, was es bei Zen wird. Mindestens 4, max. 8 denke ich. Längen darüber hinaus sind vermutlich zu selten zwischen 2 Sprüngen und gleichzeitig zu aufwändig. AMDs alte Trace Cache Patente hatten 8-er-Blöcke.

 

[OBrian]

Wohl gar nicht so falsch, was von Intel abzugucken. Je ähnlicher es zu Intel ist, desto einfacher wird es wahrscheinlich, auch ein ähnliches Performanceprofil zu erreichen. Immerhin muß AMD ja praktisch immer mit Software klarkommen, die für Intels gemacht/kompiliert wurde. Etwas anzubieten, was Intel nicht bietet, nutzt dann kaum eine Software aus, dafür müßte man an anderer Stelle sparen und das rächt sich dann.

 

[Opteron]

Die Line Size von 6 µops war dann ja eine gute Vorlage für die Erweiterung des Interfaces zum Dispatcher bei der Skylake-Mikroarchitektur.

Mal sehen, was es bei Zen wird. Mindestens 4, max. 8 denke ich. Längen darüber hinaus sind vermutlich zu selten zwischen 2 Sprüngen und gleichzeitig zu aufwändig. AMDs alte Trace Cache Patente hatten 8-er-Blöcke.

Na dann hoffen wir mal, dass es 8er Blöcke samt 8er Interface werden und nach der Decoder-Queue keine weiteren Flaschenhälse existieren
Vermutlich muss AMD mangels unified Scheduler sowieso ranklotzen, weil die Pipeline dann früher aufgeteilt wird.

Wohl gar nicht so falsch, was von Intel abzugucken. Je ähnlicher es zu Intel ist, desto einfacher wird es wahrscheinlich, auch ein ähnliches Performanceprofil zu erreichen. Immerhin muß AMD ja praktisch immer mit Software klarkommen, die für Intels gemacht/kompiliert wurde. Etwas anzubieten, was Intel nicht bietet, nutzt dann kaum eine Software aus, dafür müßte man an anderer Stelle sparen und das rächt sich dann.

Hmm, denke jetzt nicht, dass man auf low-level-Sachen dermaßen optimieren kann. Gut mit Assembler gehts natürlich, aber da muss man dann auch auf die Line Sizes und Pipapo aufpassen. Das ist so ähnlich wie bei der Cachegröße, alleine dass AMD nen L1-Cache hat ist noch nicht genügend, es sollte halt mindestens genausoviel Speicher wie bei Intel sein. Der BD-Cache war dahingehend auch schlecht gewählt, da die 16kB kleiner als Intels lange genutzte Größe von 32 kB waren. Excavator zog erstmals wieder gleich und schon ist die IPC halbwegs brauchbar ... natürlich wurde noch mehr gemacht, aber der L1 wird schon mit am Meisten zur IPC-Verbesserung beigetragen haben.

Bei den ganzen Gerüchten ist jetzt noch die Frage, was man aus dem VR-Zone-Leak machen soll, immerhin redeten die als erste vom L0-Cache, der nun bestätigt wurde. Als Größe gaben sie 4kB an, außerdem 64kB L1-Caches und 512 kB L2 ... letzteres wurde schon öfters genannt, aber 64kB L1 .. naja beschweren würde ich mich sicher nicht und bisher hatten alle Designs vom Keller 64kB L1. Wäre sicherlich auch nett im 2xfach SMT-Betrieb.

 

[OBrian]

Als Programmierer bleibt man ja auch lieber von der Hardware weg und schreibt objektorientiert, statt in die Tefen der Register abzutauchen Ich meinte eher, daß der Compiler im Zweifel eher darauf eingestellt ist, was für Intels gut ist und auf AMDs "auch läuft", nicht umgekehrt. Und das dürfte nicht nur den Intel Compiler betreffen, sondern auch den von Microsoft, womit ja wohl das meiste an Windows-Software kompiliert wird. Bei Linux kompilieren ja mehr Leute selber, aber die Standardkompilate werden auch in 80-90% der Fälle auf Intel-Maschinen entstanden sein. Das ist nun mal so, der Teufel scheißt immer auf den größten Haufen.

 

[Muku-Muku]

Da hätte Gentoo ja einen Vorteil. Hat da jemand schon einmal Benchmarks gemacht- also selbe Maschine, einmal Gentoo, einmal z.B. Debian?

 

[L0rD-Zero]

https://www.phoronix.com/scan.php?page=home wird da wahrscheinlich schon mal Benchs gemacht haben beziehungsweise auf dem Benchmark Archive davon könntest du eventuell welche finden: http://openbenchmarking.org/