AMD Zen - 14nm, 8 Kerne, 95W TDP & DDR4?

[WindHund]

Bis auf Cache-Blocking wird für solche Dinge eigtl. nicht optimiert. Zuviel Aufwand für wenig Nutzen, da hier die Prefetcher vorarbeiten.

George Woltman hat für Prime95/GWNUM auf P4 im Assemblercode extra Dummy-Ladebefehle gehabt, um die TLBs schonmal vorzuladen - u. diese dann indirekt aktiv gemanaged für optimale L1-Latenzen.

Ok, aber "L1 Software error searching" findet doch im "nano Sekunden" Bereich statt?

 

[Meckel]

Danke!
Wenn die höchste (schlechteste) Latenz besser wie beim FX ist, wäre das kein Problem.
Nur die Frage ob ein Software Entwickler dieses know how nutzen kann und bestimmte Teile vom L3 anzusprechen?
Stell ich mir zu kompliziert vor für Handarbeit, könnte das evt. der OS Sheduler übernehmen?

Nicht für bestimmte Teile: https://www.google.de/#q=gcc+prefetch

 

[WindHund]

Nicht für bestimmte Teile: https://www.google.de/#q=gcc+prefetch

Ist nicht Wahr, oder? 3Dnow prefetcher?


Ich ahne da böses für die non APUs, ohne dGPU Unterstützung ...

 

[Opteron]

Wenn ich mich recht erinnere sind die aktuellen Empfehlungen die, dass man die Complierprefetcher ausschalten sollte, weil die Chips mittlerweile selber gut genug sind und erkennen, was gebraucht wird.

Eine Optimierung bei den L3-Zugriffen würde nicht viel bringen, da reden wir vielleicht von max. 2-3 Takten Unterschied, bei Gesamtlatenzen von über 30 Takten ist das zu vernachlässigen. Unter SMT-Gesichtspunkten ist es sogar total egal, je länger der eine Thread auf den L3 wartet, desto mehr Arbeitszeit bekommt Thread 2.

Vermutlich gibts sogar eine Logik, die die 2MB-Segmente in Kernnähe eben diesem Kern zuschlägt. D.h. Daten, die aus dem kerneigenen L2 fallen, werden - falls noch was frei ist - in diese 2 MB geschrieben, stünden also wieder schnell zur Verfügung. Die AMD- Entwickler werden sich da sicherlich was clevers einfallen haben lassen

 

[MacroWelle]

@Opteron
Anderswo gibts das schon:
"Migrate “hot” lines to local L2, then local L3 (replicate L2 contained footprint)"
http://konwent.spnt.pl/files/4714/1379/9085/10_IBM_-_Power8.pdf (Seite 4)

Und noch einer:
"The chip has 32 MB of L3 cache [...] carved up into eight segments with 4 MB chunks affiliated with one of the eight cores."

http://www.theregister.co.uk/2010/02/08/ibm_power7_chip_launch/?page=2

An irgendwas erinnert mich der DIE-Shot...

Zum Verhalten des L3 bei Zen gibt es im Artikel von Anandtech einige Aussagen. Zum einen Victim-Cache für den L2, zum anderen ist ist der L3 exklusiv.

 

[Meckel]

Wenn ich mich recht erinnere sind die aktuellen Empfehlungen die, dass man die Complierprefetcher ausschalten sollte, weil die Chips mittlerweile selber gut genug sind und erkennen, was gebraucht wird.

Es ging um händischen Prefetch:

Built-in Function: void __builtin_prefetch (const void *addr, ...)

This function is used to minimize cache-miss latency by moving data into a cache before it is accessed. You can insert calls to __builtin_prefetch into code for which you know addresses of data in memory that is likely to be accessed soon. If the target supports them, data prefetch instructions are generated. If the prefetch is done early enough before the access then the data will be in the cache by the time it is accessed.

The value of addr is the address of the memory to prefetch. There are two optional arguments, rw and locality. The value of rw is a compile-time constant one or zero; one means that the prefetch is preparing for a write to the memory address and zero, the default, means that the prefetch is preparing for a read. The value locality must be a compile-time constant integer between zero and three. A value of zero means that the data has no temporal locality, so it need not be left in the cache after the access. A value of three means that the data has a high degree of temporal locality and should be left in all levels of cache possible. Values of one and two mean, respectively, a low or moderate degree of temporal locality. The default is three.

for (i = 0; i < n; i++)
{
a = a + b;
__builtin_prefetch (&a[i+j], 1, 1);
__builtin_prefetch (&b[i+j], 0, 1);
/* ... */
}

Data prefetch does not generate faults if addr is invalid, but the address expression itself must be valid. For example, a prefetch of p->next does not fault if p->next is not a valid address, but evaluation faults if p is not a valid address.

If the target does not support data prefetch, the address expression is evaluated if it includes side effects but no other code is generated and GCC does not issue a warning.

 

[Woerns]

Vermutlich gibts sogar eine Logik, die die 2MB-Segmente in Kernnähe eben diesem Kern zuschlägt. D.h. Daten, die aus dem kerneigenen L2 fallen, werden - falls noch was frei ist - in diese 2 MB geschrieben, stünden also wieder schnell zur Verfügung. Die AMD- Entwickler werden sich da sicherlich was clevers einfallen haben lassen

Arbeitet der L3 Cache immer noch als Victim-Cache, der die Daten aufnimmt, die aus dem L2 purzeln?
Ich dachte (eher so ein Gefühl), AMD hätte auf eine inklusive Cache-Architektur umgestellt, wo alles, was im L2 vorhanden ist, ohnehin auch immer im L3 ist.
MfG

 

[Opteron]

Arbeitet der L3 Cache immer noch als Victim-Cache, der die Daten aufnimmt, die aus dem L2 purzeln?
Ich dachte (eher so ein Gefühl), AMD hätte auf eine inklusive Cache-Architektur umgestellt, wo alles, was im L2 vorhanden ist, ohnehin auch immer im L3 ist.
MfG

Ne, das ist wieder der gute alte Victim Cache.

 

[Woerns]

Hm. Der Vorteil vom Victim Cache war immer, dass der Praktikant mehr MB Gesmat-Cache auf den Folien in Szene setzen konnte. Der Nachteil war immer, dass er deutlich höhere Latenzen hatte, jedenfalls gegenüber Intels inklusivem Cache.
MfG

 

[Opteron]

Hm. Der Vorteil vom Victim Cache war immer, dass der Praktikant mehr MB Gesmat-Cache auf den Folien in Szene setzen konnte. Der Nachteil war immer, dass er deutlich höhere Latenzen hatte, jedenfalls gegenüber Intels inklusivem Cache.

Der Vorteil stimmt, aber mit Latenzen hats nichts zu tun. Das war bei AMD einfach schlecht implementiert, z.B. wegen einer extra Taktdomäne mit weniger Takt.

Intel wird mittlerweile aber auch schlampiger, deren L3 hat jetzt bei den neuesten Generationen auch (wieder) nen eigenen Takt und die Latenz liegt um die 40 Takte für den Erstzugriff. Wenn AMD sich ggü. BD nun verbessert sollten sie Pi*Daumen gleichauf mit Intel sein, vielleicht sogar noch n bisschen besser.

Intels L2 gefällt mir auch nicht mehr, der braucht mittlerweile 13 Takte und ist nur noch 4fach assoziativ. Angeblich weil man bei Serverdesigns ebenfalls wie Zen auf 512 kB L2 gehen will und man in dem Fall dann wieder 8fach assoziativ wäre. Aber naja .. wenn AMD da nen 512 kB L2 mit 14-15 Takten Latenz hinzaubern könnte, wäre der mit der bekannten 8fachen Assoziativität deutlich besser als der L2 Intels. Eigentlich verlangsamt sich Intel mit der neuesten Generation, sowohl L2 als auch L3 sind schlechter. Etwas merkwürdig, aber das Design verbraucht wohl zuviel Energie, bei 256bit AVX-Instruktionen wird ja schon runtergetaktet.

Der ausschlaggebene Punkt könnten dann AMDs Stromsparfeatures sein, die man mit Carrizo einführte.

 

[LoRDxRaVeN]

Wenn ich die Caches zwischen Bulldozer und Zen vergleiche, stellt sich mir eine Frage. Lt. Anand ist der L2 von Zen 8-fach assoziativ und der von Bulldozer 16-fach. Hier kann ich mir noch vorstellen, dass das durch write-back statt write-through überkompensiert wird. Beim L3 hat aber Zen nur 16-fache Assoziativität gegenüber 64-facher von Bulldozer vorzuweisen und beide sind victim-caches. Warum stellt der L3 Cache performancemäßig so kein Problem dar bzw. warum hat man dann bei Bulldozer eine viermal so hoche Assoziativität gewählt?

LG

 

[Stefan Payne]

Warum stellt der L3 Cache performancemäßig so kein Problem dar bzw. warum hat man dann bei Bulldozer eine viermal so hoche Assoziativität gewählt?

Eventuell weil man den Sack Lahmen Takt des NB Teils ausgleichen wollte...

Die sau lahme 2. Taktdomäne vom BD ist ja auch irgendwie ein Problem. Das siehst du auch ganz gut darin, dass die niedrigst getakteten (Server) Versionen eigentlich gar nicht soo übel waren...

 

[Opteron]

Naja, mehr Ways per se sind natürlich besser, kosten aber halt auch was in Form von Stromverbrauch und Latenz.
BDs L3 hatte ne Latenz von >60 Takte. Also schön, wenn man dort wegen der Ways viele Treffer hat, aber wenn man ein paar Promill weniger hat, dafür aber nur halb so lange warten müsste (30-40 Takte), dann wäre das in 99% der Fällen sicherlich die bessere Idee.

Was sich AMD damals dabei gedacht hat, weiss vermutlich keiner. Insbesondere im Anbetracht eines Hochtakt-Designs.
Aber gut - vielleicht wollten sie damit Strom sparen, da das Core schon zuviel Leistungsaufnahme verursachte.

Im Vergleich zu Sandy damals war Sandys L3 latenztechnisch fast auf BDs L2-Niveau, kein Wunder, dass es dann mit der IPC nicht so hinhaut.

Also von daher wär ich froh, wenn AMD jetzt wenigstens einen ~40 Takt L3 hinbekommt. Zusammen mit nem guten, schnellen 512 kB L2 sollte das schon reichen. Intel ist ja auch nicht mehr groß schneller.

 

[Stefan Payne]

Würde fast vermuten wollen, dass die BD Cores eigentlich ganz gut sind, aber von den lahmen Caches und dem Uncore Bereich vernichtet worden sind...

Naja, schade drum, aber lässt sich nicht ändern...

 

[Dresdenboy]

Würde fast vermuten wollen, dass die BD Cores eigentlich ganz gut sind, aber von den lahmen Caches und dem Uncore Bereich vernichtet worden sind...

Naja, schade drum, aber lässt sich nicht ändern...

Mit etwas Einsatz könnte man das sogar nachweisen. Es gibt ja die ganzen IBS-Counter, wo man Cache Misses, Stalls, uOps executed usw. zählen könnte.

 

[Stefan Payne]

Naja, man sieht ja auch, wenn man den NB Teil übertaktet, wie verdammt viel Performance das zum Teil bringt...

AFAIR ists bei BD so, dass 100MHz mehr NB Takt in manchen Situationen etwa 200MHz Coretakt entsprechen...

 

[WindHund]

Wenn ich mich recht erinnere sind die aktuellen Empfehlungen die, dass man die Complierprefetcher ausschalten sollte, weil die Chips mittlerweile selber gut genug sind und erkennen, was gebraucht wird.

Eine Optimierung bei den L3-Zugriffen würde nicht viel bringen, da reden wir vielleicht von max. 2-3 Takten Unterschied, bei Gesamtlatenzen von über 30 Takten ist das zu vernachlässigen. Unter SMT-Gesichtspunkten ist es sogar total egal, je länger der eine Thread auf den L3 wartet, desto mehr Arbeitszeit bekommt Thread 2.

Vermutlich gibts sogar eine Logik, die die 2MB-Segmente in Kernnähe eben diesem Kern zuschlägt. D.h. Daten, die aus dem kerneigenen L2 fallen, werden - falls noch was frei ist - in diese 2 MB geschrieben, stünden also wieder schnell zur Verfügung. Die AMD- Entwickler werden sich da sicherlich was clevers einfallen haben lassen

Sounds good!

So schlecht finde ich den Speicher Controller / uncore jetzt nicht vom PD, aber es gibt Programme die einfach nur 1T 1K auslasten.

SiSoftware Sandra Speicher Latenz sequentiell: https://abload.de/img/sandra_speicherlatenzhkpgi.jpg

 

[Dresdenboy]

Naja, man sieht ja auch, wenn man den NB Teil übertaktet, wie verdammt viel Performance das zum Teil bringt...

AFAIR ists bei BD so, dass 100MHz mehr NB Takt in manchen Situationen etwa 200MHz Coretakt entsprechen...

Da verhungern also die Cores.

 

[sompe]

War daran nicht auch der L3 gekoppelt?
Bei Speicher lastigen Szenarien würde es mich dann nicht im geringsten wundern wenn dann der Northbridge Takt mehr bringt...

Allgemein empfinde ich es aber so dass das Cache System des Bulldozer Designs auch dessen größtes Problem ist. Ein Tribut an das CMT Design?

 

[Dresdenboy]

War daran nicht auch der L3 gekoppelt?
Bei Speicher lastigen Szenarien würde es mich dann nicht im geringsten wundern wenn dann der Northbridge Takt mehr bringt...

Allgemein empfinde ich es aber so dass das Cache System des Bulldozer Designs auch dessen größtes Problem ist. Ein Tribut an das CMT Design?

Der L3 spielt da keine Rolle, da CMT durch den shared L2 gekapselt wird. Allerdings hängt es dort, wie auch Mike Clark im Zen-Briefing nochmal sagte. Der L1-Write-Through-Cache sorgt natürlich sofort für einen L2-Schreibzugriff. Durch den konkurrierenden Core, den scheinbar nicht so effizienten Write Coalescing Cache u. auch die hohe L2-Latenz war dann scheinbar schnell dicht. Evtl. hat das auch schon mal jemand gemessen.

 

[WindHund]

@sompe
Zum uncore gehört alles was nicht mit CPU Takt läuft, so grob eingeordnet.
Also L3 Cache, IMC, Switches, etc.

Der L3 spielt da keine Rolle, da CMT durch den shared L2 gekapselt wird. Allerdings hängt es dort, wie auch Mike Clark im Zen-Briefing nochmal sagte. Der L1-Write-Through-Cache sorgt natürlich sofort für einen L2-Schreibzugriff. Durch den konkurrierenden Core, den scheinbar nicht so effizienten Write Coalescing Cache u. auch die hohe L2-Latenz war dann scheinbar schnell dicht. Evtl. hat das auch schon mal jemand gemessen.

Womit könnte man das testen, gern auch Anleitung per PN.

Es gibt bei Sandra auch openCL Speicher Latenz: https://abload.de/img/sandra_ocl_speicherla5oyn0.jpg
Verifiziert: http://ranker.sisoftware.net/show_run.php?q=c2ffcbfcdabbdae7d5e0d2f486bb8badc8ad90a086f5c8f8

 

[sompe]

@Dresdenboy
Bei speicherlastigen Programmen dürfte der L3 sehr wohl eine Rolle spielen aber egal.
Wie ich schon bei anderen Diskussonen schrieb habe ich mit der Deaktivierung des L1 und L2 Cache schon bei älteren Produkten (so Athlon Zeitalter) meine Erfahrung sammeln können und eine Deaktivierung des L2 wirkte sich zwar sehr deutlich aus, bei der Deaktivierung des L1 fiel die Leistung ins Steinzeit Alter zurück und er verlor geschätzte 90 oder 95% an Leistung. Damit steht für mich fest das alles was beim L1 nicht rund läuft sich massiv auf die Leistung auswirkt und gerade das L1 Design des Mulli kann man wohl nicht gerade als optimal bezeichnen.

 

[BoMbY]

@Dresdenboy
Bei speicherlastigen Programmen dürfte der L3 sehr wohl eine Rolle spielen aber egal.

Ich glaube nicht. Um große Mengen an Daten zu verarbeiten sind die Caches viel zu klein, da bringt das ganze Caching nichts - Cache bringt eigentlich nur was, wenn man die Daten darin wiederverwenden kann.

 

[Crashtest]

Mal so zwischen durch:
AMD hat die Desktop Bristol Ridge (Sockel AM4) ganz offiziell am 30.08.2016 gestartet aber keiner hats gemerkt oder ?

Es sind zwar noch nicht alle Modelle aus der Products PDF dabei aber die wichtigen "Großen" sind es ....

Wer es bei AMD nachlesen will, auf die APU-Listen (s.u.) klicken und bei Suche einfach Bristol Ridge eingeben ...

Links:
Meine Mini-User-News
AMDs APU-Liste
AMDs Product PDF

 

[BoMbY]

Ein (bzw. zwei) Server-Zen: http://browser.primatelabs.com/v4/cpu/105227

Dazu auch das hier: https://www.zauba.com/import-102-h-00a-hs-code.html

Edit: Zur Dokumentation: "AMD Eng Sample: 2S1451A4VIHE4_29/14_N @ 1.44 GHz 2 processors, 64 cores"

Edit2: Sieht so aus als wäre der mit einer Handbremse gelaufen, wenn man zum Beispiel auf die Memory-Werte schaut.