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

cyrusNGC_224 schrieb:
Das steht dort aber so nicht da.
Und es ist doch nur eine weitere Zusammenfassung.

Was kann man eigentlich zu den neuen Instruktionen sagen? Was hat AMD damit vor; denn erfahrungsgemäß setzen die sich nicht durch, wenn Intel die nicht auch übernimmt.
Zum Vergrößern anklicken....
Über die neuen Instructions gibt es fast keine Infos, ob sie genutzt werden oder nicht entscheiden aber die Entwickler und weniger Intel.
Diktatur ist out! ;)

Über den un-core Bereich weiß man bisher auch recht wenig, außer dem L3 Cache.
Alle Kerne eines Quad Cluster sollen auf alle Daten vom L3 zugreifen können, mit der selben Latenz. :o
 
ob sie genutzt werden oder nicht entscheiden aber die Entwickler und weniger Intel.
Diktatur ist out!
Zum Vergrößern anklicken....
naja, der Marktanteil entscheidet das. Welcher Entwickler baut was ein, was nur ein paar Prozent der Kunden nutzen können? Irrelevant, ob das die technisch bessere Lösung ist. Für die Hardware extra kompilierte Kernel, Programme usw. spielen bei Großrechnern eine Rolle, aber sonst doch eher nicht.

Aber wenn es nicht Diefläche oder Leistung kostet, können solche Zusatzinstruktionen ja sozusagen kostenfrei untergebracht werden, selbst wenn sie nur in Großrechnern und von einigen ichkompiliermeinLinuxselbst-Nerds genutzt werden.

Alle Kerne eines Quad Cluster sollen auf alle Daten vom L3 zugreifen können, mit der selben Latenz.
Zum Vergrößern anklicken....
wär schlimm, wenn nicht, oder? Ist das denn bisher anders? Kommt der Kern 0 meines Deneb schneller an den L3 als Kern 3? Klar, der Cache ist bei Zen grundlegend anders organisiert, aber unnötige Rückschritte vermeidet man dabei doch sicherlich.
 
Ich bin mal gespannt. Entweder ich hole mir im März dann einen Zen (falls ich meinen Nebenhjob noch hab) oder ein Z95 plus 4770K, die mir dann wohl hinterher geschmissen werden.
 
Und bei WCCFtech vermutet jemand mehr Parallelen von ZENs HT zu dem des Power8 als zu dem von Intel:
We'll have to wait for benchmarks, but I'm growing ever more suspicious that Zen's SMT implementation is more like Power8's than anything Intel's produced so far. Intel's approach has been to allow a second thread to use unused CPU resources, but doesn't really over-provision those resources (a single thread can very nearly saturate the whole CPU). On Power8, they can scale up to 8 threads per core (Zen will only do 2), but they make that viable by doubling down on key CPU resources in the first place (Instruction Cache, rename registers, etc.). The end result is that the second SMT thread on Intel increases overall performance by around 15-25%, but on Power8 the second SMT thread can increase overall performance by around 60% in some workloads. In Layman's terms, Power8's 'hyperthreads' are more useful than Intel's.

AMD haven't talked about rename registers yet, but they have revealed that the instruction cache is 64KB per core; perhaps not-so-coincidentally, that's double the size of Skylake's instruction cache, and the same size as Power8's. The L1 Data cache is only 32K in all of these processors, but its rather odd in processor design to have your instruction cache be twice the size of your L1 data cache -- unless you have a good reason. There's only two reasons I can think of -- either that second thread chews through a lot more instructions than in competing SMT designs, or possibly the uOp Cache can spill to L1. Looking at the slide from HotChips that shows which CPU resources are exclusive, competitively shared, or arithmetically arbitrated, has me leaning toward the former, though they might not have overprovisioned CPU resources enough to match Power8 fully. There were also rumors months back about Zen doing some really novel things with SMT, which would seem to back that up.

The implication of that would be that Zen could run at a lower clockspeed than Intel's current Broadwell DE but still match in overall threaded performance (but perhaps giving up 10-15% single-threaded performance (not clock-normalized)). For the mainstream, they could release a quad-core CPU at similar clocks to Skylake, and outperform it in threaded workloads. In gaming workloads, since current consoles make 6-7 threads available to games, a quad-core Zen with 4 hyper-threads giving ~60% additional performance would give a lot bettter performance than a quad-core i7 with 4 hyper-threads giving ~20% additional performance. In fact, that Zen would would have a throughput comparable to 6-7 dedicated cores.

We won't know until someone does an architecture deep-dive or we have benches showing SMT gains much larger than intel's. But its looking increasingly likely from what I see.
Zum Vergrößern anklicken....
 
Naja die Vermutung klingt ( mein Englisch ist vieles aber nicht perfekt ) an sich wirklich sehr gut, aber im Moment ist leider alles nur eine Vermutung bzw heiße Luft ... obwohl ich es wirklich für AMD hoffe das ZEN ein Erfolg wird ... ich werde ZEN auf jeden fall für einen meiner PCs kaufen ... ob für die Daddelkiste muss leider die Performance entscheiden
 
Ich würde da nun nicht zw. Intel oder IBM-Architekturen vergleichen. Simpler Fakt ist, viel hilft viel und AMDs L1I-Cache ist größer, ergo besser als Intels.

Dass der L1I-Cache wichtig ist, lernte AMD schon bei Bulldozers CMT, bekanntlich wurde der ja ab Steamroller gleich von 64 auf 96kB vergrößert, das war nicht wenig und einen solchen Änderungsaufwand im Herzen des Designs treibt man nicht ohne sehr triftige Gründe.

Da kann man dann einfach schlussfolgern, dass das eine verdammt wichtige Größe ist und 32 kB L1I für 2 Threads somit definitiv zu klein sein dürften, egal ob 2xCMT oder 2xSMT. 64 kB dürfte für SMT statt CMT dann ausreichend sein, denn 96 wird man nur für CMT brauchen, wo es ja auch noch eigene L1D-Caches gibt. Bei SMT wird dagegen der gemeinsam benutzte L1D-Cache etwas bremsen.
 
Die Fetch-Queue beim Power 8 beinhaltet egal, ob ein oder zwei Threads 64 Instruktionen, erst ab SMT4 wird hier pro Thread unterteilt.
Darüber hinaus hat Power 8 die Ausführungseinheiten praktisch in zwei Hälften partitioniert, mit zwei Unified Issue Queues.
Ein Thread verwendet beide, bei zwei kann man aber jedem Thread exklusiv Ressourcen zusichern:
http://www.anandtech.com/show/10435/assessing-ibms-power8-part-1/4

Bei Zen dagegen gibt AMD an, dass alle Ressourcen auch im 1T Mode zur Verfügung stehen:
https://pics.computerbase.de/7/4/1/5/4/15-1080.2713563378.png

Ich würde mich da viel mehr an Intels Ergebnisse orientieren, als die von Power 8.
Power 8 hat darüber hinaus einen 64KB großen L1D-Cache (8-Way) (Intel 32 KB (8-Way)) und wie Intel nur einen 32KB großen L1I-Cache (8-Way).
Zen dagegen genau andersherum, 32 KB L1D-Cache (8-Way) und 64KB L1I-Cache (4-Way).
Die ISA ist natürlich eine andere.
 
Weiß eigentlich jemand, wie derzeit die Stimmung auf den Gesichtern der Intel-Architekten ist? :)
 
OBrian schrieb:
naja, der Marktanteil entscheidet das. Welcher Entwickler baut was ein, was nur ein paar Prozent der Kunden nutzen können? Irrelevant, ob das die technisch bessere Lösung ist. Für die Hardware extra kompilierte Kernel, Programme usw. spielen bei Großrechnern eine Rolle, aber sonst doch eher nicht.

Aber wenn es nicht Diefläche oder Leistung kostet, können solche Zusatzinstruktionen ja sozusagen kostenfrei untergebracht werden, selbst wenn sie nur in Großrechnern und von einigen ichkompiliermeinLinuxselbst-Nerds genutzt werden.

wär schlimm, wenn nicht, oder? Ist das denn bisher anders? Kommt der Kern 0 meines Deneb schneller an den L3 als Kern 3? Klar, der Cache ist bei Zen grundlegend anders organisiert, aber unnötige Rückschritte vermeidet man dabei doch sicherlich.
Zum Vergrößern anklicken....
Aus der Sicht hast du vollkommen recht, als Entwickler will man so viel wie möglich Nutzer(innen) erreichen.
Ist doch kein Problem durch die CPUID Abfragung, beim Programmstart nutzen um entsprechende Zeilen vom Coder zu nutzen. ;)

Der ZEN Cluster hat aber nicht 1x 8MB wie die Piledriver sondern 4x 2MB, das ist in Verbindung mit PowerGating doch sehr beeindruckend! *party2*
 
Dresdenboy schrieb:
Weiß eigentlich jemand, wie derzeit die Stimmung auf den Gesichtern der Intel-Architekten ist? :)
Zum Vergrößern anklicken....
Na wenn du das nicht weißt... ;)
Wäre schon mal interessant, wie Insider in konkurrierenden oder nur anderen Bereichen/Firmen auf so was schauen.
 
OBrian schrieb:
naja, der Marktanteil entscheidet das. Welcher Entwickler baut was ein, was nur ein paar Prozent der Kunden nutzen können?
Zum Vergrößern anklicken....
Es ist schon viel gewonnen, wenn die meisten Compiler es unterstützten und (halb)automatisch ins Kompilat einbauen. Die Frage ist halt auch, ob es eine direkte Konkurrenz von Intel gibt/geben wird, so wie bei AVX.

Bei PCGH hats übrigens eine Folie, wo die Befehle beschrieben werden.

OBrian schrieb:
wär schlimm, wenn nicht, oder? Ist das denn bisher anders? Kommt der Kern 0 meines Deneb schneller an den L3 als Kern 3? Klar, der Cache ist bei Zen grundlegend anders organisiert, aber unnötige Rückschritte vermeidet man dabei doch sicherlich.
Zum Vergrößern anklicken....
Das hängt u. a. vom Weg auf dem Chip sowie der Anbindung des Speichers ab. Meine mich zu erinnern, dass bei IBM die Kerne teilweise den physisch nahen L3-Cache priorisiert genutzt haben. Also stellt sich bei einem Konstrukt wie bei Zen die Frage, ob einzelne Kerne auf "ihren" L3-Cache (siehe DIE-Schaubild) schneller zugreifen können.

Laut dem Bereicht bei PCGH findet die Kommunikation zwischen den CCX über einen internen Bus statt, d. h. es ist nach außen von Vorteil, wenn es egal ist, welche CPU mit welchem Teil des L3 arbeitet.
 
WindHund schrieb:
Der ZEN Cluster hat aber nicht 1x 8MB wie die Piledriver sondern 4x 2MB, das ist in Verbindung mit PowerGating doch sehr beeindruckend! *party2*
Zum Vergrößern anklicken....

Das war bei Orochi aber auch so, da gabs 4x2 MB Segmente, die Bandbreite war da eigentlich nicht so schlecht, wenn ich mich recht erinnere, nur die Latenz war halt ur-grottig ;)
Zen scheint nun 8x1 MB Segmente zu haben, auch nicht schlecht ;)

--- Update ---

Locuza schrieb:
Die Fetch-Queue beim Power 8 beinhaltet egal, ob ein oder zwei Threads 64 Instruktionen, erst ab SMT4 wird hier pro Thread unterteilt.
Darüber hinaus hat Power 8 die Ausführungseinheiten praktisch in zwei Hälften partitioniert, mit zwei Unified Issue Queues.
Ein Thread verwendet beide, bei zwei kann man aber jedem Thread exklusiv Ressourcen zusichern:
Zum Vergrößern anklicken....

Ich stimme Dir eigentlich zu, aber bei dem Punkt muss man auch an AMDs Trennung in INT+FP erinnern. Das ist quasi auch eine Auftrennung wenn auch nicht per Thread, aber da bei AMD doppelt soviele Ports wie bei Intel zur Verfügung stehen ist es von vorne herein klar, dass sich 2 Threads bei so einer Architektur nur halb so oft auf die Füße treten als bei Intel - zumindest wenn es sonst keine anderen Flaschenhälse gibt.

Der SMT-Speedup dürfte also definitv besser ausfallen. Wer unbedingt will kann das dann notfalls mit Power8 vergleichen, es geht gaaanz grob in die gleiche Richtung, ich würde es aber nicht machen, da es noch viel zu viel Unterschiede gibt und AMD näher an Intel liegt - mit dem Unterschied bei den Ports.

Die Preisfrage ist wieviel AMD drauflegen kann. Bei Intels 30%-SMT-Speedup hieß es mal, dass das allein nur wenig mehr als das Ausnutzen des Leerlaufs aufgrund der Speicherwartezeiten eines Threads war. Irgendwas zwischen 40-50% wäre also nett, CMT bei Bulldozer hatte schon 60% aufwärts, das wird man wohl nicht erreichen, da bräuchte es vermutlich mind. eine weitere Store-Unit und mehr Cache-Ports.

Edit:

Wer eine andere Architektur zum Vergleiche haben will kann die hier nehmen:
cpux0xv9.png


;)
 
Locuza schrieb:
Die Fetch-Queue beim Power 8 beinhaltet egal, ob ein oder zwei Threads 64 Instruktionen, erst ab SMT4 wird hier pro Thread unterteilt.
Darüber hinaus hat Power 8 die Ausführungseinheiten praktisch in zwei Hälften partitioniert, mit zwei Unified Issue Queues.
Ein Thread verwendet beide, bei zwei kann man aber jedem Thread exklusiv Ressourcen zusichern:
http://www.anandtech.com/show/10435/assessing-ibms-power8-part-1/4

Bei Zen dagegen gibt AMD an, dass alle Ressourcen auch im 1T Mode zur Verfügung stehen:
https://pics.computerbase.de/7/4/1/5/4/15-1080.2713563378.png
Zum Vergrößern anklicken....

Mich würde es nicht wundern wenn sich in zukünftigem CPUs Teile der Bulldozerarchitektur finden würden, d.h. dedizierte Einheiten für einzelne Threads einer CPU mit SMT.
 
WindHund schrieb:
Alle Kerne eines Quad Cluster sollen auf alle Daten vom L3 zugreifen können, mit der selben Latenz. :o
Zum Vergrößern anklicken....
Kleine Korrektur an dieser Stelle. Wenn man sich den Hotchips-Vortrag auf Youtube anschaut fällt auf, dass der AMD-Ingenieur von der gleichen durchschnittlichen Zugriffsgeschwindigkeit jedes Kerns eines CCX spricht. D. h. es kann sein, dass ein bestimmter Kern auf einen Teil des L3 schneller zugreifen kann als auf den Rest. Vmtl. also auf die näherliegenden Teile des L3.
 
MacroWelle schrieb:
Kleine Korrektur an dieser Stelle. Wenn man sich den Hotchips-Vortrag auf Youtube anschaut fällt auf, dass der AMD-Ingenieur von der gleichen durchschnittlichen Zugriffsgeschwindigkeit jedes Kerns eines CCX spricht. D. h. es kann sein, dass ein bestimmter Kern auf einen Teil des L3 schneller zugreifen kann als auf den Rest. Vmtl. also auf die näherliegenden Teile des L3.
Zum Vergrößern anklicken....
Jupp, kann ich bestätigen, hat der Vortragende von der Hotchips so gesagt (in einer anderen Version des Vortrags für die Presse).
 
MacroWelle schrieb:
Kleine Korrektur an dieser Stelle. Wenn man sich den Hotchips-Vortrag auf Youtube anschaut fällt auf, dass der AMD-Ingenieur von der gleichen durchschnittlichen Zugriffsgeschwindigkeit jedes Kerns eines CCX spricht. D. h. es kann sein, dass ein bestimmter Kern auf einen Teil des L3 schneller zugreifen kann als auf den Rest. Vmtl. also auf die näherliegenden Teile des L3.
Zum Vergrößern anklicken....
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?
 
WindHund schrieb:
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?
Zum Vergrößern anklicken....
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.
 

Ähnliche Themen

eratte
Intel Raptor Lake-S Big/Little 8 + 16 Kerne (LGA1700, DDR5, PCIe 5.0, 6/7er Chipsatzserie) Reviewthread
2 3 4
Antworten
91
Aufrufe
8K
eratte
eratte
pipin
News AMD Prozessoren mit Zen in 3000 C-Serie für Chromebooks
Antworten
14
Aufrufe
933
ONH
ONH
eratte
News Intel Alder Lake-S Big/Little 8 + 8 Kerne (LGA1700, DDR5, PCIe 5.0 (PEG Slot), 6er Chipsatzserie)
3 4 5
Antworten
102
Aufrufe
11K
eratte
eratte
eratte
News 2 neue AMD Embedded-Prozessoren: AMD Ryzen R1102G und R1305G mit 6 bis 10 Watt TDP
Antworten
3
Aufrufe
2K
eratte
eratte
Nero24
News AMD Ryzen 3000 mit bis zu 16 Kernen?
2
Antworten
34
Aufrufe
5K
MIWA
MIWA
Zurück
Oben Unten