AMD - Zen 2, 7nm, PCIe 4.0, 2019 (Matisse, Renoir, Castle Peak, Rome), Matisse-Refresh 2020 [Archiv] - Seite 13

iuno

2019-01-28, 11:40:48

Aus dem Video.
Könnte darauf schließen das bei Matisse eine IF link Chip to Chip möglich ist.
Das ist halt auch nur bearbeitetes ein Bild von der Oberflaeche*. Ob sich daraus auf die interne Struktur eines Chiplets schliessen laesst? Vermutlich schon, denn es scheint zu zeigen, wo es viele Verbindungen ins Package gibt und wo weniger.

Aber was sagt uns das? Wohl dass ein CCX weiterhin aus 4 Kernen besteht. Dann faende ich es aber doch viel schluessiger dass jedes CCX einfach einen eigenen IF link aufs I/O die hat, anstatt ueber inter-chiplet Verbindungen zu spekulieren.

Als Bestaetigung fuer inter-chiplet-Verbindungen wuerde ich das mal nicht sehen. Was soll das ueberhaupt bringen, wenn alle Speicherzugriffe eh ueber das I/O die gehen? Soll das CPU Chiplet noch die Logik bekommen, aus den L3 eines(!) benachbarten Chiplets lesen zu koennen, nur fuer Matisse?

btw ist es das, was mich an dem Typen stoert. Nicht sein schottischer Akzent oder sonst was. Auch nicht, dass er spekuliert, wie jeder von uns hier und das ganze monetarisiert. Wenns funktoiniert und ihm Spass macht, soll er halt. Aber er soll bitte nicht staendig so tun als wuerde er staendig wahnsinnig tolle Exklusivinfos zugespielt bekommen, nur weil irgendwer ihm das Bild von dem auf der CES gezeigten Package genommen und den Kontrast hochgezogen hat.

basix

2019-01-28, 12:37:33

Mal so ein Randgedanke zu den APUs: Wäre es möglich, dass die APU DDR4 und DDR5 gleichzeitig unterstützt? DDR5 soll ja 2019 in Massproduction starten.

Da gäbe es auch mehrere Varianten für den Release:
- DDR4 = Butter und Brot Notebooks, DDR5 für High-End Ultrabooks
- DDR4 first, DDR5 bei einer nächsten Generation oder einem Refresh (mit selbem Die)

Würde ein paar Skalierungsprobleme der iGPU lösen ohne gleich auf HBM setzen zu müssen.

Lehdro

2019-01-28, 12:50:28

weiß wer, welche TSMC Präsentation das ist? Habe ich im Video nicht mitbekommen.
Musste das sein:
https://ieeexplore.ieee.org/document/8310253
Evtl. weitere Links:
https://www.reddit.com/r/Amd/comments/ae2l08/more_fuel_for_the_hypetrain_5ghz_l1_cache/

Screemer

2019-01-28, 13:07:45

Mal so ein Randgedanke zu den APUs: Wäre es möglich, dass die APU DDR4 und DDR5 gleichzeitig unterstützt? DDR5 soll ja 2019 in Massproduction starten.

Mal so ein Randgedanke zu den APUs: Wäre es möglich, dass die APU DDR4 und DDR5 gleichzeitig unterstützt? DDR5 soll ja 2019 in Massproduction starten.

Cadence bietet ddr phys an die sowohl ddr4 als auch ddr5 unterstützen und für tsmcs 7nm Prozess optimiert sind: https://ip.cadence.com/uploads/1234/cdn-dsd-mem-ddr-denali-gen2-ddr-phy-ip-for-ddr5-4-for-tsmc7-pdf. Rambus und Designware (?) haben sowas glaub ich auch im Portfolio.

Allerdings wurde ja gesagt, dass zumindest die IP für den memorycontroller wieder in-house von AMD kommt. Bei Zen(+) kam der imc und die phys von cadence, wenn ich mich richtig erinnere. Bisher kann ich auch bei cadence nur Infos zu phys finden und nichts über einen lizenzierbaren imc für ddr5.

BlacKi

2019-01-28, 13:20:45

- 5 GHz sind realistisch als Boost (der8auer + TSMCs 5 GHz L1 Cache Demo)

die schlussfolgerungen aus einer demo(keiner zen2 demo) von tsmc kann ich nicht nachvollziehen. zen+ ist ja auch an einer clockwall gescheitert nicht an zu wenig voltage. nur weil cache 5ghz bei -40° mitmacht kann man doch nicht drauf schließen das die zen2 cores ebenfalls 5ghz mitmachen, vorallendingen bei +60°?:freak:
adored boost clock part
https://youtu.be/wjVjHce8uME?t=1104
der bauer aussage
https://youtu.be/ModVWpAx1yc?t=710
seine aussage war bezogen auf das pricing. bestätigt hat er letztlich nur höhere ipc und höhere taktraten. die 4,5 4,6 hatten wir schon live gesehen. also nichts neues.

mboeller

2019-01-28, 13:23:35

Musste das sein:
https://ieeexplore.ieee.org/document/8310253
Evtl. weitere Links:
https://www.reddit.com/r/Amd/comments/ae2l08/more_fuel_for_the_hypetrain_5ghz_l1_cache/

Danke!

Hab es dann hier gefunden:

https://reconfigdeeplearning.files.wordpress.com/2018/02/isscc2018-11_visuals.pdf

Das Bild mit der Skalierung bis 5.36GHz ist auf S104 von 108

BoMbY

2019-01-28, 13:24:59

Mal so ein Randgedanke zu den APUs: Wäre es möglich, dass die APU DDR4 und DDR5 gleichzeitig unterstützt?

Sowohl APUs als auch CPUs. Zumindest in der Theorie, denn man dürfte wohl bald die DesignWare DDR5/4 PHY IP (https://www.synopsys.com/dw/ipdir.php?ds=dwc_ddr54_phy) einsetzen. Nur ab wann genau, und ob das praktisch genutzt wird, das ist wohl fraglich.

Gipsel

2019-01-28, 13:57:04

1.) Einen potenziellen L4$ würde man bei dem Test doch gar nicht sehen, wenn der nicht größer als der L3 wäre. Ich denke aber nicht, dass sowas implementiert ist, da Matisse ja keine APU ist.Teil der Switch-Logik im IO-Die dürfte sehr wahrscheinlich eine Art Cache-Directory sein, der eben als Snoop-Filter funktioniert. Im Prinzip kann (bzw. sollte) man dort die L3-Tags aller angeschlossenen Dies duplizieren (das ist der naive Weg, eventuell versucht man cleverer zu sein), damit das IO-Die exakt weiß, wo die angefragte Speicherstelle gecached wird und keine Anfragen an alle Dies rausschicken muß. Will sagen, daß IO-Die dürfte durchaus merklich SRAM enthalten, selbst wenn es kein L4 ist. Aber viel mehr will man in 14nm vermutlich da auch kaum raufhauen. Denn ein Epyc 2 mit 8 Chiplets, jedes davon mit 32MB L3 (16MB pro 4C CCX, also doppelt so viel pro Kern im Vergleich zu Zen1), enthalt ja bereits in der Summe 256MB L3-Cache. Die Tags dafür kosten so grob 8 Byte pro 64Byte Cacheline (Adresse der Cacheline gekürzt um die letzten 6 Bits, 5 Bits für Status [MOESI], Statusinfo für Ersetzungsstrategie [die gibt es einmal pro Satz, also ein paar Bits pro 16 Cachelines beim L3 mit 16facher Assoziativität]), was also mithin bereits 32MB nur für die Tags wären, die man im IO-Die dupliziert. Das kleinere IO-Die für Ryzen 3k (unterstützt ja nur 2 Chiplets) kommt logischerweise dann mit nur 8MB für die Tags aus.
2.) die Chiplets werden mMn "dumm" sein, es wird keinerlei Logik zur Verbindung der CCX geben. MMn sind beide CCX direkt an das I/O-Die angeschlossen. Man muss also für Kohärenz auf jeden Fall über das I/O-Die. Das wird der größte Pferdefuß bei der Sache sein und könnte sich eher schlecht auswirken.Ob das gut oder schlecht ist, kommt ganz auf die Situation drauf an. Die L3-Caches auf den anderen Die zu snoopen kostet ja auch. Und mit der oben aufgeführten Duplizierung der Tags im IO-Die kostet das Checken der Tags an sich gleich lange, egal ob man das direkt zum anderen Die oder im IO-Die macht. Falls man einen Hit im anderen Die hätte, dann kostet die Übertragung der Cacheline bei direkter Verbindung der Dies weniger Zeit (1 Hop gespart), allerdings erfordert das dann zusätzliche Kommunikation zum IO-Die, um die Konsistenz der L3-Tag-Kopie dort zu sichern (vielleicht etwas schneller, aber zusätzliches Kopieren der Tags zum IO-Die nötig).
Falls man aber keinen Hit im anderen Die hat, man also sowieso den Speicher bemühen muß, dürfte die Anfrage über den IO-Die schneller sein, da dort der Request an den Speichercontroller schon parallel zum Check der L3-Tag-Kopien auf einen Hit eingeleitet wird (wird gecancelt, falls es einen Hit gibt) und nicht erst das Resultat der Snoops der anderen Dies abgewartet wird.

bun

2019-01-28, 14:21:32

Wie viel Drama hier ein Adored Video auslöst. Ich verstehe langsam auch warum. Ist einfach zu kompliziert, man muss selbst differenzieren was wie wahrscheinlich ist, man bekommt nicht sofort einfach stumpf erzählt, was man jetzt zu glauben hat. Intelligente Menschen die sich hinreichend mit der Materie beschäftigen schätzen das. Dieses Differenzieren fällt Manchen hier offensichtlich sehr schwer, und die eigene Unfähigkeit das Präsentierte selbst einzuschätzen schlägt dann in Wut und Ablehnung um, weil das Vorhergesagte ja nicht zu 100% exakt so eintrifft. (Was bei so komplizierten Spekulationen einfach nicht drin ist)

Das Problem ist, das die richtige und interessierte Zielgruppe zu klein ist, und sich das wirtschaftlich nicht ausgeht, nur diese Zielgruppe zu bedienen. Man muss seine Erklärungen immer vereinfachen, ausholen und wiederholen, um auch die schlecht informierten, halb desinteressierten Stammtischbrüder zu bedienen.

Wie hier schon wieder von Leak geredet wird. Was für ein Leak ?! Es sind einfach ein paar weitere Detailinformationen, ein paar mehr Spekulationen. Wie kann man das als Leak bezeichnen? Und offensichtlich folgt hier Niemand Lisa Su Interviews. Die Frau ist wie Teflon.
Das hin und her mit Vega und Navi, zu dem Adored ja interessante Details geliefert hat, kam kürzlich so halb in dem CES Roundtable zur Sprache. Ian Cutress von Anandtech wollte eine vollständige Abschrift liefern, hat das aber noch nicht getan.

PCGH hat eine (gruselig schlechte) deutsche Übersetzung für euch Englisch Legastheniker, aber viel wichtiger noch ein (unvollständiges) Video in dem man gut sieht, wie Lisa Su die Presse handhabt.

http://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/Specials/Lisa-Su-Interview-1273322/

Video Zeitstempel -7:30 bis -6:30

Interviewer: "The 7nm Vega was not supposed to be a consumer product"
Lisa Su: "Well you guys said that, i never said that! (lacht)"
Interviewer: "Really? Okay..."
Andere Person: "It wasn't Consumer in 2018"
Lisa Su: "I think what we said is we would do Datacenter first."
Interviewer: "Right"
Lisa Su: "I think this is what we said"
Lisa Su: (an AMD Marketing Mensch gerichtet) "Isn't that what we said?"
AMD Marketing Mensch: "We ... yes."
Interviewer: "You just didn't say anything else after that"
Lisa Su: "We didn't say anything else after that. Actually if i remember correctly, what i said at Computex in june was, you know, you will see 7nm gaming parts from us. And uhm, that's you know we always planned to bring Radeon VII to the market [...]"

Lisa Su hat hier bewusst während der Computex vage formuliert, wohl um sich die Option Navi oder Vega offen zu halten. Schenkt man Adored Glauben, dann wurde Navi wegen Problemen verschoben, und Vega als Lückenfüller in den Gaming Markt gesteckt.
Selbst wenn nicht, man sieht wie vorsichtig Su agiert, wie man sich Optionen offenhält.

Worauf will ich hinaus? Was zum Teufel wollt ihr von einem Tweet ableiten, in dem Su es toll findet, das Adored Zen so interessiert folgt?
Das Einzige was man davon ableiten kann, ist das AMD es wohl für gute Werbung hält, wenn die Leute dank Jim über AMD reden. Das ist auf dem gleichen Niveau, wie wenn Su zu einem BestBuy fährt und einen 500$ Ryzen Laptop kauft.

Denniss

2019-01-28, 14:25:14

Wenn der Leak echt wäre würde man das nicht liken, vor allem als CEO.Das Liken bedeutet wahrscheinlich "Nice try, try again"

bun

2019-01-28, 14:31:06

die schlussfolgerungen aus einer demo(keiner zen2 demo) von tsmc kann ich nicht nachvollziehen. zen+ ist ja auch an einer clockwall gescheitert nicht an zu wenig voltage. nur weil cache 5ghz bei -40° mitmacht kann man doch nicht drauf schließen das die zen2 cores ebenfalls 5ghz mitmachen, vorallendingen bei +60°?:freak:

Er hat beiläufig in einem Satz behauptet, das die Cache Frequenz gerne mal das Limit vorgibt, quasi wenn der Cache das schafft, läuft der Rest der Logik auch auf der Frequenz. Dann waren es nicht "nur" 5Ghz, sondern 5.36Ghz, und Jim merkte auch an das die Spannung noch recht gering ist, ich meine 1.12V.
Ist alles aus dem Kopf, habe das Video auch nur 1x kurz gestern Abend angeschaut, aber das Argument war schon Etwas elaborierter als deine Vereinfachung.

Was ich viel interessanter war, war die Aussage von Mark Papermaster, der während der CES ja so ganz verdächtig stark im Rampenlicht gefehlt hat, aber hier und da doch Interviews gegeben hat. Ich rieche ja schon wieder, das der zu Einer anderen Firma wechselt.

https://i.imgur.com/tKCAnql.png

BlacKi

2019-01-28, 14:50:00

Er hat beiläufig in einem Satz behauptet, das die Cache Frequenz gerne mal das Limit vorgibt, quasi wenn der Cache das schafft, läuft der Rest der Logik auch auf der Frequenz. Dann waren es nicht "nur" 5Ghz, sondern 5.36Ghz, und Jim merkte auch an das die Spannung noch recht gering ist, ich meine 1.12V.
ja, aber das stimmt halt einfach nicht. das design bestimmt stark wie viel takt man schafft, nicht der prozess alleine. und die cache demo hat einfach mal nichts mit ryzen zu tun. das ryzen deutlich besser performen wird muss nichts mit dem takt zu tun haben, ich sehe größere baustellen beim speicher bei zen+. da liegt mehr potential offen als beim core takt, der natürlich steigen wird.

amdfanuwe

2019-01-28, 14:53:05

Worauf will ich hinaus? Was zum Teufel wollt ihr von einem Tweet ableiten, in dem Su es toll findet, das Adored Zen so interessiert folgt?
Das Einzige was man davon ableiten kann, ist das AMD es wohl für gute Werbung hält, wenn die Leute dank Jim über AMD reden. Das ist auf dem gleichen Niveau, wie wenn Su zu einem BestBuy fährt und einen 500$ Ryzen Laptop kauft.
Ist sogar besser. Kostet Lisa nur ein paar Twitter Zeilen und erzeugt mehr Mediale Aufmerksamkeit.
Ebenso die Lederjacke auf der CES.
Da sind Werbeprofis am Werk um AMD im Gespräch zu halten.
Ebenso das Bild auf Lisas Twitteracount mit ihren Eltern zum 50. Hochzeitstag.
Da wird ein Image um Lisa aufgebaut.
Hoffentlich trommeln sie nur nicht wieder zu laut wie bei "poor Volta"

Unicous

2019-01-28, 15:20:26

https://i.imgur.com/tKCAnql.png

Hast du wirklich gerade einen Screenshot von einem Video gemacht, das wiederum ein screenshot ist von einem Artikel, anstatt das kurz zu googlen und die Primärquelle zu verlinken?:eek:

Pirx

2019-01-28, 15:23:28

der Großmeister des Papiers wurde doch gerade befördert

robbitop

2019-01-28, 15:28:09

Der kritische Pfad determiniert den maximalen Takt. Lange Signalwege oder zu wenig Zeit pro Pipelinestufe sind häufig das Problem. Der Cache wohl eher nicht.

bun

2019-01-28, 16:01:02

Ich hab da schlechte Nachrichten für euch.

https://i.imgur.com/PtZRL1G.png

Stand in dem "Paper" ??? zu der "Präsentation" ??? von TSMC ??? auf der IEEE 2018 ??? drin.
Also vielleicht mal TSMC ne Email rüberwerfen, das die zu doof sind ihre Prozesse richtig einzuschätzen.

EDIT:

Mehr:

https://ieeexplore.ieee.org/document/8310253

Abstract:
In high performance computing (HPC) applications, the speed of the L1 cache will typically determine the maximum frequency (/Max) of the processor core. Companies that mass produce high-performance microprocessors commonly have the L1 cache consist of fully-custom macros: to ensure that the performance of the L1 cache does not limit the fMAX or throughput of the processor. In addition, it is also common for the custom L1 cache designs to use a two-port 8T or a large 6T bitcell, along with domino read logic and very short BL [2,3]. These designs tradeoff density and area for high performance. This paper presents a different approach, one which can satisfy a range of different applications; a memory compiler that can generate more than 10,000 different high-speed L1 cache macro configurations is proposed. The 7nm L1-cache compiler described in this paper uses a high-current (HC) 6T bitcell, which is more area efficient than an 8T bitcell. The HC bitcell, along with small-signal sensing, allows for long BL (256b), leading to further area efficiency improvements. Since these L1 macros are just as likely to be used in mobile applications as they are to be used in HPC applications, they were implemented using the array dual-rail (ADR) architecture [4]. The ADR architecture (Fig. 11.3.1) allows the periphery circuits of the L1 macro to operate at the same voltage as the processor core: a lower l/DD results in dynamic power savings. ADR performance is also improved, over an interface dual-rail, when the SRAM and logic supplies are equivalent, as ADR design does not suffer from a level-shifter delays on the inputs or outputs.
Published in: 2018 IEEE International Solid - State Circuits Conference - (ISSCC)

mboeller

2019-01-28, 16:02:23

Teil der Switch-Logik im IO-Die dürfte sehr wahrscheinlich eine Art Cache-Directory sein, der eben als Snoop-Filter funktioniert. ....... wird.

Mal eine blöde Noob-Idee, basierend auf der IMHO etwas seltsamen Chiplet-Anordnung beim Rome. Könnten die Chiplets als eine Art Master-Slave arbeiten? Beim Matisse wäre also nur 1 Chiplet direkt mit dem IO-Chip verbunden und das 2. Chiplet nur mit dem ersten Chiplet. Beim Rome wären dann nur 4 Chiplet direkt mit dem IO-Chip verbunden.

Gipsel

2019-01-28, 16:04:59

Mal eine blöde Noob-Idee, basierend auf der IMHO etwas seltsamen Chiplet-Anordnung beim Rome. Könnten die Chiplets als eine Art Master-Slave arbeiten? Beim Matisse wäre also nur 1 Chiplet direkt mit dem IO-Chip verbunden und das 2. Chiplet nur mit dem ersten Chiplet. Beim Rome wären dann nur 4 Chiplet direkt mit dem IO-Chip verbunden.
Extrem unwahrscheinlich. Erstens verschlechtert das die durchschnittlichen Latenzen und dann hat AMD explizit gesagt, daß bei Rome jedes Kern-Chiplet mit dem IO-Die (und nur dem IO-Die) verbunden ist, welches also dafür 8 IFOP-Interfaces besitzt.

robbitop

2019-01-28, 16:19:06

@bun
deshalb haben Hochtaktdesigns viele Pipelinestufen (mit dem Nachteil einer hohen Penalty bei falscher Sprungvorhersage) und eine ganze Menge Massetransistoren (kostet Fläche) und verwenden idR keine High Density Labs (Fläche). Weil der Cache limitiert...

Das kann sicherlich bei manchen Auslegungen so sein. Es aber zu verallgemeinern birgt die Gefahr, dass man daneben liegt.

Der Prozess allein ist nur eine von vielen Variablen.
IBMs Power6 CPUs takteten schon vor einem Jahrzehnt mit rund 5 GHz. Trotz massiv älteren Prozesses.
Das Design hat offenbar einen größeren Einfluss als der Prozess.

Ein paar SRAM Zellen auf Betriebspunkte zu testen ist sicher ein gutes Mittel einen Prozess zu beurteilen (dafür ist tsmc ja auch verantwortlich) sagt jedoch nichts darüber aus welche anderen Flaschenhälse im CPU Design vorliegen, die poteziell dazu führen, dass diese Betriebspunkte eben nicht erreicht werden.

Gipsel

2019-01-28, 17:03:51

Daß die Taktmauer der Zens nicht zwingend transistorlimitiert, sondern eher leitungslimitiert sein könnte, habe ich schon vor einiger Zeit mal in den Raum gestellt (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11312802#post11312802)*. Ob das nun irgendwelche Funktionseinheiten oder den Cache betrifft, kann man aber ohne direkte Einblicke schlecht beurteilen.

*:
In der Nachbetrachtung ist ein Limit durch den L3-Cache nicht wirklich überzeugend, da man dort dann im Notfall die Latenz relativ feingranular erhöhen könnte (ob man 40 oder 42 Takte Latenz hat, ändert die Performance bei gleichem Takt meist kaum, so daß sich die Änderung lohnen würde, falls man dadurch 5% höher takten könnte [also falls der L3 das harte Limit war]). Eine Änderung der Latenz des L1-Caches von 4 Takten auf z.B. 5 Takte ist dagegen deutlich härter (und ein ziemlich massiver Eingriff in die CPU). Ein Limit durch den L1 ist also deutlich wahrscheinlicher als eins durch den L2 oder gar L3.

Complicated

2019-01-28, 17:51:57

Zumal die Pre-Zen APUs ohne L3 Cache auf die selben Taktgrenzen stiessen. Ich denke auch nicht der L3-Cache ist hier das Limit.

basix

2019-01-28, 18:47:19

Gipsel

2019-01-28, 18:57:27

Übrigens würde ich stark vermuten, daß AMD bei so einem zentralen Bestandteil einer CPU wie dem L1-Cache sich nicht unbedingt auf ein von TSMC geliefertes Makro verläßt, sondern da noch selbst ein wenig an den Stellschrauben dreht. Und weiß irgendwer überhaupt, welche Latenz das L1-Beispieldesign von TSMC gehabt hat?

Edit:
Sehe gerade, der Abstract wurde hier ja schon gepostet, aber dann mal einen Teil davon nochmal:
In high performance computing (HPC) applications, the speed of the L1 cache will typically determine the maximum frequency (/Max) of the processor core. Companies that mass produce high-performance microprocessors commonly have the L1 cache consist of fully-custom macros: to ensure that the performance of the L1 cache does not limit the fMAX or throughput of the processor. In addition, it is also common for the custom L1 cache designs to use a two-port 8T or a large 6T bitcell, along with domino read logic and very short BL [2,3]. These designs tradeoff density and area for high performance. This paper presents a different approach, one which can satisfy a range of different applications; a memory compiler that can generate more than 10,000 different high-speed L1 cache macro configurations is proposed. The 7nm L1-cache compiler described in this paper uses a high-current (HC) 6T bitcell, which is more area efficient than an 8T bitcell. The HC bitcell, along with small-signal sensing, allows for long BL (256b), leading to further area efficiency improvements.Sprich: Da ist noch jede Menge Platz nach oben für Eigendesigns von AMD (oder anderen TSMC-Kunden).

Zossel

2019-01-28, 19:33:25

Der Prozess allein ist nur eine von vielen Variablen.
IBMs Power6 CPUs takteten schon vor einem Jahrzehnt mit rund 5 GHz. Trotz massiv älteren Prozesses.
Das Design hat offenbar einen größeren Einfluss als der Prozess.

Power6 ist ein In-Order Design, IMHO mit SMT.

robbitop

2019-01-28, 19:45:40

Richtig. Der Punkt war ja dass das Design den größten Einfluss auf den maximalen Takt hat. ;)

BlacKi

2019-01-28, 19:47:38

Richtig. Der Punkt war ja dass das Design den größten Einfluss auf den maximalen Takt hat. ;)
und man vom cache takt nichts ableiten kann.

robbitop

2019-01-28, 19:52:45

So ist es.

mczak

2019-01-28, 20:00:12

Daß die Taktmauer der Zens nicht zwingend transistorlimitiert, sondern eher leitungslimitiert sein könnte,
Macht das einen Unterschied was man da allenfalls an Mehrtakt erwarten könnte allein durch 7nm ob es eher transistor- oder leitungslimitiert war?

Gipsel

2019-01-28, 20:07:33

Macht das einen Unterschied was man da allenfalls an Mehrtakt erwarten könnte allein durch 7nm ob es eher transistor- oder leitungslimitiert war?Transistorperformance skaliert, Leitungsperformance eher nicht (bzw. muß man aufpassen, kein negatives Scaling zu bekommen).
Die Leitungsperformance ist oft eine große Herausforderung für das Design, wenn man was deutlich Schnelleres haben will. In dem TSMC-Paper benutzen die z.B. sowohl breitere Leitungen und auch parallele, miteinander verbundene Leitungen in übereinander liegenden Metal-Layern (M1+M2), um bessere Leitfähigkeiten und somit eine geringere Verzögerung auf den Bitlines zu bekommen (die man dann dadurch im Vergleich zu den typischen Custom-L1-Makros verlängern kann).

BlacKi

2019-01-28, 20:08:18

Macht das einen Unterschied was man da allenfalls an Mehrtakt erwarten könnte allein durch 7nm ob es eher transistor- oder leitungslimitiert war?
werden wir an der v7 sehen, was der prozess alleine bringt. 1,7 gehen schon mit der vega1, mehr als 1,9 werden wir mit vega2 nicht sehen.

ryzen müsste was am design geändert haben für mehr takt, unabhängig vom fertigungsprozess um die 5ghz zu erreichen.

vielleicht kommen die 5,1ghz ja, aber es auf den prozess zu schieben ist einfach falsch.

Screemer

2019-01-28, 20:12:00

du kannst also von gcn auf ryzen projezieren. cool. erzähl uns mehr!

BlacKi

2019-01-28, 20:16:13

ich gesagt wir werden sehen was der prozess selbst für einen einfluss haben kann.

bun

2019-01-28, 21:13:20

Sprich: Da ist noch jede Menge Platz nach oben für Eigendesigns von AMD (oder anderen TSMC-Kunden).

6Ghz confirmed :eek:

mczak

2019-01-28, 21:30:13

Transistorperformance skaliert, Leitungsperformance eher nicht (bzw. muß man aufpassen, kein negatives Scaling zu bekommen).
Die Leitungsperformance ist oft eine große Herausforderung für das Design, wenn man was deutlich Schnelleres haben will. In dem TSMC-Paper benutzen die z.B. sowohl breitere Leitungen und auch parallele, miteinander verbundene Leitungen in übereinander liegenden Metal-Layern (M1+M2), um bessere Leitfähigkeiten und somit eine geringere Verzögerung auf den Bitlines zu bekommen (die man dann dadurch im Vergleich zu den typischen Custom-L1-Makros verlängern kann).
Ok, ich hätte gedacht auch wenn es leitungslimitiert ist könnte ein Shrink helfen. Immerhin werden ja die Leitungen kürzer, und wenn die Transistoren weniger Strom brauchen hilft das ja auch.
Aber ist wohl schon so dass die dünneren Leitungen eher ein Problem sind. Intel verwendet ja nicht bloss aus reiner Experimentierfreude bei 10nm Kobalt statt Kupfer (oder hat es zumindest versucht). Breitere (und parallele übereinander verlegte) Leitungen kann man ja wohl auch nicht beliebig verwenden (sonst wird dann alles grösser).

basix

2019-01-29, 09:15:12

In den heutigen Nanometer-Strukturen nimmt der parasitäre Widerstand glaube ich eher exponentiell oder sogar noch darüber zu. Eines der Probleme dabei ist, dass die Isolationsschichten nicht mehr viel dünner werden können, und dadurch der effektiv nutzbare Querschnitt deutlich stärker abnimmt als einfach linear mit der Strukturbreite. Der Artikel zu Intels 10nm beschreibt das recht gut:
https://fuse.wikichip.org/news/525/iedm-2017-isscc-2018-intels-10nm-switching-to-cobalt-interconnects/2/
http://semimd.com/blog/tag/cobalt/
https://semiengineering.com/dealing-with-resistance-in-chips/
https://fuse.wikichip.org/wp-content/uploads/2017/12/iedm-2017-intel-10-copper-wire-shrink.pnghttp://semimd.com/wp-content/uploads/2018/06/F2.jpghttps://semiengineering.com/wp-content/uploads/2018/06/fig5resist.png

basix

2019-01-29, 19:45:33

unl34shed

2019-01-29, 19:59:46

Für bessere SMT-Skalierung müssten denke ich mehr ALUs in den Core, so kann ein Thread prozentual weniger auslasten. Zumindest wäre das wohl der einfachste Schritt.

Beim L3 Cache bin ich mir nicht so sicher, du müsstest weniger Misses bekommen, also weniger wait-cycles bzw. eine höhere Kernauslastung. Das dürfte also eher hinderlich sein, da pro Thread weniger exklusive Zeit mit den gesamten Ressourcen zur Verfügung stehen.
Ist zumindest meine laienhafte Vorstellung davon ;)

basix

2019-01-29, 20:19:21

Mehr ALUs wäre ich mir nicht ganz sicher, von denen sind viele inaktiv (glaube bei 5-Wide werden gerade so 2 Instruktionen pro Takt rausgepresst).

Habe zu dem Thema aber eine sehr interessantes Arbeit gefunden. Ist von 2006 aber im Grundsatz gelten heute gleihe Bedingungen (SMT gabs damals schon).
http://www.ucdenver.edu/faculty-staff/dconnors/Documents/papers/phdthesis-settle.pdf

It has proved very useful for computing environments where severaljobs are run in parallel. However, SMT has not addressed the problem of improving the performance of individual jobs.

In particular, the shared cache hierarchy [29], and the instruction fetch and issue logic [20] have emerged as components that require special attention in an SMT environment.
...
Hily and Seznec demonstrated in [30] that the performance of multithreaded systems was limited by the cache hierarchy, in particular, the increase in bus contention introduced by the additional memory requests in an SMT machine model. This observation inspired later studies that focused on improving the
latency tolerance of SMT architectures

robbitop

2019-01-29, 20:20:13

Nichts sieht nach smt4 aus bis dato. Dafür müsste man sicherlich auch eine Menge umkrempeln.
Klang für mich damals schon unwahrscheinlich und bis dato hat sich dahin gehend nichts geändert in der Informationslage. War wohl eine Fehlinfo/Fehlinterpretation...?

basix

2019-01-29, 20:21:18

Wir reden auch nicht von SMT4, sondern dass SMT2 besser skaliert ;) Sagen wir beispielhaft +60% in Cinebench R15 anstatt +40%. Durch mehr Cahce stehen mehr Ressourcen zur Verfügung, welche sich speziel bei SMT vorteilhaft bemerkbar machen müssten.

Mal ein wildes Beispiel:
Bei 96% auf 98% Steigerung der Hitrate bei Verdopplung L3 macht das den Braten nicht so fett (IPC Steigerung). Bei SMT aber dann von 80% auf 96% Hitrate pro Thread wäre ein grosser Sprung.

Brillus

2019-01-29, 20:21:25

Eine Frage zum doppelten L3$: Es gab eine Aussage eines AMD Mitarbeiters (weiss nicht ob es Papermaster war) man solle eher die Threads als die Kerne zählen. Könnte der grössere L3$ ein stark verbessertes SMT ermöglichen? Schlussendlich hätte man pro Thread gleich viel Cache wie vorhin nur mit einem einzelnen Thread. Oder müsste man für ein verbessertes SMT eher den L1/L2 aufbohren?
Ich denke eher die Assosativität erhöhen, damit sich die Threads nicht gegenseitig den Cache killen.

Aber für SMT skalierung ist wohl die Anzahl der Ausführungseinheiten am wichtigsten.

SKYNET

2019-01-29, 20:24:34

naja, SMT funzt auf AMD eh schon DEUTLICH besser als es jemals auf intel tat, von daher sehe ich da schon kleine hoffnungen das sies noch weiter optimiert haben.

basix

2019-01-29, 20:31:34

Jepp, AMDs SMT ist wirklich ziemlich gut. Aber da es der erste Wurf war, wieso nicht noch etwas mehr erwarten ;) Aber vielleicht haben sie aus ihrer CMT Zeit was mitnehmen können.

Zumindest sollte der Off-Chip Traffic aufgrund des vergrösserten Caches stark reduziert sein. Für die Energieeffizienz und die durschnittlich Latenz sicher förderlich.

Hier noch ein Beispiel dazu. Meistens bewegt man sich aber eh bei >90% Hitrate nur schon beim L1.
https://lwn.net/Articles/252125/
https://static.lwn.net/images/cpumemory/cpumemory.33.png

Setsul

2019-01-29, 23:26:06

Mehr ALUs sind in der Tat nur begrenzt sinnvoll. Man kann sich das mit gewissen Abschätzungen vor Augen führen. Wenn man von 50% ALU, 20% Branches, 20% Loads, 10% Stores ausgeht (das schwankt natürlich) und 2 Loads oder 1 Load + 1 Store pro Takt wie bei Zen1 dann kann man mit mehr als 4 ALUs nicht wirklich etwas anfangen, weil man an dem Drittel das Loads und Stores braucht hängt. Wenn man jetzt auf 2+1 erweitert dann könnte man rein rechnerisch 7 ALUs/Branch Units beschäftigen, aber schon für 4 braucht man 7 Instructions pro Takt. Die Decoder können nur 4, der Op Cache theoretisch 8 aber nur wenn die Lines voll sind und der Renamer kann sowieso wieder nur 5 und dann muss das alles auf die INT Seite die nur 6 µops verkraftet. Also es ist nicht so dass man nicht mehr ALUs will, aber ohne entsprechend breiteres Front End hält sich der Nutzen in Grenzen. 4 ALUs sind meistens genug und bei Zen löst sich das Problem sowieso in Luft auf sobald SIMD oder FP ins Spiel kommt.

Bezüglich L1/L2 Cache kommt es sehr aufs Programm an. Wenn das fürchterlich optimiert ist für 32 kiB L1D und dann muss es sich den mit einem anderen Thread teilen wird es nicht sehr glücklich sein. Beim L1D hängt man sehr ein VIPT und damit 4 kiB way-size weil es einfach enorm praktisch ist und alles über 8-way ist von den Kosten her anscheinend nicht so angenehm. Mit Sunny Cove geht Intel jetzt wohl auf 12-way, aber das hat 13 Jahre gedauert. L2 ist immer ein schwieriger Kompromiss zwischen Latenz, Größe und Stromverbrauch. SKL-X braucht die 1 MiB für AVX512 aber bei Zen2 lohnt sich das wahrscheinlich nicht.

Beim L3 Cache sind die Überlegungen vielleicht sehr viel einfacher. 2 MiB LLC pro Kern oder sogar nur 1 MiB/Kern reichen zwar bei 20 Kernen und 20 bzw. 40 MiB L3, aber eben nicht bei nur 4 Kernen. Ein 10-16 MiB working set passt bei einem 8 Kern Xeon wunderbar in die 20 MiB, aber Zen mit 2x8 MiB hat damit fürchterliche Probleme.
Nach ein bisschen suchen hab ich dazu auch wieder was gefunden:
https://web.stanford.edu/~geayers/files/websearch_hpca18.pdf
Kurz gesagt für Google sind 1 MiB pro Kern, nicht pro Thread, ideal, aber:
For example, all 18-core designs with less than 1 MiB/core perform worse than other designs with fewer cores. A corollary to this observation is that, unlike prior work [37], the LLC must hold more than the instruction working set, since any capacity less than 18 MiB is detrimental despite a 4 MiB code working set (§III-B). In other words, we must
carefully rightsize the L3 cache.
Graphen dazu auf Seite 7, Text auf Seite 8.

Also der Code braucht zwar nur 4 MiB, aber bei dem 20-way L3 (Xeon mit 2,5 MiB/Kern, Desktop und Zen haben nur 16-way) heißt das, dass die Daten ein bisschen vom Code wieder rauskegeln und deshalb sogar ein bisschen über Kernzahl + 4 MiB hinaus etwas bringen. Figure 9 auf Seite 8 zeigt in 4,5 MiB Schritten was passiert. Also bei 4 Kernen sieht man dass von 4,5 auf 9 ein gewaltiger Sprung ist und selbst 13,5 sind noch deutlich spürbar.
Wenn man jetzt eine Workload hat die nicht nur 1 MiB/Kern sondern 2 oder eben 1 MiB pro Thread will dann sind 16 MiB für 4 Kerne gar nicht so unnütz.

Man kann jetzt die große Debatte unified vs distributed LLC wieder anfangen, wobei Intel auch mit SNC den L3 wieder trennt weil bei >20 Kernen dem Ganzen einfach Grenzen gesetzt sind und Latenz und Stromverbrauch sonst in die Höhe schießen, aber beim Chiplet Design geht das sowieso nicht. Der CCX-Ansatz hat Vor- und Nachteile und man kann mit den Nachteilen unterschiedlich umgehen, 8 Kern CCX würden auch helfen, sind aber aus anderen Gründen schwierig und ungünstig (hab ich schonmal erwähnt), aber den L3 zu verdoppeln hat klare Vorteile. Auf 7nm kann man sich es leisten, es ist vielleicht nicht sonderlich elegant, aber es ist einfach und funktioniert und für jede Lösung dieser Art ist AMD wahrscheinlich dankbar.

gravitationsfeld

2019-01-30, 06:26:44

Scheduling ist halt nicht immer einfach. Es kann durchaus passieren, dass gerade ein Port blockiert ist der fuer eine bestimmte Op gebraucht wird, obwohl die blockierende Op auch auf einem anderen haette laufen koennen der frei ist. Das bekommt man nie perfekt hin. Mit SMT ist das auch noch schwieriger.

Ich seh darin den hauptsaechlichen Grund, warum man immer mehr den Ports fast alle Ops gibt. In Sunny Cove koennen jetzt z.B. alle int-ports LEA.

Setsul

2019-01-30, 10:06:53

Kochtopf

2019-01-30, 11:29:40

Nach ein bisschen suchen hab ich dazu auch wieder was gefunden:
https://web.stanford.edu/~geayers/files/websearch_hpca18.pdf

Sehr spannendes Paper, vielen Dank dafür!

Also der Code braucht zwar nur 4 MiB, aber bei dem 20-way L3 (Xeon mit 2,5 MiB/Kern, Desktop und Zen haben nur 16-way) heißt das, dass die Daten ein bisschen vom Code wieder rauskegeln und deshalb sogar ein bisschen über Kernzahl + 4 MiB hinaus etwas bringen. Figure 9 auf Seite 8 zeigt in 4,5 MiB Schritten was passiert. Also bei 4 Kernen sieht man dass von 4,5 auf 9 ein gewaltiger Sprung ist und selbst 13,5 sind noch deutlich spürbar.
Wenn man jetzt eine Workload hat die nicht nur 1 MiB/Kern sondern 2 oder eben 1 MiB pro Thread will dann sind 16 MiB für 4 Kerne gar nicht so unnütz.

Ich versuche deinen Gedankengang nachzuvollziehen, sieht schlüssig aus für 1 MiB -> 2 Mib pro Core bei 4 Kernen. Zen+ hat aber 2MiB L3 pro Core und bei Zen2 ist es von 2 -> 4 MiB. Da sehe ich in deinem zitierten Diagram aber gar nicht mehr so große Sprünge für Google-Workload (4-kern linie: 2. punkt -> 4. Punkt, gleiches bei 8 Kern: 4. -> 8. pt). Deswegen frage ich mich ob die Sättigung des IPC-Increase vielleicht doch früher einsetzt als dein Post hoffen lässt? Oder mir fehlt ein Stück im Gedankenpuzzle.

Setsul

2019-01-30, 11:55:03

Die Überlegung war bei 1 MiB/Kern für das working set + 4 MiB für den Code + etwas mehr für conflict misses und ähnliches reichen 2 MiB/Kern bei 8 oder mehr Kernen locker aus (8*1+4+Puffer < 16) aber bei 4 Kernen (4*1+4 = 8) wird es knapp.
Der 2. Punkt in der 4-Kern-Linie ist ja schon bei 9 MiB, von ein bisschen vor diesem Punkt zu zwischen dem 3. (13,5) und 4. (18) ist schon ein Unterschied.

Wie gesagt das ist eine Workload die nominell 1 MiB/Kern braucht. Bei >10 Kernen stimmt das auch ungefähr, aber bei 4 eben noch nicht. Wenn man sich jetzt eine Workload mit 1,5 MiB/Kern und/oder 6 MiB Code nimmt, dann hat man ab 12 Kernen und 2 MiB Cache pro Kern keine Probleme, aber bei 4 Kernen mit 8 MiB sieht es verdammt düster aus. 4*1,5+6 = 12, da reichen 8 MiB definitiv nicht.

Also 4 Kerne + 8 MiB deckt sicherlich schon einiges ab und vieles wird von den 16 MiB nicht mehr spürbar profitieren, aber Google würde laut dem Paper wohl ~10% bekommen und es gibt schließlich noch "schlimmere" Workloads, sonst würde Intel bei >20 Kernen nicht immernoch 2,5 MiB/Kern verbauen sondern wieder runtergehen.

basix

2019-01-30, 12:19:51

Danke @Setsul für die Erklärung. Beim Workload-Anteil (pro Kern) kommt also noch ein Code Anteil (unified für alle Kerne im selben "Block") dazu, d.h. man kann das separieren. War mir so jetzt nicht bewusst. Macht aber absolut Sinn, das so zu machen.

War nicht in einem der Paper eine Grafik wo man sah, dass vor allem Applikationen mit einem eher zufälligen Zugriffsmuster am meisten von einem grösseren Cache profitieren, speziell im SMT Fall? Spiele wären da vermutlich ja ein Kandidat?

Und noch was ganz anderes: Beim AdoredTV Beitrag hat er den Package Shot mit dem stark verstärkten Kontrast gezeigt. Ist ein eher schwacher Beleg aber wieso nicht: Könnte es sein, dass AMD etwas an der CCX-Architektur gedreht hat und nicht 2x 4C CCX verbaut? Wenn das in der Mitte wirklich eine entsprechende Crossbar ist, würde das sehr einem CCX vom Aufbau her ähneln. Nur das jetzt anstatt 1 Kern jeweils 2 Kerne an jeder Ecke des Moduls vorhanden wären und der L3-Cache unter Umständen "gesplitted" ist. Über die Crossbar hätte man wieder die total 6 Verbindungen zu jedem der anderen 2-Kern-Blöcke. Wieso mir das gefallen würde (wenn das der Latenz, Performance etc. nicht schadet): Bei Zen 3 könnte man einfach den 2-Kern Block auf 3-Kerne aufbohren, ohne irgendwas an der Architektur zu ändern oder zusätzlich Module hinzufügen zu müssen.

bun

2019-01-30, 12:35:09

Es kam von AMD doch die Aussage das softwareseitig keine Anpassungen für Zen 2 nötig wären, was die Berücksichtigung der CCX angeht? Man möchte wohl das was man mit Ryzen 1000 und 2000 da nun erreicht hat mit der nächsten Gen weiter nutzen, und nicht wieder einen neuen Softwareoptimierungszyklus lostreten.

Ich habe da gerade keine Quelle parat, meine das war ein Zitat von Papermaster das ich vor ein paar Tagen gelesen hab.

MR2

2019-01-30, 12:35:39

@bun
https://www.tomshardware.com/news/ryzen-amd-third-gen-7nm-processor,38474.html
Papermaster: AMD's 3rd-Gen Ryzen Core Complex Design Won’t Require New Optimizations

http://www.pcgameshardware.de/Mainboard-Hardware-154107/News/Fuer-AMDs-Ryzen-3000-Asrock-bereitet-neun-X570-Mainboards-vor-1274279/
Für AMDs Ryzen 3000: Asrock bereitet neun X570-Mainboards vor

basix

2019-01-30, 12:45:29

Das mit der Aussage zur Softwareanpassung ist mir bewusst. Heisst aber nicht, dass man nicht dennoch was dreht. Die Wahrscheinlichkeit sinkt, das ist wahr. Kann aber auch sein, dass man jetzt eben 2-Chiplets hat anstatt 2 CCX und sich das dann so in wieder SW mässig in 2 Module aufteilt. Würde doch passen, den Workload möglichst nur auf einem Chiplet laufen zu lassen, wie vorher innerhalb des CCX. Anzahl der Module pro CPU aber immer noch 2. Andernfalls müsste man doch für die Desktop-Chips bis zu 4 CCX abbilden. Würde doch SW-Anpassungen benötigen, oder nicht? Oder wird die Anzahl CCX aus dem Prozessor ausgelesen?

Es geht mir eben darum, dass man bei der oben beschriebenen Idee immer noch von aussen gesehen gleich viele Module mit niedriger Latenz hätte. Für EPYC würde genau das selbe gelten. 2-Chiplets auf jeder Seite = 2 CCX bei EPYC1 innerhalb des Summit Ridge DIE. Jeweils 8 präferiere Low-Latency Blöcke, möglichst wenig zwischen den anderen CCX oder eben neu Chiplets Daten rumschieben, um die Latenz tief zu halten. Von der Software her würde das ja wohl von aussen gesehen gleich oder zumindest sehr ähnlich aussehen. Splittet man jetzt das Chiplet wieder in zwei Teile auf, hätte man noch mehr fragmentierte Blöcke, welche man verwalten muss.

Sieht das Chiplet eben auch so aus wie beschrieben, wäre es sehr einfach für Zen 3 / Zen 4, den Core-Count auf 12-16 Kerne pro Chiplet zu erhöhen, ohne dabei die Aufteilung der Blöcke zu verändern. Das würde meiner Meinung nach sehr helfen, da keine neuen SW-Optimierungen eingeführt werden müssen, hat man seine SW mal auf Zen 1 angepasst gehabt. Wenn ich mal Zeit habe, zeichne ich dazu mal was auf.

robbitop

2019-01-30, 12:56:30

Wenn es pro Chiplet nur ein 8C CCX wäre, wäre das Latenzdiagramm anders. Dann hätte 1x CCX 32 MiB. Erkennbar ist, dass 1x CCX nur 16 MiB hat.
Das wäre nur erklärbar, wenn der L3 Cache nicht verdoppelt wäre sondern nur aus 2x CCX 1x CCX geworden wäre.

bun

2019-01-30, 12:58:36

Du wirfst wahllos irgendein Zeug in den Raum, wo selbst mir als absolutem Laien in Mikroprozessorarchitektur durch zufällig Aufgeschnapptes klar ist, das das Unsinn ist.

Deine letzten 3 "Theorien":

1. Cache wurde verdoppelt damit SMT besser skaliert

Gegenthese:

- Cache musste vergrößert werden, um Cache misses zu verringern, weil der IMC jetzt ausserhalb liegt, und sich die Speicherlatenz erhöht, siehe Benchmark Grafiken von Zen2, Zen1 und Intel 2-3 Seiten weiter vorne
- 7nm erlaubt schrumpfen des Caches, daher ist der Weg gehbar

2. AMDs SMT skaliert besser als Intel

Gegenthese:

- AMD kriegt ihre Ausführungseinheiten im single thread schlechter ausgelastet, hat mehr brach liegen, und daher kann SMT mehr rausholen. Das Argument habe ich vor ein paar Tagen Irgendwo gelesen, es macht Sinn, und kam von Jemandem mit mehr Ahnung als wir Beide zusammen.

3. Ich kann den CCX Kram von dir gar nicht zusammenfassen, zu verwirren.

Gegenthese:

- AMD hat gesagt an den CCX ändert sich nichts, was zu Softwareänderungen führt
- AMD zeigt chiplet mit 8 Kernen, was auf 2x4c CCX schließen lässt, wie bei Zen1 bekannt

Aber Adored ankacken, weil der liegt ja nicht immer 100% richtig. Wenigstens macht Jim sich 2 Wochen lang Gedanken und formt aus den Details die er findet immer stichhaltige Theorien, die Sinn ergeben (auch wenn sie natürlich weiterhin nur spekulierte Theorien sind)

BoMbY

2019-01-30, 13:07:53

basix

2019-01-30, 13:10:27

@bun:

OK, als Laie weisst du natürlich, dass es definitiv so ist. Bemerkst du den Widersrpuch? ;)

Es sind keine Theorien, dass es genau deswegen gemacht wurde. Sondern dass es in entsprechenden Szenarien helfen könnte. Da ich es, als Laie, ja nicht mit Bestimmtheit weiss, spekuliere ich darüber. Dann entsteht eine Diskussion wo man es dann untermauern kann oder widerlegen kann (von Leuten, die täglich damit arbeiten). Wenn du das natürlich genau weisst, dass es nichts bringen kann, OK.

Deine Gegenthesen sind am Schluss ja genau die selbe Speku. Wissen tun wir den inneren Aufbau nicht im Detail. Wie es gegen aussen aussieht (z.B. Sofware Anpassungen) ist ein ganz anderes Thema. Wenn AMD hier sagt es ist so, wird es so sein. Hier anzunehmen, dass sich an der HW aber dadurch nichts ändern wird, finde ich falsch.

Ach ja zu Adored: Ich habe ihn gar nicht angekackt. Ich schaue jedes seiner Videos und finde seine Ausführungen interessant. Sonst würde ich ihn gar nicht erwähnen. Aber man sollte alle Infos mit einem Grain of Salt nehmen, egal aus welcher Internet Quelle. Und dass irgendein Bild des Packages genau den Chip-Floorplan zeigt ist ein Beispiel davon. Selber denken und etwas kritisch betrachten ist das Zauberwort.

mboeller

2019-01-30, 15:47:06

seeking Alpha transcript:

https://seekingalpha.com/article/4236505-advanced-micro-devices-inc-amd-ceo-lisa-su-q4-2018-results-earnings-call-transcript?page=3

In client computing, we started the year with our second generation Ryzen mobile processors and we’re on track to launch our third generation Ryzen desktop processors in the middle of the year. And in the server market, we expect to deliver a significant step function performance increase with the launch of our next generation Rome processors in the middle of the year

schade, doch ein wenig später als gehofft

bun

2019-01-30, 16:28:26

Das sich an der Software nichts ändern muss, heißt nicht zwangsläufig, dass sich am CCX nichts ändert. Die Systeme sollten jetzt mit deutlich mehr Konfigurationen klar kommen, wenn die CPU-Daten korrekt ausgelesen und angewendet werden.

Du kennst dich scheinbar besser damit aus. Magst du mal Details erklären?

@bun:

OK, als Laie weisst du natürlich, dass es definitiv so ist. Bemerkst du den Widersrpuch? ;)

Es gibt keinen Widerspruch. Selbst als Laie gelingt es das sofort zu erkennen, weil es klare Äußerungen von Experten zu dem Thema gab, die durch die Tech Presse ging. Das muss man nur Lesen und sich Merken.

Zum Rest: Dir ist vielleicht aufgefallen, das ich 3 völlig unterschiedliche Ansätze von dir aufgegriffen und Alle 3 gleichzeitig verworfen habe. Denn erst beim Lesen des dritten Posts mit dem dritten Ansatz den ich überhaupt nicht nachvollziehen kann, ist mir aufgefallen das bei dir da ein starkes Muster dahinter steckt.

Spekulieren kann man anhand von gar keinen Daten und Fakten, oder anhand von vielen Daten und Fakten.

Es wurde nun seit Wochen darüber gemunkelt, das AMD bei Ryzen wohl auch einen 14nm IO Die mit externem MC verwenden könnte, was erfahrungsgemäß die Speicherlatenz erhöht. Es wäre logisch, das mit mehr L3 Cache zu kompensieren. Es wäre auch logisch, das man mehr L3 nun auch problemlos umsetzen kann, weil 7nm die Transistoren hinreichend schrumpft, und die Kostenrechnung aufgeht. Das ist für mich eine faktenbasierte Spekulation, warum AMD den L3 Cache vergrößert, die auch von Benchmarks hier schon gut belegt wurde.
Wenn ich dann deinen Post zu SMT lese, welche Fakten stehen dahinter? Was veranlasst dich das zu Spekulieren? Das ist doch eine ganz andere Klasse an Wahrscheinlichkeit?

Das Gleiche trifft mehr oder minder auch auf die anderen Theorien zu.
1. AMD sagt, die CCX haben sich nicht in einer Art und Weise geändert, die Softwareänderung erfordern.
2. Irgendwoher kam die Information, wie die Cores auf den neuen Epycs verbunden sind, ich glaube über neue Latenz Infos, gleichmäßigere
Latenzen über alle Cores hinweg? Ich bin mir da nur halb sicher.
3. Adored gräbt ein high res foto auf, und findet traces auf dem package und entwickelt dazu eine recht stichhaltige Theorie wie die das IF aussieht, basierend wohl auch auf 1. und 2.
Nun kommst du mit einer anderen Theorie daher, die komplett gegenläufig ist, mit einem Argument das ich immer noch nicht logisch nachvollziehen kann.

Das ist kein persönlicher Angriff. Man kann hier natürlich alles Spekulieren. Ich finde nur das man versuchen sollte, die bestätigten Fakten und wahrscheinliche Szenarios nicht zu ignorieren, weil sonst sind die Spekulationen selten auch nur in der Nähe der Realität.

BoMbY

2019-01-30, 18:15:41

Du kennst dich scheinbar besser damit aus. Magst du mal Details erklären?

Was denn? Die Systeme lesen die unterstützen Funktionen und die Konfiguration hauptsächlich per CPUID aus, und setzen das entsprechend z.B. im Scheduler um.

Für Ryzen siehe: https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf

basix

2019-01-30, 18:24:23

@bun:

Keine Angst, ich nehme das nicht persönlich. Der Ton spielt die Musik ;)

Das mit dem I/O Die und dem vergrösserten L3 macht alles Sinn. Ich stelle nur die Frage, ob es abseits der reduzierten Latenz noch Fälle gibt, wo man davon profitieren kann. Die effektive Auslastung pro Thread könnte steigen, da pro Thread mehr Ressourcen verfügbar. Ein Beispiel kam ja schon von Setsul mit der Google-Workload. Ich habe ein Beispiel aus einem Paper gebracht, wo eindeutig beschrieben wird dass SMT von den Caches abhängig ist. Interference der Threads ist hier so ein Thema, welches man mit einem grösseren Cache abmildern kann. Ergo, was könnte das Resultat sein? Besseres SMT Scaling --> Mein Speku-Gedanke. Ist diese Annahme also so abwegig?

Und noch zu deiner Aufzählung:

SW Kompatibilität bedeutet nicht identischer HW Aufbau, da muss ich mich wiederholen. Ich erwarte nicht, dass das 4C CCX abgeschafft wird, es gibt einige Daten die für ein 4C CCX sprechen. Das streite ich nicht ab. Wenn ich aber auf dem Bild von Adored aufbaue und sich der Chip-Floorplan im Package abbilden lässt (was wie gesagt etwas Kaffeesatzleserei ist), dann gibt es da noch einen Widerspruch in der Analyse von Adored (siehe 3. zur IF-Crossbar)
Diese Info stimmt bezüglich Speicherzugriffen auf den RAM. Jedes Chiplet hat den gleich langen Weg vom Core zum I/O Die zum RAM. Bei EPYC musste man je nach Lage der Daten im Speicher auf den lokalen Memory Controller zugreifen oder auf den eines anderen Chips. Das fällt mit Rome weg, deswegen wird es homogener. Meines Wissens nach wurde aber nichts über die Latenzen innerhalb der Chiplets von Core zu Core etc. gesagt. Deshalb sagt die Info nichts über den internen Aufbau des Chiplets aus.
Adored spekuliert, dass es das CCX gleich aussieht wie bei Zen 1. Nicht falsch, aber eben spekuliert. Aber wenn wir schon hier sind: Schau dir die Stelle im Video an wo er die IF-Crossbar einzeichnet. Interessant ist hierbei die vertikale Linie. Wenn dies wirklich IF-Logik ist, würde sie mitten durch den L3$ des gesamten CCX durchgehen. Erstens ist das anders als bei Zen 1 und zweitens würdest du den L3$ von der Anordnung her aufteilen. Das passt nicht zu einem CCX wie bisher. Entweder Adored liegt hier falsch oder es hat sich doch was am Aufbau geändert. Dazu habe ich aber noch vor ein Bildchen zu malen und hier posten, dann wird das vielleicht etwas verständlicher. Das grösste Gegenargument für meine Hypothese ist die Latenzmessung des UserBenches.

Um den Thread hier nicht noch mehr zuzuspammen: Wir können das gerne auch per PN noch fertig diskutieren. Falls du keine Lust hast, auch OK.

Gipsel

2019-01-30, 19:00:22

Auch das Problem hat Zen kaum weil jede ALU einen eigenen Port hat. Bei Intel kann FP/SIMD Branch/INT/LEA blockieren oder DIV kann einen Branch blockieren oder viele andere Variationen.
Bei Zen sind Branch, MUL und DIV auf unterschiedlichen Ports und fast alles andere läuft auf allen Ports und FP/SIMD ist sowieso getrennt. Versuch einfach mal eine Kombination von INT Ops zu finden bei der dein Szenario eintritt.Zen hat anders als intel-CPUs allerdings keinen gemeinsamen Scheduler für alle Ports (noch nicht mal für Alles was Integer ist), sondern grob ähnlich wie K7/K8/K10 sechs separate Scheduling-Queues auf Integer-Seite (FP/SIMD hat dagegen einen unified Scheduler für alle Ports). Es kann also durchaus vorkommen, daß im Prinzip zwar ein passender Port frei wäre, die Instruktion aber in einer "falschen" Queue steckt. Da gibt es also in bestimmten Fällen schon noch Reserven und dürfte auch mit ein Grund sein, warum SMT bei Zen oft recht viel bringt.

Edit:
BD hatte dagegen einen Integer-Scheduler für Alles (waren aber auch nur 2 ALUs und 2 AGUs), Bobcat/Jaguar hatte einen ALU-Scheduler (für 2 ALUs), einen AGU-Scheduler (für die 2 AGUs) und einen FP/SIMD-Scheduler (für die 2 FP/SIMD-Ports). K7/K8/K10 hatte 3 Integer-Scheduler (für jeweils ein ALU/AGU-Paar) und einen FP/SIMD-Scheduler für alles dort.
Zen (die 6 Integer-Scheduling-Queues haben jeweils 14 Einträge [um das mal mit dem K7-K10 zu vergleichen, wo es 3x8 Einträge gab]):
https://en.wikichip.org/w/images/thumb/d/d3/amd_zen_hc28_overview.png/600px-amd_zen_hc28_overview.png
Achja, Nehalem hat im Scheduler Platz für 36 Instruktionen, Sandybridge für 54, Haswell für 60, Broadwell 64 und Skylake schließlich für satte 97 (jeweils für alle Ports zusammen, da unified). Wieviele Einträge bei Zen auf FP-Seite zur Verfügung stehen (zusätzlich zu den 6x14 auf Integer-Seite), konnte ich jetzt auf die Schnelle nicht rauskriegen (werden wohl aber mehr als die 36 vom K8 sein).

K8 (K7 und K10 sahen im Prinzip identisch aus):
https://images.anandtech.com/reviews/cpu/amd/hammer/hammer.gif

Bobcat/Jaguar:
https://hothardware.com/newsimages/Item14235/BobcatDetail1.jpg

BD:
https://upload.wikimedia.org/wikipedia/commons/e/e9/AMD_Bulldozer_block_diagram_%28CPU_core_bloack%29.PNG

robbitop

2019-01-30, 19:37:44

@smt Skalierung. Ian Cutress hatte zum Zen Launch erläutert wie AMD smt implementiert hat.
https://www.anandtech.com/show/11170/the-amd-zen-and-ryzen-7-review-a-deep-dive-on-1800x-1700x-and-1700/10
IIRC erklärte dies zumindest zT die bessere Skalierung außerhalb des Arguments, dass Intel ihre mArch ggf ein wenig mehr auslastet.

Gipsel

2019-01-30, 19:49:39

IIRC erklärte dies zumindest zT die bessere Skalierung außerhalb des Arguments, dass Intel ihre mArch ggf ein wenig mehr auslastet.Das macht intel auch nicht viel anders.
Die unified Scheduler von intel gegen 6xInt +1xFP Scheduler bei Zen helfen aber schon ein wenig, um die gegebenen Einheiten mit einem Thread etwas besser auszulasten. Der Vorteil verschwindet dann tendentiell mit zwei Threads.

Setsul

2019-01-30, 20:32:43

@basix:
Zugriffsmuster sind schwierig. Zufällig im Sinne von gut auf verschiedene Sets verteilt ist gut, bei zufällig im Sinne von jede Adress triffts nur einmal bringen Caches nichts.

Relativ: Die Latenz (Anstieg >16 MiB) passt nicht und ein Crossbar ist nicht kreuzförmig. Man könnte so eine Kreuzform nur bekommen wenn man den L3 zwischen die Kerne schiebt so ähnlich wie bei Skylake, aber das ist völlig unabhängig von der Größe des CCX. IF alleine würde niemals so einen breiten Streifen belegen. IF würde außerdem nicht die Kerne untereinander verbinden. Die Existenz eines Crossbars ist unabhängig von der Größe der CCX. Bei Zen1 sind die Kerne schließlich auch mit dem L3 verbunden.
Das ist genauso aus der Luft gegriffen wie "doppelte Leistung aber ganz sicher nur 12 Kerne also muss die IPC um 17% steigen".

@bun:
1. Bisschen was von A, bisschen was von B und bisschen was von C? Mehr Cache auch deshalb weil manche Programme von mehr L3 profitieren. Wenn der Bedarf mit der Anzahl der Threads skaliert hilft das indirekt natürlich auch SMT. Man nimmt alles mit, letztendlich läuft es auf mehr Cache bei gleicher Latenz = besser raus und 7nm machts möglich.

2. Auch hier kommen mehrere Sachen zusammen. Zen hat auch einfach mehr Ports, bekommt unter Umständen mehr durch den Renamer und bekommt auch max 8 Ops aus dem Op Cache statt 6 wie SKL.
Also es gibt auch genügend Beispiele (z.B. 3DPM) wo Zen ohne SMT hinten liegt aber mit SMT dann vor Intel liegt. Das lässt sich allein durch schlechte ST-Auslastung nicht erklären.
https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/

@Gipsel:
Ja, aber das ist einfach ein Nachteil des Scheduler-Designs. Das ist kein Problem das dadurch entsteht, dass die einzige ALU die DIV kann durch ein LEA blockiert ist und deshalb bräuchte man mehr Ports die LEA können, so wie gravitationsfeld das beschrieben hat. Das entsteht dadurch dass in einer Queue 2 Instructions stecken die bereit sind und einer anderen 2 die es nicht sind (oder gar keine). Natürlich könnte man jetzt 8 ALUs bauen um das Problem abzuschwächen aber da ist ein Unified Scheduler doch einfacher. Anderes Problem, andere Lösung.

Es ging ja ursprünglich darum ob mehr ALUs sinnvoll wären und als Lösung für dieses Problem sind sie es definitiv nicht.

Gipsel

2019-01-30, 20:42:54

Ja, aber das ist einfach ein Nachteil des Scheduler-Designs. Das ist kein Problem das dadurch entsteht, dass die einzige ALU die DIV kann durch ein LEA blockiert ist und deshalb bräuchte man mehr Ports die LEA können, so wie gravitationsfeld das beschrieben hat.Völlig klar, daß das praktisch das umgekehrte Problem ist. Bei intel hat man öfter mal Instruktionen, die nicht gescheduled werden können, weil die passende ALU beschäftigt ist (aber der Scheduler im Prinzip Ports frei hätte), bei Zen hat man öfter mal Instruktionen, die nicht gescheduled werden können, obwohl eine passende ALU frei ist, weil die Instruktion im falschen Scheduler hängt (dessen Port gerade von einer Instruktion belegt wird). Andere Ursache, ähnliche Auswirkung (darum ging es mir). Bei AMDs Problem hilft es aber tendentiell mehr, einen zweiten Thread draufzuwerfen (weswegen das in die im Schnitt etwas bessere SMT-Skalierung reinspielen dürfte).

basix

2019-01-30, 21:45:49

Also ich habe mal versucht, meinen Gedanken künstlerisch darzustellen ;)

Was ich als Laie eben elegant finde ist folgender Punkt: Ryzen und EPYC sieht aus der Vogelperspektive gleich aus, wenn man die Zen Generationen vergleicht (Ausnahme Epyc 1, ist aber nah dran). Da gleichbleibende Anzahl "Low Latency Bereiche" greifen auch allfällige Zen 1 Software-Optimierungen. Für mich sieht das nach einem sinnvollen Konstrukt aus. Ich kann mich aber irren ;)

Noch als Hinweise zur Grafik:

Das I/O Die bei Matisse und einer allfälligen Zen 3 CPU habe ich weggelassen, da in dieser Betrachtung nicht unbedingt nötig. Es geht nur um Cores, CCX etc. und deren Kommunikation untereinander.
Innerhalb der "Low Latency Bereiche" hätte es nur die jeweils sechs rot eingezeichneten Verbindungen zwischen den Cache Slices und nicht mehr. Die jeweils gruppierten Cores bilden quasi eine etwas separierte Einheit. Das wäre auch die Knacknuss am ganzen. Das Konstrukt würde den Verbindungsaufwand bei steigender Kernzahl nicht explodieren lassen (Stichwort Skalierung). Ob diese Lösung aber irgendwie sinnvoll umsetzbar ist bezüglich Core-zu-Core Latenzen ist die grosse Frage. Technisch sicher machbar, aber entstehen (zu grosse) Performance Nachteile?

https://abload.de/thumb/zen_architecturesceki2.jpg (http://abload.de/image.php?img=zen_architecturesceki2.jpg)

Das ZIP-File enthält ein PDF, bei welchem man ein wenig mehr sieht als ein wenig Pixelbrei ;)

robbitop

2019-01-31, 07:59:09

IMO sieht es in deiner Grafik so aus als wäre in einem Zen 2 chiplet ein 8C CCX verbaut. War das die Intension?
Wären es hingegen 2 ccx (was wahrscheinlicher istl) müsste ein if link eingezeichnet sein und der low latency bereich würde nicht über das ccx hinausgehen.

basix

2019-01-31, 08:24:31

Ich weiss nicht, ob man es als 8C CCX verstehen könnte. Eher ein "Quasi-8C-CCX". Die Idee geht schon in die Richtung. Die vier 2C-Blöcke wären eben ein wenig weiter weiter weg von den andern Cores im selben Chiplet. Nicht viel aber mehr als bei Zen 1. Zudem wären nicht alle L3$ Slices direkt miteinander verbunden. Bei einem 8C CCX nach Zen 1 Art würde man irgendwo 30 Verbindungen zwischen den Slices benötigen. Bei noch mehr Cores würde es noch schlimmer. Bei meinem Ansatz wäre das Problem nicht vorhanden. Ist einfach ein anderer Skalieruns-Ansatz als einfach jeweils eim zusätzliches CCX zu verbauen und würde das Problem umgehen, dass man bei steigender Core-Anzahl immer mehr Low-Latency Inseln hat. Und es würde einige Last und Komplexität vom IF reduzieren, evtl. vorteilhaft bezüglich Stromverbrauch.

robbitop

2019-01-31, 09:12:11

Das Latenzdiagramm zeigt mE keinen Hinweis dafür.

Lehdro

2019-01-31, 11:13:07

Neuer Userbench: (https://www.userbenchmark.com/UserRun/14273098)

Der_Korken

2019-01-31, 13:31:18

Neuer Userbench: (https://www.userbenchmark.com/UserRun/14273098)

Sieht komisch aus. Bei 8 und 16MB sind die Latenzen deutlich höher als vorher. Und bei 32MB ist der Peak genauso hoch wie vorher, nur dass alles danach dann nicht mehr schneller wird (wie beim ersten Bench). Singlecore-Leistung der CPU ist deutlich geringer, Quadcore im Schnitt leicht langsamer, Multicore im Schnitt leicht bis deutlich schneller. Vielleicht spielen die mit verschiedenen (Beta-)Microcode-Versionen rum.

Lehdro

2019-01-31, 13:47:51

Sieht komisch aus. Bei 8 und 16MB sind die Latenzen deutlich höher als vorher. Und bei 32MB ist der Peak genauso hoch wie vorher, nur dass alles danach dann nicht mehr schneller wird (wie beim ersten Bench). Singlecore-Leistung der CPU ist deutlich geringer, Quadcore im Schnitt leicht langsamer, Multicore im Schnitt leicht bis deutlich schneller. Vielleicht spielen die mit verschiedenen (Beta-)Microcode-Versionen rum.
Takt ist deutlich niedriger (-10%), was auch Auswirkungen auf die Latenz hat.

Der_Korken

2019-01-31, 13:53:16

SKYNET

2019-01-31, 14:02:22

Es sind nur 7% weniger Takt. Damit kann man bestenfalls die höhere Latenz bei >32MB erklären.

Der Rest verhält sich systematisch anders: Der SC-Score sinkt um knapp 15%. Komischerweise sind dann MC-Float und MC-Mixed gleichauf, MC-Int auf dem kleineren Takt knapp 20% schneller. Und der L3-Cache verhält sich so, als wäre er halbiert.

evtl. isses einfach ne andere CPU... :upara:

werden sicherlich auch welche dabei sein, wo ein teil des cache defekt ist, die will man dann trotzdem verkaufen... :)

basix

2019-01-31, 14:19:47

Das Latenzdiagramm zeigt mE keinen Hinweis dafür.

Richtig, deshalb ist das auch das stärkste Gegenargument und es deutet auf ein 4C CCX hin. Aber wenn ich mir überlege, wie falsch z.B. AIDA bei Zen Release die Latenzen ausgemessen hat, bin ich mir nicht ganz sicher, ob auf die Daten 100%iger Verlass ist, wenn sich die Architektur ändert.

Aber wir werden sehen. Als Enduser ist vordergründig das Resultat entscheidend. Ob das jetzt mit 4C CCX erreicht wird oder nicht, spielt ja keine Rolle. Steht nur im Raum, welcher Ansatz auch in Zukunft das höchste Potential bietet für eine weitere Skalierung der Architektur.

HOT

2019-01-31, 14:34:44

Das ist kein Zen2, sondern ein Zen1 mit Standard-2133-RAM.

SKYNET

2019-01-31, 14:47:43

Das ist kein Zen2, sondern ein Zen1 mit Standard-2133-RAM.

nö, dann würde die CPU erkannt werden...

habe ja auch nen ES im notebook, wird als normaler 3840QM erkannt ;) einziger hinweis das es ein ES ist, ist in CPU-Z zu finden :)

mboeller

2019-01-31, 15:37:22

nö, dann würde die CPU erkannt werden...

habe ja auch nen ES im notebook, wird als normaler 3840QM erkannt ;) einziger hinweis das es ein ES ist, ist in CPU-Z zu finden :)

der Kurvenverlauf sieht aber genauso aus, wie die beim 2700X hier:

https://twitter.com/mustmann/status/1089238684480782336?s=19

Nur die Werte sind ein wenig anders.

HOT

2019-01-31, 15:44:36

nö, dann würde die CPU erkannt werden...

habe ja auch nen ES im notebook, wird als normaler 3840QM erkannt ;) einziger hinweis das es ein ES ist, ist in CPU-Z zu finden :)
Vielleicht ist es ein altes ES oder so, es ist aber ein Zen1, punkt.

SKYNET

2019-01-31, 15:46:14

Vielleicht ist es ein altes ES oder so, es ist aber ein Zen1, punkt.

mit 12 kernen und 24 threads... :upara:

unl34shed

2019-01-31, 15:46:46

Aber für Zen2 hat er Zuwenig L3 oder?

SKYNET

2019-01-31, 15:53:16

Aber für Zen2 hat er Zuwenig L3 oder?

evtl. isses einfach ne andere CPU... :upara:

werden sicherlich auch welche dabei sein, wo ein teil des cache defekt ist, die will man dann trotzdem verkaufen... :)

:wink:

Setsul

2019-01-31, 17:17:21

@basix:
Nein, es funktioniert so einfach nicht.
1. Selbst wenn man die Slices zusammenfasst, muss man immernoch alle L2s untereinander verbinden. Außer das L2/L3 Design ist völlig anders.
2. Entweder wäre es ein 8 Slice L3 oder es ginge über IF, dann wäre die Latenz komplett im Eimer (was man beim ES gesehen hätten) oder AMD hätte etwas völlig neues für diese Verbindung entwickeln müssen.
3. Selbst IF bräuchte niemals so viel Platz und man schießt sich damit nur selbst ins Knie wenn man die Kerne in die Ecken verschiebt also die größtmöglichen Entfernungen erzeugt.
4. Es gibt absolut keinen Grund wieso von den 10 hellen Flächen auf dem Package 8 Kerne sein sollen aber 2 nicht. Wenn man den Mann im Mond sehen will, wird alles unpassende ausgeblendet, aber dadurch wird er nicht real.

Also es ist weder technisch machbar ohne extrem hohen Aufwand und/oder extrem hohe Nachteile, sodass es niemals so implementiert werden würde und es gibt bis jetzt keinerlei Hinweise, dass es so kommt (ansonsten möchte ich hiermit verkünden, dass die 10 hellen Flächen ein Beweis für 10 Kerne sind und genauso ernst genommen werden) und dafür hat bis jetzt jeder Hinweis darauf hingedeutet, dass es bei 4 Kernen pro CCX bleibt.

Bezüglich IF zwischen den Nachbar-Dies bei Rome: Darauf hatte ich auch schon spekuliert, einfach damit das Ganze sich wieder in 4 NUMA-Nodes aufteilen lässt. Jetzt mit 4x4 Kernen statt 2x4 und auf 2 Dies, aber bei der kleinen Entfernung dürfte die Latenz zwischen den CCX fast gleich sein egal ob selber oder Nachbar-Die, trotz IFOP vs on-Die. Die Latenz von Verbindungen die über 2 IFOPs durch den I/O-Die muss wird definitiv deutlich höher sein, also ergibt sich eine klare Aufteiling in 4 Nodes selbst wenn der Sprung zum Nachbar-Die 30% länger dauert.

basix

2019-01-31, 17:51:41

Danke für die Erläuterungen, das mit dem L2 macht es deutlich komplizierter. Das mit den Ecken ist natürlich klar und dass es nicht über den IF läuft ebenso. Nur wie willst du den Floorplan anders legen? Die Kerne werden sowieso praktisch überall am Rand anstossen, wenn man den L3$ wie gehabt zwischen den Kernen haben will. Zudem ist die Distanz zwischen den Kernen deutlich kleiner als z.B. bei einem HSW-E. Dort nehmen die 8 Kerne + L3$ etwa 200mm2 ein. Wäre also der eine Millimeter Abstand dazwischen so extrem matchentscheidend? Das es nicht optimal ist, ist klar. Es geht mir mehr ums Verständnis, von welchen Grössenordnungen von Nachteilen wir hier sprechen. Dass 4C CCX immer noch mit Abstand am wahrscheinlichsten sind bestreitet ja niemand (auch ich nicht ;)). Mir kam nur anhand des Bildes von AdoredTV eine etwas andere Idee, wie man das Chiplet aufbauen könnte ;)

amdfanuwe

2019-01-31, 17:55:37

Bezüglich IF zwischen den Nachbar-Dies bei Rome: Darauf hatte ich auch schon spekuliert, einfach damit das Ganze sich wieder in 4 NUMA-Nodes aufteilen lässt.
Was für Daten sollen denn über diese IF laufen? Schließlich haben die Chiplets keinen Memory Controller.

Eldoran

2019-01-31, 19:40:08

Eine interessante Frage dürfte auch sein, was neben den Cores/Cache noch auf dem CPU Chiplet sitzt. Offensichtlich mindestens ein IFOP Link, ich würde aber vermuten, dass auch Teile des Powermanagements dort sitzen.
Wenn wie bei Naples genutzt jeder Core seine eigene lastabhängige Spannung definieren kann, werden die wohl auch dort sitzen müssen, Sensoren etc. detto. Das alles über das IO Chiplet zu erledigen dürfte ineffizient sein - auch weil die Reaktionszeiten deutlich länger sein sollten. Das Crypto Zeug könnte in IO-Chiplet sitzen.

Zossel

2019-01-31, 20:09:58

Das Crypto Zeug könnte in IO-Chiplet sitzen.

Teile der RAM-Verschlüsselung (SEV/SME) könnte im I/O Chip liegen, das braucht Infos aus der MMU.
AESNI liegt ganz tief in der CPU, und das ist auch gut so!!!

Setsul

2019-01-31, 22:19:10

@basix:
Naja möglichst nah zusammen und I/O nach außen wo es sowieso hingehört.
Wenn man so ein 8 Kern CCX baut und dann zwischenrein einen Streifen mit ungefähr einem Kern Breite schiebt hätte man die Latenz eines 10 Kern CCX aber bekommt nur 8 Kerne dafür. Dann natürlich je länglicher das Ding wird desto schlechter. Quadrat ist optimal, wenn man von 4x2 nochmal streckt auf 5x2 wirds schlechter. Eher steckt man die Logik in die Mitte und machts dadurch breiter (4x3 grob gesagt). So ähnlich kommt auch das Layout bei Zen1 zustande.
https://images.anandtech.com/doci/10591/HC28.AMD.Mike%20Clark.final-page-014.jpg
Abstand von L3CTL zu L3CTL ist ungefähr konstant. Es steckt natürlich noch mehr dahinter aber das ist so ungefähr die Überlegung.

@amdfanuwe:
Ich hab gehört, dass die Chiplets Caches haben und manche Threads machen völlig absurde Sachen und wagen es zu schreiben. Wenn ein Thread in einem anderen Chiplet an die Daten ran will kommen die nicht vom IMC.
Mal ernsthaft wenn jede Kommunikation zwischen Threads über Memory gehen würde wäre das schon extrem langsam. Das ist bei Zen1 auch nicht anders wenn ein Programm in mehr als einem CCX läuft.

amdfanuwe

2019-02-01, 01:05:14

Mal ernsthaft wenn jede Kommunikation zwischen Threads über Memory gehen würde wäre das schon extrem langsam. Das ist bei Zen1 auch nicht anders wenn ein Programm in mehr als einem CCX läuft.
Mal ernsthaft, du hast keine Ahnung, was da überhaupt abläuft.
Programme arbeiten auf Hauptspeicher, Threads kommunizieren über queues und pipes oder durch semaphoren geschützte Bereiche etc.. Wenn die Hardware den Datenverkehr durch Caches beschleunigt, schön. Die Software hat darauf keinen Einfluß. Die Firmware bzw. der OS Kernel hat noch Einfluß auf die Caches.
Die Kommunikation über die IF zwischen den Kernen bzw. dem I/O dient hauptsächlich der Cache Kohärenz. War früher noch einfach, als alle Kerne an einem Bus hingen und die Caches mitlauschen "snooping" konnten und bei Bedarf ihren Cache angepasst haben.
Bei größeren verteilten Systemen wirds dann schon komplizierter, da muß per Broadcast im ganzen System jedem Cache mitgeteilt werden, auf welche Adresse zugegriffen wird, damit die anderen Caches konsistent gehalten werden. Erzeugt natürlich einen ordentlichen Datenverkehr zwischen den Caches und über die IF Links zwischen den einzelnen CCX.
Ab einer bestimmten Kern Anzahl lohnt es sich eher, Verzeichnisbasierte Cache strategien zu benutzen.
Ich nehme an, dass AMD solches auf den I/O implementiert hat.
Kommt eine Änderungsmeldung eines Caches, schaut der I/O in seinem Verzeichnis nach, welche anderen Caches im System davon betroffen sind und schickt denen selektiv die Änderungsmeldung. Senkt den Datenverkehr auf den IF enorm, da nicht mehr Broadcastmäßig die Änderungsnachricht an alle geschickt wird.

Daher macht es dann auch keinen Sinn ein IF zwischen 2 Chiplets zu legen.

Hier noch etwas an Grundlagen:
https://eldorado.tu-dortmund.de/bitstream/2003/34097/1/Dissertation.pdf
Schau mal ab S. 15, "2.3 Konsistenz und Kohärenz in Mehrkern-Prozessoren", rein

Setsul

2019-02-01, 13:40:47

Programme arbeiten auf Hauptspeicher, Threads kommunizieren über queues und pipes oder durch semaphoren geschützte Bereiche etc.. Wenn die Hardware den Datenverkehr durch Caches beschleunigt, schön. Die Software hat darauf keinen Einfluß. Die Firmware bzw. der OS Kernel hat noch Einfluß auf die Caches.

Was soll denn das für ein Argument sein? Natürlich sind Caches transparent für Software, das ist der Sinn der Sache. Ändert nichts daran dass eine modified Cache Line nicht vom RAM gelesen wird.

Die Kommunikation über die IF zwischen den Kernen bzw. dem I/O dient hauptsächlich der Cache Kohärenz.
Das hast du gut erkannt. Chiplet B möchte eine Cache Line die auf Chiplet A modifiziert wurde. Darüber reden wir gerade.

Ich nehme an, dass AMD solches auf den I/O implementiert hat.
Kommt eine Änderungsmeldung eines Caches, schaut der I/O in seinem Verzeichnis nach, welche anderen Caches im System davon betroffen sind und schickt denen selektiv die Änderungsmeldung. Senkt den Datenverkehr auf den IF enorm, da nicht mehr Broadcastmäßig die Änderungsnachricht an alle geschickt wird.

Daher macht es dann auch keinen Sinn ein IF zwischen 2 Chiplets zu legen
Das ist schön, dass du schon weißt wie AMD alles implementiert hat.
Aber "AMD hat das so implementiert weil ich vermute dass AMD das so implementiert hat" ist leider ein sehr schlechtes Argument.
Wie gesagt schau dir Zen1 an. Das läuft offensichtlich anders.

Es gibt verdammt viele Möglichkeiten und die absolut naivste Implementierung bei der jede Änderung 2 mal durchs IFOP muss nur um zum zweiten CCX auf dem selben Die zu kommen wird es wahrscheinlich nicht sein.

Hier noch etwas an Grundlagen:
https://eldorado.tu-dortmund.de/bitstream/2003/34097/1/Dissertation.pdf
Schau mal ab S. 15, "2.3 Konsistenz und Kohärenz in Mehrkern-Prozessoren", rein
Hard real time ist eine ganz andere Baustelle, keine Ahnung wie du auf dieses Paper kommst.

amdfanuwe

2019-02-01, 14:51:56

Was soll denn das für ein Argument sein? Natürlich sind Caches transparent für Software, das ist der Sinn der Sache. Ändert nichts daran dass eine modified Cache Line nicht vom RAM gelesen wird.
Oh, dann hab ich das wohl falsch verstanden:
Ich hab gehört, dass die Chiplets Caches haben und manche Threads machen völlig absurde Sachen und wagen es zu schreiben. Wenn ein Thread in einem anderen Chiplet an die Daten ran will kommen die nicht vom IMC.

Das hast du gut erkannt. Chiplet B möchte eine Cache Line die auf Chiplet A modifiziert wurde. Darüber reden wir gerade.

Schön, und wie soll das funktionieren? Chiplet A Broadcast an alle: Ich weiß, dass einer die Daten im Cache hat, schick mir bitte die Cacheline XY?
Schließlich weiß der Cache nur, ob eine Cacheline shared, modified etc. ist, aber doch nicht, wo im Sytem in welchem Cache die nun gültigen Daten stecken.
Das kann nur ein Verzeichnisbasierte System leisten und dann entscheiden ob es schneller ist die Daten aus dem RAM oder einem anderem Cache zu lesen.

Das ist schön, dass du schon weißt wie AMD alles implementiert hat.
Aber "AMD hat das so implementiert weil ich vermute dass AMD das so implementiert hat" ist leider ein sehr schlechtes Argument.

Tja, ich weiß es nicht, ich vermute es. Welchen Wissensstand hast du?

Wie gesagt schau dir Zen1 an. Das läuft offensichtlich anders.

Eben, Schau es dir an und überleg mal, was man da besser machen könnte anstatt dauernd einen Broadcast an alle Caches zu schicken.
Gib mal eine Alternative, wie es AMD implementiert haben könnte. Dann haben wir eine Diskussionsgrundlage und können das für und wieder abklopfen.
Einfach ein paar IF zwischen zwei Chiplets einzuzeichnen macht doch keinen Sinn ohne entsprechendes Konzept.

Es gibt verdammt viele Möglichkeiten und die absolut naivste Implementierung bei der jede Änderung 2 mal durchs IFOP muss nur um zum zweiten CCX auf dem selben Die zu kommen wird es wahrscheinlich nicht sein.

Ich kann mir aber vorstellen, dass innerherhalb eines Chiplets die Caches konsistent gehalten werden. Liegen ja am selben Bus (IF) und da reichte ein snooping.
Es muß aber dem restlichem System auch mitgeteilt werden, wenn sich eine Cacheline ändert. Also, Broadcast oder Verzeichnisorientiert?
Schließlich braucht jede Übertragung Energie. Durch ein Verzeichnis basiertes System kann da viel gespart werden.

Hard real time ist eine ganz andere Baustelle, keine Ahnung wie du auf dieses Paper kommst.
Einfach mal nach Cahe Kohärenz gegoogelt. Fand das Kapitel über Cache Kohärenz anschaulich. Wenn du gute Links zum Cache Kohärenz Thema hast, immer her damit. Ist nicht leicht etwas zu finden, was das Thema anschaulich beleuchtet. Wäre natürlich noch besser, wenn du etwas zum IF Protokoll hast.

Complicated

2019-02-01, 16:21:19

Einfach mal nach Cahe Kohärenz gegoogelt. Fand das Kapitel über Cache Kohärenz anschaulich. Wenn du gute Links zum Cache Kohärenz Thema hast, immer her damit. Ist nicht leicht etwas zu finden, was das Thema anschaulich beleuchtet. Wäre natürlich noch besser, wenn du etwas zum IF Protokoll hast.
Hier ist Dresdenboys Preview zu Zen hilfreich
https://www.planet3dnow.de/cms/26077-details-und-analyse-der-zen-architektur-nach-der-hot-chips-konferenz/4/
Dazu die Erläuterung in Wikipedia zu MOESI
Ergeben einen guten Überblick zu Zen1 als Ausgangsbasis.
https://de.m.wikipedia.org/wiki/MOESI

Setsul

2019-02-01, 16:49:32

Tja, ich weiß es nicht, ich vermute es. Welchen Wissensstand hast du?

Deshalb habe ich ja geschrieben "Darauf hatte ich auch schon spekuliert" und nicht "alles andere ergibt keinen Sinn". Kann sein dass AMD es macht, kann aber auch sein dass alles über den I/O Die laufen muss.

Schön, und wie soll das funktionieren? Chiplet A Broadcast an alle: Ich weiß, dass einer die Daten im Cache hat, schick mir bitte die Cacheline XY?
Schließlich weiß der Cache nur, ob eine Cacheline shared, modified etc. ist, aber doch nicht, wo im Sytem in welchem Cache die nun gültigen Daten stecken.
Das kann nur ein Verzeichnisbasierte System leisten und dann entscheiden ob es schneller ist die Daten aus dem RAM oder einem anderem Cache zu lesen.

Bei mir hatte A die Daten und B wollte sie, nur dass hier keine Missverständnisse aufkommen.
Wenn B die Cache Line schon hatte, als Shared, dann könnte er sehr wohl wissen welcher Node die Line als Owned hatte, denn bevor A auf Owned ist kann A auch nicht schreiben. Also das kann man durchaus vermerken. A ist außerdem eigentlich verpflichtet zu broadcasten dass er geschrieben hat und alle anderen Kopien Invalid sind. Es sollte klar sein wieso eine direkte Verbindung da hilfreich sein kann. Der I/O-Die sollte natürlich trotzdem einen Snoop Filter haben bzw. idealerweise generell alle Tags und den Broadcast nur dorthin schicken wo er auch hin muss.

Dann der andere Fall, B hat die Line noch gar nicht. Wir reden immer noch von einer Modified Line, da hat auch ein verzeichnisbasiertes System nicht zu entscheiden ob es schneller ist aus dem RAM zu laden, weil die Daten im RAM veraltet sind. Das kann man nicht einfach ignorieren bloß weil der RAM direkt am I/O-Die hängt und man sich den zusätzlichen Weg 2 mal übers IFOP sparen will. Generell muss man entweder alle Lines kennen (directory), wenn die Line nur Owned/Exclusive/Shared ist kann man sie aus beliebiger Quelle holen, oder man snooped. Je nach Protokoll ist sowieso festgelegt dass ein bestimmter State (Exclusive/Owned/Forward) automatisch auf die Snoop-Request antwortet und alle anderen Caches sie ignorieren.

Bei der Topologie von Rome ist es offensichtlich nicht optimal wenn alle Snoop-Requests erstmal 3 Hops hinter sich bringen müssen bevor der I/O-Die weiß ob er jetzt vom RAM laden muss oder nicht. Also einige wenn nicht alle Tags sollten auch auf dem I/O-Die sein damit man schon nach einem Hop weiß ob man den RAM braucht. Aber das heißt nicht, dass man nicht optimieren kann was innerhalb eines Dies oder eben innerhalb von 2 Dies passiert.

Ich kann mir aber vorstellen, dass innerherhalb eines Chiplets die Caches konsistent gehalten werden. Liegen ja am selben Bus (IF) und da reichte ein snooping.
Es muß aber dem restlichem System auch mitgeteilt werden, wenn sich eine Cacheline ändert. Also, Broadcast oder Verzeichnisorientiert?
Schließlich braucht jede Übertragung Energie. Durch ein Verzeichnis basiertes System kann da viel gespart werden.
Also IF ist kein Bus, nur dass das klar ist.
https://images.anandtech.com/doci/13243/1534792269677709153101.jpg

Bei Zen1 gibts eine logische Zuordnung von Cache Lines zu dem Die auf dem der IMC liegt zu dem die Adresse gehört. Außerdem hat jeder Die zu jedem eine Verbindung, man kann also mit relativ niedriger Latenz snoopen. Bei Shared Lines kann man auch noch den Snoop Filter auf dem Die fragen ob der andere L3 die Line hat. Ich müsste suchen aber ich glaube da sind keine großen Optimierungen drin weil jeder Die ja seine eigene Verbindung zu jedem anderen hat und was soll er sonst mit der Bandbreite machen? Also einfach Broadcast und dann bleibts im Snoop Filter hängen (ob auf dem eigenen oder den anderen Dies weiß ich nicht) und stört die L2s/L3s nicht. Nicht gerade sparsam aber IF an sich ist nicht sehr sparsam, es funktioniert und hat die niedrigste Latenz.
Geht bei Rome natürlich auch und der I/O-Die muss nicht einmal unnötige Requests verschicken wenn er alle Tags sammelt, aber die Latenz ist höher.
Bei Chiplets auf gegenüberliegenden Seiten des I/O-Dies würde sich die Latenz kaum ändern selbst wenn man den I/O-Die überspringen könnte, einfach wegen der physischen Entfernung, aber zwei benachbarte Chiplets könnte man verbinden und diese niedrigere Latenz nutzen.
Ob man dann einfach auf gut Glück Snoop-Requests an den I/O-Die und das andere Chiplet schickt und der I/O-Die macht einfach nichts wenn er merkt dass das andere Chiplet die Anfrage bearbeiten kann/muss oder ob man einen Source Filter davorklemmt und nur dann an das andere Chiplet schickt wenn es die Line auch hat und dafür nichts an den I/O-Die, das sind dann Details.
Selbst wenn man immer an beide schickt ist das immernoch weniger als wie bei Zen1 an 3 bzw. 4 (bei 2P) zu schicken und im Fall dass das andere Chiplet antwortet spart man sich ja auch den Umweg über den I/O-Die, also sind die Gesamtkosten selbst bei der doppelten Anzahl Chiplets nicht wirklich höher als bei Zen1.
Das wäre es mir schon wert für die niedrigere Latenz.
Man darf auch nicht vergessen, dass ohne das oder etwas ähnliches alle Chiplets 2 Hops voneinander entfernt sind. Also alles was mehr als 8 Kerne benutzt würde dann so laufen als wäre es bei Zen1 auf zwei Sockel verteilt.

basix

2019-02-01, 17:47:51

@ Setsul: Danke für die sachliche Darlegung und Diskussion der Dinge :up:

Was ich schön and Zen 2 finde: Es gibt viele wahnsinnig interessante Dinge zu spekulieren und bei Release zu analysieren :) Und dass er natürlich so performt wie Schmitz-Katze :D

amdfanuwe

2019-02-01, 19:18:28

@Complicated
Danke für die Links

Rincewind

2019-02-01, 19:33:07

@Setsul: Danke für Deine Ausführung: Ich habe zwar nicht alles verstanden, aber ich habe mal ne kurze Frage: Die Kerne kommunizieren ja miteinander, wie viel Zeit geht eigentlich (in Prozent?!) dabei drauf, zu kommunizieren / Daten abzugreifen und weiterzuverarbeiten.

Ich weiß, das liest sich ungenau, aber ich hoffe ihr wisst meine "naive" Frage richtig zu interpretieren.
Stichpunkt: Verwaltungsaufgaben :)

Zossel

2019-02-01, 20:56:45

@Setsul: Danke für Deine Ausführung: Ich habe zwar nicht alles verstanden, aber ich habe mal ne kurze Frage: Die Kerne kommunizieren ja miteinander, wie viel Zeit geht eigentlich (in Prozent?!) dabei drauf, zu kommunizieren / Daten abzugreifen und weiterzuverarbeiten.

https://www.reddit.com/r/orlybooks/comments/50meb5/it_depends/

Setsul

2019-02-01, 22:30:26

@Rincewind:
Siehe Zossel.

Aber mal ehrlich das ist so wie ein Miss in allen Caches und dann das warten auf den RAM. Oder Pointer Chasing.
Im Idealfall passiert es nie, aber wenn dann kostet es sehr viel Zeit. Also versucht man die Latenz zu minimieren. RAM ist so ungefähr 300 Takte und wenn man die Latenz zwischen Sockeln bei Zen1 sich anschaut dann wäre der worst case bei Rome von einem Chiplet zum anderen gut das doppelte. Wenn man von 4 Instructions pro Takt ausgeht dann heißt das einmal "kommunizieren" wenn man darauf warten muss alle ~2500 Instructions würde genauso viel Zeit brauchen wie die 2500 Instructions also das Programm um 50% verlangsamen. Wenn das nur 2 Threads sind war also alles umsonst.

Durch out of order execution bzw. Locks, Semaphore und alle möglichen anderen lustigen Sachen wird das natürlich noch komplizierter aber bleib dem Vergleich zum RAM. Manche Programme interessieren sich dafür überhaupt nicht weil sie einfach nur die ALUs/SIMD-Units zum glühen bringen aber so wie bei manchen Spielen 10% niedrigere RAM-Latenz 8% mehr fps bringt ist. Genauso ist für manche eben die Latenz zwischen den Kernen sehr wichtig und jenseits von 4 Kernen hat AMD da momentan deutliche Schwächen. Zen1 hat innerhalb des Sockels Latenzen wie Intel zwischen den Sockeln. Wenn Rome innerhalb des Sockels Latenzen hat wie Zen1 zwischen den Sockeln dann wäre das schon sehr übel. Wie gesagt manche Programme wirds nicht interessieren und bei manchen wird die doppelte Latenz dafür sorgen dass sie dann mit mehr Threads langsamer werden.

Lehdro

2019-02-01, 23:09:40

Zen1 hat innerhalb des Sockels Latenzen wie Intel zwischen den Sockeln.
https://www.pcper.com/files/review/2017-08-09/latency-pingtimes.png
Ist aber mit DDR4 2400. Weiß einer wie das mit RAM Takt skaliert? DRAM Latency skaliert ja ganz ok mit Takt/Timings, aber wie sieht es innerhalb der CPU aus? Skaliert IF da auch sauber durch mit höherem RAM Takt? Zen 2 soll ja gerüchteweise mit 3200 antreten.

Setsul

2019-02-01, 23:39:44

https://www.servethehome.com/amd-epyc-infinity-fabric-latency-ddr4-2400-v-2666-a-snapshot/
Vergleich mit Xeon ist ganz unten.

Also skaliert schon aber wenn Rome eben die Inter-Socket-Latenz jetzt innerhalb des Sockels hätte, dann bringt das auch nichts. Nur um auf die alte AMD Intra-Socket-Latenz bzw. Intel Inter-Socket-Latenz zu kommen müsste man die Frequenz aufs doppelte hochprügeln und EPYC mit 4800 RAM wirds nicht geben.

Wenn es bleibt wie es war ist es ja nicht schlecht. Intel mit besserer Latenz bis 28 Kerne aber dann bis 56 gleichauf weils 2 Dies sind und dann über 64 wieder Vorteil Intel wenn sich an der Inter-Socket Latenz nichts ändert. Aber wenn AMD ab 9 Kernen mit der doppelten Latenz rumhampelt die Intel zwischen Sockeln hat dann ist wenig zu holen.

Lehdro

2019-02-02, 00:32:41

Bin gespannt was AMD denn da am Ende zusammengezimmert hat, denn man geht schon davon aus dass Latenz ein großer Arbeitspunkt für Zen 2 war. IF soll ja in die nächste Generation gehen.

Platos

2019-02-02, 02:35:37

Mit was für einem Perfomancesprung kann man eigentlich von TSMCs 12nm zu Samsungs 7nm EUV erwarten ? Ist Samsungs 7nm EUV vergleichbar mit TSMC 7nm EUV (also 7nm+)?

Da nvidia so ein schlechtes Quartal hatte, glaube ich kaum, dass sie nochmals solche Preise ansetzten werden und da sie bestimmt ordentlich RT pushen wollen (was Fläche braucht), aber trotzdem nicht wieder so riesen DIEs wie die von Turing bringen wollen/werden, glaube ich eigentlich kaum an eine signifikante Erhöhung der 'normalen' Leistung.

robbitop

2019-02-02, 07:43:58

Das geleakte Latenzdiagramm sieht nicht so aus als wären Latenzen sonderlich schneller oder langsamer geworden. Memoryzugriff läuft ja auch über die IF (zum imc). Ca 10 ns langsamer wegen dem zusätzlichen IO die. Andererseits war das Ding noch niedrig getaktet und der RAM auch (wenn der mit „1,3 ghz“ nicht gar eine Fehlauslesung war). Wenn es so bleibt, aber der RAM Takt out of the box bei Zen 2 Produkten höher ist, bleiben Latenzen ggf unterm Strich gleich (oder sogar besser wenn finale Taktraten noch etwas verbessern können). Das dürfte dann doch auch für die Interchiplet Latenz gelten.
CCX zu CCX ggf durch höheren Praxistakt (out of the box) etwas schneller.

Man sollte seine Erwartungen managen. AMD kann auch nicht zaubern. Der Chipletvorteil hat nunmal prinzipbedingt auch Nachteile (Latenz und sicherlich erhöhter Energiebedarf für die Kommunikation). Ggf war die IF in der ersten Iteration aber noch so unoptimiert, dass der Fortschritt (sofern er passiert ist) hoffentlich die Nachteile aus dem Chipletansatz kompensiert und am Ende in der Hauptsache die Vorteile (ggü Zen1) unterm Strich stehen bleiben.

Mit was für einem Perfomancesprung kann man eigentlich von TSMCs 12nm zu Samsungs 7nm EUV erwarten ? Ist Samsungs 7nm EUV vergleichbar mit TSMC 7nm EUV (also 7nm+)?

Da nvidia so ein schlechtes Quartal hatte, glaube ich kaum, dass sie nochmals solche Preise ansetzten werden und da sie bestimmt ordentlich RT pushen wollen (was Fläche braucht), aber trotzdem nicht wieder so riesen DIEs wie die von Turing bringen wollen/werden, glaube ich eigentlich kaum an eine signifikante Erhöhung der 'normalen' Leistung.

Sollte grob vergleichbar sein. Gerade Dichte und Leistungsaufnahme sind ja hier ein enormer Sprung.
Ich gehe davon aus, dass NVs 7nm Generation wieder Pascals Chipgrößen (106/104/102) umsetzt. Die großen Chipgrößen waren bei Turing nur nötig, weil es nur 12 nm gab und man mehr Leistung und RT gleichzeitig haben wollte. Ohne echten Shrink.

Der HP Prozess sklaiert, wenn man sich die sram Größen anschaut, auf rund 45% der Chipgröße. TU102 wäre entsprechend rund 330 mmw groß. GP102 war mit 471 mm2 noch relativ handelbar. Wenn man das anstreben würde, mArch nicht schneller wird und Taktraten gleich bleiben, kann man also rund 40...45% mehr Transistoren und entsprechend mehr Performance erwarten.
Powerreduction fängt die Mehrtransistoren mehr als aauf. Ggf kann man also auch etwas höher takten.

Allerdings muss man dann die rund 50% höhere Leistung auch mit Bandbreite füttern.
TU102 hat 45,9 gb/tflop. Das ist extremst großzügig. Und das obwohl die dcc nochmal besser geworden ist ggü Pascal.

Extreme bei Pascal:
1070 ti: 31,3 gb/tflop x s
1060 9gbps: 49,4 tflops x s

16 gbps Module würden bei 384 bit für einen ga102 (s.o) rund 37 gb/tflop x s bedeuten.
Bei 512 bit sogar 49 gb/ tflop x s

Für klassische Spiele würde ersteres reichen. Aber es muss ja einen Grund geben, warum Turing so viel Bandbreite bekommen hat. Ist Raytracing ggf banbbreitenintensiver?

512 bit hätte den Vorteil, dass man nicht gleich auf 24 gb vram hoch müsste sondern nur auf 16 gb.

Das ist aber ziemlich OT und sollte im entsprechenden Thread weiter diskutiert werden.

Platos

2019-02-02, 16:31:37

Der Post sollte eigentlich in den anderen Thread gehen ^^

Aber danke für die Auskunft.

basix

2019-02-02, 19:07:08

Für klassische Spiele würde ersteres reichen. Aber es muss ja einen Grund geben, warum Turing so viel Bandbreite bekommen hat. Ist Raytracing ggf banbbreitenintensiver?

Tensor Cores / AI Workloads hängen vielfach an der Bandbreite. Sieh dier mal den TPU 3.0 von Google an: 2.4 TB/s pro 4-Chip Cluster. Werden also TC für das Denoising steigt sicherlich der Bandbreitenbedarf. Wie das bei Raytracing generell aussieht weiss ich aber nicht.

Thunder99

2019-02-03, 12:23:59

Nightspider

2019-02-03, 12:27:41

Du meinst 4 und 6 Kerner mit noch höheren Taktraten?

Naja, bei 14nm von Glofo gab es zumindest die Clockwall und auch bei wenigeren Cores ist man außerhalb des Sweetspots, da macht die Anzahl der Kerne keinen Unterschied.

Cool wäre natürlich ein monolithischer 6 Kerner mit fettem eDRAM und/oder größeren Caches, so das alles auf höhere ProKern Leistung ausgelegt ist aber das lohnt sich nicht. Das wäre ein Nischenmarkt.

basix

2019-02-03, 13:01:43

Das mit den wenigen Cores kannst du eigentlich vergessen. Die zwei SC-Performance Metriken sind praktisch ausgeschöpft. Da kann man sich zwar noch einen Vorteil verschaffen aber halt nur einen geringen.

4-5 GHz sind bei den heutigen Designs das Maximum. Das ist schon weit überhalb des Effizienz-Sweetspots von vielleicht 2.5-3.0 GHz. Da momentan alles verbrauchslimitiert ist, ist eine starke weitere Erhöhung der Frequenz eher unwahrscheinlich da die Effizienz den Bach runter geht. Ausnahme man findet den heiligen Gral der Fertigungstechnologie oder Architektur.
Generelle IPC-Steigerungen sind auch nicht mehr so gross möglich, vielleicht nochmals jeweils 10-15% pro Generation. In Spezialfällen wie z.B. AES usw. baut man deswegen ja schon lange Extensions ein. Oder man findet auch hier den heiligen Gral.

Will man die SC-Performance drastisch steigern, müsste man sich vermutlich nach einem komplett neuen Konzept oder sogar einer anderen Architektur als x86 umsehen. Eine Idee wäre, mehrere Kerne am selben Thread rechnen zu lassen. Da man aber wenn man genau hinschaut schon innerhalb eines einzelnen Kerns schon ziemlich parallel unterwegs ist (Stichwort ILP), sehe ich das aber als nicht sinnvoll an. Zumindest nicht bei den heutigen CPU-Architekturen. Was man aber machen kann: Die Latenzen senken usw. sodass man eigentlich in allen Anwendungen vor Intel liegt (eDRAM ginge ja, ist aber teuer und sehr Prozess-selektiv). Spiele wären ein Beispiel davon, es gibt aber sicher noch andere. Hat man das erreicht und gleichzeitig mehr Kerne: Vorteil AMD auf breiter Linie. Das ist momentan das "Problem" von AMD. Mit Intel fährt man momentan in gewissen Anwendungsszenarien halt einfach besser. Ist meine Hauptanwendung Spiele und ich kann es mir leisten: Intel ist heute performancemässig vorne (Preis/Leistung ist ein anderes Thema). Kann hier AMD das Verhältnis umdrehen, hat AMD gewonnen. Da reichen auch nur 10%. Mehr Kerne werden sie vorderhand sowieso haben.

reaperrr

2019-02-03, 13:28:20

Ich hoffe, dass das Chiplet Design nicht zum Nachteil wird bei wenigen Cores, siehe auch bei Intel Sylake vs Skylake X.

Der Ansatz auch beim Desktop auf Chiplet zu gehen ist wohl der nach wie vor schlechten wirtschaftlichen Situation geschuldet (begrenztes Budget).
Wieso geht AMD nicht mal die umgekehrte Richtung mit weniger Cores Intel zu schlagen (diese Entwicklung zu forcieren)? Das wäre eine Sensation :D
Bei Skylake X liegen die Probleme
- in der veränderten Cache-Architektur (der angeflanschte L2 ist stromhungrig und m.W. auch nicht so schnell wie die 256KB der normalen SKL, L3 kleiner pro Kern und exklusiv statt inklusiv -> hat seltener die gewünschten Daten parat)
- der Tatsache, dass die Chips monolithisch sind und dadurch die Wahrscheinlichkeit extrem hoch ist, dass wenigstens einer der (aktiven) Kerne schlecht taktet oder viel Strom säuft, weshalb für die Massenproduktion relativ moderate Einstellungen gewählt werden müssen.

AMD's Chiplet-Ansatz ist das exakte Gegenteil. Wir werden mMn bei Zen2 noch stärker als es Threadripper schon angedeutet hat sehen, dass der Chiplet-Ansatz relativ betrachtet viel näher am Optimum liegende Taktraten/Spannungen erlaubt, gerade bei den Top-Modellen, weil sie einfach die besten Chiplets zusammenpacken können, und bei nur 75mm² wird es relativ viele gut taktende, voll funktionsfähige Chiplets geben.

Intel hat mit seinen monolithischen Dies einen massiven Nachteil bei Ausbeute und Binning.

BlacKi

2019-02-03, 13:38:46

werden die Dies schon vor dem aufbringen getestet? ist das überhaupt rentabel möglich?

Skysnake

2019-02-03, 13:48:51

Ja die dies werden insgesamt sogar zigfach getestet. Während der Produktion mit Teststuckturen für alignment etc und dann am Ende vor dem dicing noch als kompletter Chip.

Da wird normal ein Funktional testing gemacht etc. Da gibt es extra verfahren und Maschinen für.

Wenn also nen Chip auf einPackage wandert kann man sich normal sehr sicher sein, dass der auch funktioniert.

Lehdro

2019-02-03, 13:54:30

werden die Dies schon vor dem aufbringen getestet? ist das überhaupt rentabel möglich?
Wie sonst sollte AMD entscheiden ob es ein Epyc, Threadripper oder Ryzen werden soll? Das machen sie doch heute schon...

Zossel

2019-02-03, 14:12:38

Ist meine Hauptanwendung Spiele und ich kann es mir leisten: Intel ist heute performancemässig vorne (Preis/Leistung ist ein anderes Thema). Kann hier AMD das Verhältnis umdrehen, hat AMD gewonnen. Da reichen auch nur 10%. Mehr Kerne werden sie vorderhand sowieso haben.

Ist die Spielestärke von Intel eigentlich nur in praxisfenen Auflösungen < HD vorhanden?

basix

2019-02-03, 14:29:37

Klar, die grössten Unterschiede sind bei niedrigen Auflösungen vorhanden. Aber auch bei 1080p und höher gibt es mit starken Karten zum Teil deutliche Unterschiede (z.B. für die High FPS Gamer). Je nach Spiel auch noch in 4K (z.B. Total War Warhammer, ja ein Einzelbeispiel). Im Schnitt sind CPUs von sicher beiden AMD und Intel voll tauglich für Spiele. Aber es geht gar nicht so extrem darum, wie gross die Unterschiede effektiv sind. Es geht nur darum: Wer ist der schnellste? Bei welcher CPU muss ich mir keine "Sorgen" machen? Diese Frage beeinflusst die Kaufentscheidung vor allem im oberen Preisspektrum. Und da ist ein 9900K im Schnitt nunmal schneller als ein 2700X. Das kann man drehen und wenden wie man will, das ist einfach Fakt.

reaperrr

2019-02-03, 14:30:15

Ist die Spielestärke von Intel eigentlich nur in praxisfenen Auflösungen < HD vorhanden?
Nein, die kommt auch dann zum Tragen, wenn Leute für 120/144Hz hohe FPS erreichen wollen.

Gibt auch vereinzelte Spiele, die mit Zen generell nicht so gut klarkommen und sehr CPU-lastig sind (z.B. Ashes of the Singularity).

Linmoum

2019-02-03, 14:41:10

Ist die Spielestärke von Intel eigentlich nur in praxisfenen Auflösungen < HD vorhanden?
Das ist immer noch auflösungsunabhängig. 65fps für CPU A und 83fps für CPU B in 720p und genau dasselbe gilt dann auch für FHD, WQHD oder UHD. Die CPUs schaffen nicht auf magische Weise mehr fps.

Was auch immer noch der Grund ist, warum (gute) CPU-Tets in niedriger Auflösung durchgeführt werden, damit man eine CPU nicht im GPU-Limit bencht. Zum hundertsten Mal. *seufz*

SKYNET

2019-02-03, 15:17:47

werden die Dies schon vor dem aufbringen getestet? ist das überhaupt rentabel möglich?

wird jetzt schon gemacht, die "schlechten" sind die epyc, die so lala die ryzen, die top cores threadripper.

reaperrr

2019-02-03, 16:46:20

wird jetzt schon gemacht, die "schlechten" sind die epyc, die so lala die ryzen, die top cores threadripper.
Das 14LPP B2 Stepping wird exklusiv für Epyc verwendet, bei Epyc ist also alles dabei (die schlechtesten für die Billigmodelle mit wenig Kernen, die besten für die 32c-Topmodelle).

Die "schlechten" 12LP-B2 werden für OEM-2300X/2500X und 2600 verwendet, wobei "schlecht" bei einem ausgereiften Prozess auch relativ ist.

Setsul

2019-02-03, 17:53:47

Eine Idee wäre, mehrere Kerne am selben Thread rechnen zu lassen.
Das hat Softmachines versucht. Interessanterweise war auch AMD unter den Investoren. Die ersten Prototypen waren dann nicht ganz so gut wie erhofft und Intel hat die Chance genutzt und den ganzen Laden für 250 Mio. gekauft was im Vergleich zu den 220 Mio die ursprünglich investiert wurden schon allein durch die Inflation praktisch der best case ist. Mittlerweile gibt die Website nur noch 403 - Forbidden zurück. Daraus kann man jetzt schließen was man will.

Bei Skylake X liegen die Probleme
- in der veränderten Cache-Architektur (der angeflanschte L2 ist stromhungrig und m.W. auch nicht so schnell wie die 256KB der normalen SKL, L3 kleiner pro Kern und exklusiv statt inklusiv -> hat seltener die gewünschten Daten parat)
- der Tatsache, dass die Chips monolithisch sind und dadurch die Wahrscheinlichkeit extrem hoch ist, dass wenigstens einer der (aktiven) Kerne schlecht taktet oder viel Strom säuft, weshalb für die Massenproduktion relativ moderate Einstellungen gewählt werden müssen.
Die L2 Latenz geht in der Tat von 12 auf 14 Takte hoch.
Exklusiv statt inklusiv ist aber kein Nachteil. Ob 2,5 MiB L3 mit 256 KiB L2 die inklusiv, also doppelt sind, oder 1 MiB L2 + 1,375 MiB L3 die exklusiv sind also insgesamt 2,375 MiB mit deutlich niedriger Latenz von 0,25 bis 1 MiB nimmt sich wenig.
Aber der L3 braucht oft 10-20 Takte länger und das Mesh taktet niedriger als der Ring weil es sonst noch mehr Strom fressen würde. Also jenseits der 1 MiB und besonders zum RAM merkt man es deutlich.
Das ist keine Frage des Binnings, die >4,0 GHz i9s hängen auch bei gleichem Takt in Spielen und ähnlich RAM-Latenz empfindlichen Programmen dem "normalen" SKL/KBL/CFL hinterher.

mboeller

2019-02-03, 18:17:33

Das hat Softmachines versucht. Interessanterweise war auch AMD unter den Investoren. Die ersten Prototypen waren dann nicht ganz so gut wie erhofft und Intel hat die Chance genutzt und den ganzen Laden für 250 Mio. gekauft was im Vergleich zu den 220 Mio die ursprünglich investiert wurden schon allein durch die Inflation praktisch der best case ist. Mittlerweile gibt die Website nur noch 403 - Forbidden zurück. Daraus kann man jetzt schließen was man will.

SWARM fällt, glaube ich auch in diese Kategorie. Ich bin mir aber nicht sicher.

zB.: https://people.csail.mit.edu/mcj/talks/2015.swarm.slides.micro.pdf

basix

2019-02-03, 18:39:27

@Setsul: Ja Softmachines hatte ich im Hinterkopf und auch dass Intel den Laden gekauft hat. Aber schon damals gab es Diskussionen zur Firma, z.B. dass die Darstellung der Mehrperformance recht "speziell" war. Einer der Gründer von Softmachines war übrigens soweit ich mich erinnere ein Ex-Intel Mitarbeiter ;)

Mich lässt noch immer eine Aussage eines AMD Mitarbeiters nicht los: Man soll nicht die Kerne sondern die Threads zählen. Weiss aber nicht mehr wer das war.

BlacKi

2019-02-03, 19:05:13

wird jetzt schon gemacht, die "schlechten" sind die epyc, die so lala die ryzen, die top cores threadripper.
das macht keinen sinn, warum sollte amd das genau so tun?

wenn skysnake sagt, das würde schon gemacht, dann glaub ich ihm das. deshalb habe ich es ja auch als fragestellung formuliert.

robbitop

2019-02-03, 19:35:03

Pirx

2019-02-03, 19:40:27

Wobei die Latenz bei CFL spätestens zum >=9. Kern so gigantisch hoch ist, daß dann dieser als todkrank erscheint.

gravitationsfeld

2019-02-03, 20:02:41

Eldoran

2019-02-03, 20:12:35

TR sind die besten Bins von Ryzen, EPYC nutzt ein anderes Stepping und mittlerweile auch einen anderen Chipfertigung (12nm statt 14nm). Andererseits taktet EPYC auch relativ handzahm - in der Regel zwischen 2-3GHz um trotzdem einen relativ begrenzten Stromverbrauch/Kühlbedarf zu erhalten. 180W sind bei 32C ergibt grob 45W/Die. Es gibt seit kurzem noch ein paar neue Modelle, die mehr Cache oder einen etwas höheren Takt bieten. Der extremste Fall dürfte aber der EPYC 7371 mit 16C und einem Takt von 3.1-3.6GHz sein (200W TDP).
Andererseits wird auch von den Kunden erwartet, dass die CPUs eben nicht schon an der Grenze laufen, die sind alle ziemlich konservativ selektiert. Schliesslich sollen die ein paar Jahre unter Last laufen.

Eldoran

2019-02-03, 20:31:06

gravitationsfeld

2019-02-03, 21:59:03

APUs sind nicht CPUs. Die GPU verliert auf den Konsolen ~10% Leistung durch die CPU-Zugriffe. 1GB L4 wuerde wohl ziemlich sicher DRAM bedeuten, aber halt die GPU entlasten.

Ich sage nicht, dass das wirklich so kommt, aber es ergibt zumindest Sinn.

reaperrr

2019-02-03, 21:59:09

Ein L4 macht heute kaum einen Sinn - früher war da eDRAM einigermassen sinnvoll, aber mittlerweile taktet das normale RAM höher, da wird der Nutzen immer kleiner. Vor ein paar Monaten gab es einen Test mit dem einen i7-5775C auf techreport, aber heute ist der Broadwell nicht mehr sonderlich überragend, bzw. würde eben ein Coffee Lake mit eDRAM auch keine wunder bewirken.
https://techreport.com/review/34205/checking-in-on-intel-core-i7-5775c-for-gaming-in-2018
Der 5775C krankt an niedrigerer IPC (jedenfalls ggü. SKL/CFL), niedrigerem Takt und weniger Kernen im Vergleich zu den anderen getesteten CPUs.

Dass er trotz weniger IPC, weniger L3, weniger Takt und weniger echten Kernen teilweise zumindest bei 99th Percentile noch vor dem 8400 liegt und auch dem 2700X manchmal auf die Pelle rückt, sagt einiges. Auch im Vergleich zu einem 6700K - geschweige denn 2400G - würde er noch ziemlich gut abschneiden, gemessen an Takt und IPC.

Der 9900K würde definitiv gut von L4 profitieren, noch deutlich mehr als der 5775C, weil doppelte Kern/Threadzahl + mehr Takt und IPC auch die Bandbreiten-Anforderungen hochtreibt.

Zossel

2019-02-03, 22:18:09

Eldoran

2019-02-03, 22:59:52

Der 9900K würde definitiv gut von L4 profitieren, noch deutlich mehr als der 5775C, weil doppelte Kern/Threadzahl + mehr Takt und IPC auch die Bandbreiten-Anforderungen hochtreibt.
Das ist alles relativ - wenn der 9900K wie üblich mit schnellem RAM etwa DDR4-3200 betreibt, ist der Unterschied minimal. Ausser dieser hypothetische L4 ist eher so etwas wie HBM, vor allem wenn das ganze ziemlich gross sein soll - etwa 1GB. Da stellt sich bei so etwas eben auch die Frage wie viel besser die Latenz sein sollte. Für eine GPU schaut das eben wieder anders aus, da zählt eher die Bandbreite.
Ein Hinweis wäre auch, dass intel selbst bei Skylake Crystal Well nicht mehr als L4, sondern als memory side cache nutzt, also bei Zugriffen aus das RAM parallel im eDRAM schaut, und das erste Ergebnis nutzt. Es ist auch völlig offen wie weit das ganze überhaupt skalierbar wäre. Die Latenz geht i.d.R. nach oben, je grösser das ganze wird. Das ganze verbraucht auch eine Menge Strom. Auch beim 9900K ist das ganze normalerweise noch nicht sonderlich von der Bandbreite beschränkt, ausser wir reden von AVX lastigem gut parallelisierten Code. Allerdings denke ich, dass es in diesen Anwendungsgebieten schlicht effizienter ist wie bisher auf Quadchannel Interfaces (oder breiter) umzusteigen.
Oder ein anderes Beispiel - bei EPYC ist etwa der L3 teilweise auch nur minimal besser wie ein lokaler RAM Zugriff. Der Hauptzweck ist da eher Bandbreite sparen bzw. den energieintensiven Lookup.

Man muss solche Dinge auch immer wieder im Zusammenhang sehen - gerade bei Cache ist wichtig, dass dieses eben deutlich bessere Leistungsdaten bietet wie die darunter liegende Stufe. Das hat sich auch bei x86 in den letzte 20 Jahren mehrfach gezeigt, dass eben die letzte Cache Stufe teilweise nichts gebracht hat.

Setsul

2019-02-04, 00:14:16

@robbitop:
Also abgesehen davon, dass man am Fabric etwas machen könnte, es kostet nur zu viel Strom, bringt mehr Cache immer etwas. Selbst wenn das Fabric 1000 Takte Latenz hätte, solange der L4 eine deutlich niedrigere Latenz als der DRAM, wird die durchschnittliche Latenz sinken. Und IBM hat bei POWER8 einen eDRAM auf 27 Takte runtergeprügelt, das ist schneller als DDR4 je sein wird.

@gravitationsfeld:
Best case beim SKL L3 sind 38 Takte, bei SKL-X 50 oder so und worst case bei 80-90. Trotzdem schneller als DRAM.

@Eldoran:
Der normale RAM taktet nicht höher. DDR4-3200 hat 1600 MHz I/O-Takt und die Chips selbst takten mit 400 MHz. 3000 MHz eDRAM taktet mit 3000 MHz. Siehe oben. Und siehe auch reaperrr. Wenn ein 5775C einen 9900K mit in der Summe von IPC und Takt 40% Vorteil und doppelt sovielen Kernen schlagen würde, dann bräuchte niemand mehr neue Architekturen. Einfach alles mit eDRAM zufplastern. Das heißt nicht dass ein 9900K mit eDRAM nicht schneller wird. Es gibt keine magische Grenze ab der niedrigere Latenz nichts mehr bringt.

@Zossel:
Ich hab gerade keine bessere Quelle aber hier:
https://www.anandtech.com/show/6993/intel-iris-pro-5200-graphics-review-core-i74950hq-tested/3
At idle, simply refreshing whatever data is stored within, the Crystalwell die will consume between 0.5W and 1W. Under load, operating at full bandwidth, the power usage is 3.5 - 4.5W.
Das stört bei den 150W auch nicht mehr.
Und der 9900K ist doch spottbillig. Vor Ryzen wollte Intel schlappe 1089$ für 8 Kerne. Irgendein Idiot findet sich immer. Abgesehen davon kostet der eDRAM keine 20$. Wenn Intel wollte könnten sie das Ding für den gleichen Preis mit eDRAM verkaufen und trotzdem nicht arm werden.

@Eldoran:
HBM hat nicht auf magische Weise niedrigere Latenz als DDR4. Das sind effektiv die gleichen Chips. Bandbreite != Latenz.

Mit SKL CRW sollte doch eigentlich klar sein dass der eDRAM immernoch schneller als DRAM ist. Bei der Organisation gehts um ganz andere Sachen. Es wird nicht mehr 1/4 des L3 für die L4 Tags verwendet, auch andere Requests vom System Agent können gecached werden, nicht nur Anfragen von der CPU/iGPU und der L4 ist kein Victim Cache mehr. Das letzte bedeutet dass man nicht mehr erst 16 MB Texturen laden muss und dabei 4 komplette L3 Füllungen braucht die viele nützliche andere Lines rauswerfen sondern der GPU Treiber kann das sogar explizit verbieten und die Texturen einfach im L4 lassen ohne den L3 zu stören.
Also in der Summe: L4 für alle, nicht nur die CPU/iGPU und mehr nutzbaren L3 anstatt massiv L3 zu opfern um den L4 nutzbar zu machen.

Lokaler L3 ist bei EPYC viel besser als RAM. L3 auf anderen Dies ist natürlich langsamer als der eigene RAM und spart auch nicht viel Energie. L3 im anderen CCX liegt am IF. Ist aber alles müßig weil das kein shared L3 ist. Die L3s sind Victim Caches, die bekommen nur Lines die in den eigenen L2s waren. Bandbreite sparen ist noch ganz nett aber viel wichtiger ist die Kohärenz. Dafür muss auf den anderen L3s sowieso zugegriffen werden können selbst wenn sie auf einem anderen Die sind, Energie hin oder her, Bandbreite gibts dann gratis dazu.

robbitop

2019-02-04, 11:24:28

Was fuer ein Quatsch. L3 ist selbst im Worst-Case 30 cycles, DRAM sind hunderte. Und mit einer GPU am selben Interface und GDDR mit den laengeren Bursts ist das noch viel schlimmer.
Den L3 meinte ich nicht im Speziellen. L3 Latenz ist schlechter als bei SKL, was aber noch massiv schlechter geworden ist, ist die Memorylatency. Gute 20 ns schlechter als bei SKL. SKL-X und Zen haben durch ihre Fabric hier sehr ähnliche Auswirkungen in so einigen Spielen. Bei skalieren auch besonders gut mit der Verringerung dieser Latenz durch höheren Speicher/Fabrictakt und optimierte Timings.

Schau dir die Latenzmessungen an. Die reine Zugriffszeit ist nur ein Teil der Gesamtlatenz.
L4 liegt bei rund 40 ns bei aida (ist aber auch dram!). Bei modernen CFLs mit anständigem Speichertakt und getunten Latenzen sind es knapp unter 40 ns.

@setsul und @gravitationsfeld
Die Zugriffszeiten auf den Nachbar CCX bei Zen über die IF sind laut den Messungen von pcper bei rund 80 ns. Die Fabric oder was sonst noch auf dem Weg liegt ist anscheinend einfach irre lahm.

Der 5775C krankt an niedrigerer IPC (jedenfalls ggü. SKL/CFL), niedrigerem Takt und weniger Kernen im Vergleich zu den anderen getesteten CPUs.

Dass er trotz weniger IPC, weniger L3, weniger Takt und weniger echten Kernen teilweise zumindest bei 99th Percentile noch vor dem 8400 liegt und auch dem 2700X manchmal auf die Pelle rückt, sagt einiges. Auch im Vergleich zu einem 6700K - geschweige denn 2400G - würde er noch ziemlich gut abschneiden, gemessen an Takt und IPC.

Der 9900K würde definitiv gut von L4 profitieren, noch deutlich mehr als der 5775C, weil doppelte Kern/Threadzahl + mehr Takt und IPC auch die Bandbreiten-Anforderungen hochtreibt.

9900K sollte mit sehr gutem RAM die Latenz vom eDRAM im 5775c sogar schlagen. Er hätte keinen Effekt mehr. Die Messungen sind idr bei 40...42ns. Memorylatency von 36...38 ns (mit zugegeben sehr guten RAM) habe ich bereits gesehen.

Setsul

2019-02-04, 12:43:34

Wie gesagt IBM hat eDRAM schon auf 27 Takte bei 5 GHz runtergeprügelt. So pauschal zu sagen dass eDRAM langsamer ist als RAM beim 9900K ist falsch.
Natürlich ist es nicht sinnvoll einen Cache mit 50ns einzubauen wenn man in 40ns zum RAM kommt, aber das heißt nicht dass Caches generell nichts mehr bringen und ist auch völlig unabhängig davon ob es SRAM oder eDRAM ist.
Ob es sinnvoll ist, weil ein entsprechend schneller Cache auch entsprechend stromhungrig ist, ist etwas anderes.

Also nochmal zum Mitschreiben: Cache ist nur sinnvoll wenn er schneller ist als RAM und kann auch immer schneller sein als RAM. Ein Cache mit x MB direkt neben oder auf dem CPU-Die kann garantiert immer niedrigere Latenz haben als ein 10cm entfernter 32 GB RAM-Riegel. Ob sich das von Kosten/Nutzen her lohnt (besonders Energie), ist ein ganz anderes Problem. Aber dass man einen Cache nicht mehr schneller machen kann als RAM kommt nicht vor.

Wie gesagt Fabric ist dabei egal. Wenn alles den gleichen Weg nimmt ist es egal ob das 10 oder 100ns dauert, wenn dahinter Cache + RAM hängt ist das besser als nur RAM.
1000 + 30 ns durchschnittliche Latenz sind besser als 1000 + 40 ns, auch wenn beides scheiße ist.

robbitop

2019-02-04, 12:55:07

Eldoran

2019-02-04, 14:10:39

Der Anteil der Fabric bei allem was den CCX verlässt ist anscheinend so hoch, dass es nur eben nicht so viel bringen würde.

IBM hat den edram aber auch ins eigene die integriert. Iirc kann das aber nicht jeder Produktionsprozess. Ggf deshalb nicht praktikabel. Und ja: wenn man deutlich unter 35 ns kommen würde damit, würde es in der Praxis sicherlich was bringen. (Bei Intels Ringbus sicherlich kP, bei Intels Mesh und AMDs IF eher nicht offnbar) Ich nehme aber mal an, dass das ohne auf dem gleichen die zu sein eher illusorisch ist.
Wenn nicht am gleichen Die, dann wird die Übertragung relevant. Das war intel etwa momentan verwendet hat eben keine signifikant höhere Bandbreite verglichen mit dem normalen RAM. Die Latenz ist etwas besser. Allerdings kann man auch nicht beliebig an den Schrauben drehen. Es gibt eine begrenzte Menge an Lötpunkten, parallele Leitungen neigen bei dichter Anordnung und auf höheren Frequenzen zu störenden parasitären Effekten. Davon abgesehen braucht das alles auch Platz. Ursprünglich waren etwa auch die i7 mit Crystal Well besonders große BGA Packages.
Es kommt natürlich auch eine Kosten/Nutzen Rechnung dazu. Es ging mir nur eben hauptsächlich darum, dass eDRAM etc. nicht prinzipiell magisch Vorteile bringen. Gerade der eDRAM L4 ist eben ein Kind seiner Zeit - unter den damaligen Verhältnissen war es effizient, unter anderem weil man sich damit eben auch erspart hat ein triple/quadchannel RAM Interface zu bauen, bzw. besonders hoch taktendes RAM zu verlangen. 2013 etwa war DDR3-1600 normal, da hat es eben einen deutliche Verbesserung gebracht. Heute wäre der Effekt deutlich kleiner, auch wegen dem grösseren L3. Da müsste das hypothetische eDRAM deutlich grösser sein und ein breiteres/schnelleres Interface haben. Billiger wird es dadurch auch nicht...

robbitop

2019-02-04, 14:20:46

Bandbreite ist für eine CPU im Großteil der typischen Consumer Workloads nicht ausschlaggebend. Für die GPU in einem SoC schon. Das war sicherlich der Hauptaugenmerk für Crystalwell.

][immy

2019-02-04, 15:34:52

Bandbreite ist für eine CPU im Großteil der typischen Consumer Workloads nicht ausschlaggebend. Für die GPU in einem SoC schon. Das war sicherlich der Hauptaugenmerk für Crystalwell.
nunja, ich weiß nicht so recht. Sind inzwischen doch recht viele Kernchen die hinzugekommen sind über die Jahre. Während die Speicherbandbreite nicht so extrem explodiert ist.
Könnte mir gut vorstellen, das die neuen CPUs, wenn die Kerne tatsächlich noch mal verdoppelt werden sollten, doch langsam ein Bandbreiten-Problem bekommen könnten. So das zumindest für die high-end Modelle >3200er Speicher erforderlich werden könnte. Die aktuellen Ryzens profitieren ja schon vom schnelleren Speicher, wobei der Knoten hoffentlich mal gelöst wird mit Zen2.

Eldoran

2019-02-04, 16:48:07

[immy;11917869']nunja, ich weiß nicht so recht. Sind inzwischen doch recht viele Kernchen die hinzugekommen sind über die Jahre. Während die Speicherbandbreite nicht so extrem explodiert ist.
Könnte mir gut vorstellen, das die neuen CPUs, wenn die Kerne tatsächlich noch mal verdoppelt werden sollten, doch langsam ein Bandbreiten-Problem bekommen könnten. So das zumindest für die high-end Modelle >3200er Speicher erforderlich werden könnte. Die aktuellen Ryzens profitieren ja schon vom schnelleren Speicher, wobei der Knoten hoffentlich mal gelöst wird mit Zen2.
Ryzen profitiert vor allem durch die Koppelung des IF an die Frequenz des Speichercontrollers.
Tatsächlich messbar stösst Ryzen erst an eine Grenze wenn AVX auf allen Threads läuft. Teilweise sieht man das sicher auch bei den 32C TR, wobei da noch die indirekte Anbindung des RAM hinzukommt. Es ist aber i.d.R. schwierig wirklich an der Bandbreite zu hängen. Selbst wenn das RAM die Bremse darstellt sind das eher Latenzprobleme oder Abhängigkeiten bei den Zugriffsmustern. Es muss relativ wenig Berechnungen erfordern, relativ lineare Zugriffsmuster verlangen aber gleichzeitig nicht im Cache bleiben. Es ist auch relativ schwer messbar. Ohne iGPU ist es ziemlich schwer da unter normalen Bedingungen an eine Grenze zu stossen. Oder auch im Umkehrschluss - nur einen RAM Riegel zu nutzen (und somit single channel) reduziert zwar die Leistung, aber vermutlich keine halbierte Leistung.
Normalerweise begrenzt eher, dass die Software weitere Cores nicht sinnvoll nutzen kann.

Setsul

2019-02-04, 17:16:35

@robbitop:
Es würde mehr oder weniger das gleiche bringen, IF hin oder her.
Aber die Latenz beim IF zu reduzieren würde mehr bringen, weil das einfach der größere Anteil ist.

IBM war nur so als Untergrenze. Auch auf einem eigenen Die gewinnt es einfach durch die kürzere Entfernung und höheren Takt im Vergleich zu DDR4.

CRW ist in der Tat hauptsächlich für die iGPU gedacht und generell Mobile. Also mehr Bandbreite und Energie sparen durch weniger RAM Zugriffe waren die Ziele.
Wenn man exakt den selben Aufbau an CFL anklebt und dann einen L4 mit 50ns und RAM mit 40ns hat, ist das natürlich sinnlos.
Aber man könnte mit exakt der gleichen Technik, eDRAM auf dem gleichen Prozess, locker die Latenz unterbieten, wenn das Ziel ist, wenn man bereit ist entsprechend Strom zu verbrauchen. Das ist nicht illusorisch. Sinnvoll zwar auch nicht, aber das war nicht die Frage.

Ich darauf hinaus, dass diese Behauptung "Die Latenz der Fabric ist so hoch, dass ein L4 eDRAM keinen Effekt hätte." einfach komplett falsch ist.
Latenz des Fabrics ist egal. Sicher, wenn das Fabric 10 mal so hohe Latenz hat wie der Cache an sich dann sollte man sich eher damit befassen als mehr Cache dranzuschrauben, aber es macht den Cache nicht weniger effektiv. Nur weniger sinnvoll weil "einfachere" Maßnahmen mehr bringen und weniger kosten.

Wenn das Ziel niedrigere Latenz und nicht höhere Bandbreite ist, dann sind on-Die Caches auch wesentlich attraktiver. Für die iGPU bringen 128 MB mit 100 GB/s und 50 ns viel mehr als 1 MB L3 mit 1000 GB/s und 10 ns. Wenn Latenz das Ziel ist, dreht sich das um. Also unabhängig von eDRAM vs SRAM, wo man immer die Kalkulation kleinere Fläche vs höhere Kosten pro Wafer macht ist bei Latenz eher die Frage großer L4 oder mehr L3, aber insgesamt weniger. Auf den L4 wird erst nach dem L3 Miss zugegriffen. Auch wenn der L4 30 ns Latenz oder weniger hat braucht man wesentlich mehr davon damit die durchschnittliche auf den gleichen Wert kommt wie mit einem größerer L3 mit 10-15 ns.

Also nichts gegen L4, nichts gegen eDRAM, aber man baut keinen off-chip 128 MB Cache für die Latenz. IBM und Intel machen es beide für Bandbreite und Energie. Wie ich schonmal geschrieben habe ist bei Zen2 ist ein L4 Cache auf dem I/O-Die deshalb nicht sinnvoll, egal ob eDRAM oder SRAM, weil Zen2 kein Bandbreitenproblem hat mit 8 DDR4-Channels und selbst wenn würde jeder Cache dort vom IF zu den Chiplets limitiert, und die Energiebilanz ist sowieso im Eimer wenn man schon off-Chip gegangen ist. Zen hat ein Latenzproblem und das löst man nicht off-Chip, weil das alles viel schwieriger macht. Für die Latenz ist ein größerer existierender on-Chip Cache besser, weil dort in doppelter Hinsicht weniger mehr ist.

Langer Rede kurzer Sinn: L4 bringt etwas, off-Chip Cache bringt was, aber beides ist hauptsächlich für Bandbreite. Für Latenz bringt es zwar auch etwas wenn man will, aber alles andere bringt mehr.

Zossel

2019-02-04, 20:45:43

So ist es. SKL-X krankt wie auch Ryzen an der Latenz. Beides resultierte aus der Fabric.

Die Latenz der Fabric ist so hoch, dass ein L4 eDRAM keinen Effekt hätte.
CFL unterbietet mit anständigem Speichertakt und Timings auch die Latenzen die man vom i7 5775c kennt. Also auch dort nicht mehr sinnvoll.

Für mehr Cores braucht es eben andere Architekturen als Full mesh oder Ringbus, aber das ist nun nichts neues der Entwicklung von CPUs.

Als die Busse breiter wurde gab es Strafpunkte für missaligned Zugriffe, Als Caches aufkamen gab es Strafpunkte wenn die Zugriffe so erfolgten das der Cache nicht richtig greifen konnte. Als die Diskrepanz zwischen Cache und RAM immer größer wurde wurde der aligned Zugriff auf Cache Lines immer wichtiger. Die stackorientierte X87 FPU stellte sich für optimierende Compiler als nicht zu bewältigender Brocken heraus. Superskalere CPUs erfordern entsprechende Anordnung der Befehle. Pipelinig ging nicht mit selbstmodifizierenden Code und alten Debuggern. Und so weiter und so fort.

Nun ist es eben die höhere Bandbreite zwischen Cores die ihren Tribut fordert und Software braucht halt Anpassungen. Alles nicht neues, und jammern das früher in Stalingrad alles besser war bringt nix.

robbitop

2019-02-04, 22:24:21

LuisT

2019-02-05, 21:46:09

AdoredTV Gedanken zum Cache von zen2 https://www.youtube.com/watch?v=lM-21GySlso

JVC

2019-02-08, 09:37:41

https://www.techradar.com/news/amd-ryzen-3rd-generation
"AMD Ryzen 3rd Generation release date, news and rumors"

Alter scheiss neu aufgewärmt ?

m.f.g. JVC

M4xw0lf

2019-02-08, 09:44:18

https://www.techradar.com/news/amd-ryzen-3rd-generation
"AMD Ryzen 3rd Generation release date, news and rumors"

Alter scheiss neu aufgewärmt ?

m.f.g. JVC
Ja. Nur das AdoredTV-Gelaber.

Lowkey

2019-02-11, 23:13:35

Wenn VII mit 7nm so ist wie sie ist, was bedeutet es dann für Ryzen im Sommer?

Ist das 7nm oder fake 12nm?

Der_Korken

2019-02-11, 23:21:27

Wenn VII mit 7nm so ist wie sie ist, was bedeutet es dann für Ryzen im Sommer?

Erstmal nix. In Zen 2 dürfte deutlich mehr Entwicklung drinstecken als in V20. Man sollte sich nur von irgendwelchen Phantasien von +30% Takt verabschieden. Der Großteil der 7nm-Verbesserungen dürften in den Verbrauch fließen, um doppelt so viele Kerne realisieren zu können.

Gipsel

2019-02-12, 00:42:55

Ist das 7nm oder fake 12nm?Was meinst Du denn da mit? Natürlich sind das 7nm.

=======================

Man sollte sich nur von irgendwelchen Phantasien von +30% Takt verabschieden.Nun, die 2057 Cinebench-Punkte des demonstrierten 8C-Modells sind schon eine deutliche Steigerung zum 1800X (~1640 Punkte bei 3,7Ghz all core Boost) oder 2700X (~1830 Punkte bei ~4,05GHz allcore Boost bei guter Kühlung). Und die von AMD mal genannten +25% Taktvorteil der 7nm beziehen sich auf den Vergleich zu 14/16nm, nicht zum 12LPP-Prozeß des 2700X.
Der Cinebench-Score zeigt schon mal grob +26% mehr Leistung, was vermutlich zu einem großen Teil auf den erhöhten allcore Takt zurückzuführen ist. Dabei hat AMD betont, daß das noch nicht finale Taktraten wären und der Verbrauch von so grob 65W bei dem Takt (vermutlich mindestens 4,4GHz all core Frequenz bei der Demo, falls AMD nicht irgendwo noch einen großen IPC-Happen gefunden hat) läßt da wohl auch noch Spielraum nach oben. Insofern würde ich solche Behauptungen vielleicht nicht ganz so skeptisch sehen. Das kann durchaus drin sein. Sowohl beim allcore-Takt (meist durch Verbrauch limitiert, +25% zum 1800X wären 4,6GHz) als auch beim Single-Core-Boost (Limit des Siliziums), wo +25% dann 5,1 oder 5,2GHz wären.

SKYNET

2019-02-12, 02:15:35

Was meinst Du denn da mit? Natürlich sind das 7nm.

=======================

Nun, die 2057 Cinebench-Punkte des demonstrierten 8C-Modells sind schon eine deutliche Steigerung zum 1800X (~1640 Punkte bei 3,7Ghz all core Boost) oder 2700X (~1830 Punkte bei ~4,05GHz allcore Boost bei guter Kühlung). Und die von AMD mal genannten +25% Taktvorteil der 7nm beziehen sich auf den Vergleich zu 14/16nm, nicht zum 12LPP-Prozeß des 2700X.
Der Cinebench-Score zeigt schon mal grob +26% mehr Leistung, was vermutlich zu einem großen Teil auf den erhöhten allcore Takt zurückzuführen ist. Dabei hat AMD betont, daß das noch nicht finale Taktraten wären und der Verbrauch von so grob 65W bei dem Takt (vermutlich mindestens 4,4GHz all core Frequenz bei der Demo, falls AMD nicht irgendwo noch einen großen IPC-Happen gefunden hat) läßt da wohl auch noch Spielraum nach oben. Insofern würde ich solche Behauptungen vielleicht nicht ganz so skeptisch sehen. Das kann durchaus drin sein. Sowohl beim allcore-Takt (meist durch Verbrauch limitiert, +25% zum 1800X wären 4,6GHz) als auch beim Single-Core-Boost (Limit des Siliziums), wo +25% dann 5,1 oder 5,2GHz wären.

nen 2700X müsste runabout 4.6GHz allcore haben für den score.

basix

2019-02-12, 10:51:17

Würde ja gut zu +10% Takt und +15% IPC passen. Die IPC-Verbesserung in dieser Grösse stand ja irgendwo mal als Gerücht im Raum.

Gipsel

2019-02-12, 11:56:38

Würde ja gut zu +10% Takt und +15% IPC passen. Die IPC-Verbesserung in dieser Grösse stand ja irgendwo mal als Gerücht im Raum.+15% als Schnitt durch die Bank wäre schon recht viel (in Einzelfällen [z.B. bei heftigem AVX-Einsatz] wird es sicher sogar mehr werden), aber so weit ich weiß, kommt bei Cinebench nicht so recht viel AVX zum Einsatz. Da würde ich also eher auf recht moderate IPC-Steigerungen setzen (maximal 10% oder so). Aber ist natürlich im Moment auch nur mein Gefühl.

Der_Korken

2019-02-12, 12:15:29

@Gipsel: Wenn man vom Basistakt aus rechnet, dann sind 30% nicht so weit weg, aber der liegt in der Praxis nie an, außer vielleicht in Prime. Ein 2700X läuft oob so um die 4Ghz allcore im CB. +30% wären dann 5,2Ghz. Vom Singlecore Boost aus wären es sogar 5,6Ghz. Mir ist schon klar, dass das 12nm vs 7nm sind, aber es gab auch noch viel wildere Gerüchte als 30%. Z.B. dass das design target von 14nm bei 3Ghz liegt, während 7nm bei 5Ghz liegen soll und man daraus ableiten könnte, dass auch der Takt ähnlich stark steigt ;D.

Im Endeffekt sollte man beim Takt lieber seine Erwartungen bremsen, auch 7nm kann nicht zaubern. Intel hat schon in 32nm 4,5Ghz geschafft, Spitzenwerte beim OC gingen bis knapp 5Ghz. Mehr hat Skylake in 14nm auch nicht geschafft, erst 14nm+ und ++ haben noch so 500Mhz rausgequetscht.

Zuli

2019-02-12, 14:27:44

nen 2700X müsste runabout 4.6GHz allcore haben für den score.

Es gibt mehrere Einträge, die zwischen 4.3 und 4.4GHz benötigen um den Score von 2000 zu knacken. Also kann man eher von einem Takt von 4.1-4.3 GHz des ES ausgehen.

Gipsel

2019-02-12, 14:34:52

@Gipsel: Wenn man vom Basistakt aus rechnet, dann sind 30% nicht so weit weg, aber der liegt in der Praxis nie an, außer vielleicht in Prime. Ein 2700X läuft oob so um die 4Ghz allcore im CB.Ja, ich habe oben die Taktraten bei Cinebench angegeben, sowohl für den 1800X als auch für den 2700X. ;)
+30% wären dann 5,2Ghz. Vom Singlecore Boost aus wären es sogar 5,6Ghz. Mir ist schon klar, dass das 12nm vs 7nm sind,Also weißt Du, daß das dann die falsche Baseline ist, da AMD meines Wissens ausdrücklich die 14nm als Grundlage genannt hat (und +25% als Frequenzsteigerung). Da kannst Du also von 3,7GHz allcore-Turbo und 4,1 GHz XFR-Turbo (Threadripper bis 4,2GHz) ausgehen. Und dann kommt man eben nur noch auf 4,6GHz allcore bzw. 5,1/5,2 XFR. Plusminus ein wenig natürlich.
aber es gab auch noch viel wildere Gerüchte als 30%.Ich würde mich eher an öffentlichen Aussagen AMDs orientieren.
Im Endeffekt sollte man beim Takt lieber seine Erwartungen bremsen, auch 7nm kann nicht zaubern.Das auf jeden Fall. Falls Vega20 ein Indiz ist, scheinen ja offenbar Hotspots ein arges Problem zu sein (eventuell durch die hohen Stromdichten auch in den Leitungen, der Grund dafür, warum intel ab 10nm [was etwa TSMC 7nm entspricht] dort mal Kobalt verbauen wollte). Dies kann dann z.B. die singlecore Turbos effektiv begrenzen.

=================================

Es gibt mehrere Einträge, die zwischen 4.3 und 4.4GHz benötigen um den Score von 2000 zu knacken. Also kann man eher von einem Takt von 4.1-4.3 GHz des ES ausgehen.Mit 4,4Ghz liegt man im Normalfall mit einem 2700X noch ganz knapp unter 2000 Punkten, erreicht sie vielleicht gerade so (oder auch nicht, wenn man z.B. nicht sehr optimierte Speichersettings fährt). Und die live demonstrierten 2057 Punkte (der beste Run wäre vermutlich noch minimal höher) sind nochmal ein paar Prozentpünktchen mehr und sehr wahrscheinlich hat AMD dort recht langsam getakteten Speicher (DDR4-2666 mit stock SPD-Timings) benutzt. Aber das sind Details. Wir werden ja wohl spätestens im Sommer mehr wissen.

amdfanuwe

2019-02-12, 15:22:56

Zu Vega gibt es auch diese Grafik:
https://www.amd.com/system/files/styles/992px/private/2018-11/172884-mi60-vs-mi25-chart-1260x709_0.jpg?itok=Va2rEenq
Zwischen 1,5 und 1,8 GHz sind es aber nur 20% mehr Takt. Hängt wohl von der Frequenz ab, wieviel mehr Takt gegenüber 14nm erreicht werden. Also Basetakt +30% und Single Core nur + 20% beispielsweise. Bei den hohen CPU Taktraten könnte es auch noch schlechter aussehen.

HOT

2019-02-12, 15:28:37

Das ist klar, das irgendwo Ende ist. Das war ja bei Intel ebenfalls der Fall bei 32 -> 22nm -> 14nm. Erst 14+ i.V.m. unbeschränkter TDP brachte mehr Takt. Für deutlich mehr als 5GHz ist AMDs Design bestimmt nicht gedacht, wenn die überhaupt erreicht werden.
Zen1 war ja bis 3GHz sehr effizient, ab da mäßig effizient und ab 4 GHz gings dann abwärts. Zen2 wird das vielleicht etwas höher schrauben aber sicher keine 30%. So ein Graph wie für die V20 ist sicherlich auch für Zen2 zu erwarten. Also Maximalturbo wird dann sicherlich nur wenig Steigerung sein von 4,35 -> 4,7-5GHz. Den größten Vorteil wird Zen2 ggü. Zen1 sicherlich so um die 3,5GHz haben, wo Zen2 eben noch sehr effizient ist, Zen1 aber nur noch mäßig. Noch krasser wird das übrigens für Icelake gelten. Ich erwarte dort sogar eher wieder sinkende Maximalturbos <5GHz, jedoch werden die in den allcore-turbo-Bereichen sicherlich deutlich energiesparender als die Coffeelakes. Da muss die Mehrleistung aber definitiv aus der Architektur kommen (welche ja auch deutlich "dicker" wird), was anders ist als bei AMD, die da einfach noch mehr Luft haben - da gibts eben noch low-hanging-Fruits in der Architektur und der Prozesssprung wird größer.

basix

2019-02-12, 18:14:49

Zwischen 1,5 und 1,8 GHz sind es aber nur 20% mehr Takt. Hängt wohl von der Frequenz ab, wieviel mehr Takt gegenüber 14nm erreicht werden. Also Basetakt +30% und Single Core nur + 20% beispielsweise. Bei den hohen CPU Taktraten könnte es auch noch schlechter aussehen.

Genau deswegen kann man immer noch auf einen 16C @ 4 GHz All-Core hoffen ;)

Zossel

2019-02-12, 18:52:10

SKYNET

2019-02-12, 19:37:54

Es gibt mehrere Einträge, die zwischen 4.3 und 4.4GHz benötigen um den Score von 2000 zu knacken. Also kann man eher von einem Takt von 4.1-4.3 GHz des ES ausgehen.

nur wenn du die Priorität von CB auf hoch setzt... @ stock sinds eher um die 1930-1940 bei 4300

Langlay

2019-02-12, 21:49:34

nur wenn du die Priorität von CB auf hoch setzt... @ stock sinds eher um die 1930-1940 bei 4300

zwischen normal und hoch liegt bei mir kein grosser Unterschied. Das sind <5Punkte bei 4.35GHz was etwas mehr bringt ist Priorität auf Echtzeit. Das bringt bei mir so 10-15 Punkte.

https://abload.de/img/cinegtkgx.jpg

Das beste Ergebnis mit normaler Priorität war 1994 Punkte.

Zossel

2019-02-13, 07:01:03

zwischen normal und hoch liegt bei mir kein grosser Unterschied. Das sind <5Punkte bei 4.35GHz was etwas mehr bringt ist Priorität auf Echtzeit. Das bringt bei mir so 10-15 Punkte.

Wurde bei der Vorführung des Samples auch unter diesen Bedingen gemessen?
Und 10-15 Punkte sind noch nicht mal 2%, also quasi nicht relevant.

Langlay

2019-02-13, 08:13:14

Wurde bei der Vorführung des Samples auch unter diesen Bedingen gemessen?
Und 10-15 Punkte sind noch nicht mal 2%, also quasi nicht relevant.

Priorität kann durchaus auf hoch gewesen sein. Bei Echtzeit wird das Bild im Fenster nicht angezeigt beim Rendern, der Rechner friert für die Dauer des Runs ein. Also Echtzeit wars auf keinen Fall.

SKYNET

2019-02-13, 10:23:26

Priorität kann durchaus auf hoch gewesen sein. Bei Echtzeit wird das Bild im Fenster nicht angezeigt beim Rendern, der Rechner friert für die Dauer des Runs ein. Also Echtzeit wars auf keinen Fall.

bei hoch stockts auch ordentlich... da poppen die kacheln dann auf einmal auf anstelle das sie balkenartig erscheinen... bei "höher als normal" gibts ausser ein paar punkte mehr keinen unterschied.

gbm31

2019-02-13, 10:38:39

Alles Cheater! ;-D

Ich hab daran noch nie gedreht...

Der_Korken

2019-02-13, 10:47:24

Alles Cheater! ;-D

Ich hab daran noch nie gedreht...

Bei mir liegen zwischen "normal" und "höher als normal" gerne mal 50-60 Punkte, von daher ...

SKYNET

2019-02-13, 11:52:20

Alles Cheater! ;-D

Ich hab daran noch nie gedreht...

meine CB ergebnisse sind generell ohne pfusch an der priorität... :P

aber sollte wirklich mal mit echtzeit testen ;D

Langlay

2019-02-13, 22:02:29

bei hoch stockts auch ordentlich... da poppen die kacheln dann auf einmal auf anstelle das sie balkenartig erscheinen... bei "höher als normal" gibts ausser ein paar punkte mehr keinen unterschied.

Also ich seh keinen Unterschied zwischen normal und hoch. Da stockt bei mir nix.

Bei mir liegen zwischen "normal" und "höher als normal" gerne mal 50-60 Punkte, von daher ...

Dann hast du wahrscheinlich viel Scheiss im Hintergrund laufen.

Leonidas

2019-02-19, 09:08:11

Ryzen 3000 mit X570 mit Launch erst am 7.7. lt. Red Gaming Tech:
http://www.redgamingtech.com/exclusive-ryzen-3000-navi-release-date-specs-intel-comet-lake/

Ist aber eher nur Hörensagen über Branchengeflüster. Die Sache mit dem gleichzeitig geplanten Launch von Navi (selbst wenn es nun verschoben sein soll) macht es nicht glaubwürdiger.

Piefkee

2019-02-19, 09:10:29

http://www.redgamingtech.com/exclusive-ryzen-3000-navi-release-date-specs-intel-comet-lake/

Vorstellung Ryzen 3000, X570 und Navi zur Computex. Launch an 7.7 (7nm). Anscheinend ist der Navi Termin noch nicht Save da es Zeitlich eng mit der Produktion wird.

Zu Zen2:
- höhere taktraten
- zuerst folgt 12Core und später 16 Core

Renoir soll noch im H2 2019 kommen

RedGamingTech sagt fie Infos kommen von selben leaker der ihm bereits fiebinfos von Vega 7 gegeben hat (Fotos vor Release und Infos )

Dunkeltier

2019-02-19, 09:25:12

Erst ab Mitte Juli? Da kann ich dann auch noch die restlichen 4-5 Monate bis zum Intel überbrücken, vergleichen und mich dann entscheiden. Finde ich ehrlich gesagt etwas enttäuschend.

Mangel76

2019-02-19, 09:32:45

Erst ab Mitte Juli? Da kann ich dann auch noch die restlichen 4-5 Monate bis zum Intel überbrücken, vergleichen und mich dann entscheiden. Finde ich ehrlich gesagt etwas enttäuschend.

Ja, sehr enttäuschend. Nur gut dass Intel seine 10nm-CPUs, die schon vor 2 Jahren angekündigt wurden, so pünktlich ausgeliefert hat, sonst müsste man jetzt 1-2 Monate länger auf ZEN 2 im neuen Fertigungsverfahren warten ... oh wait ;D

nairune

2019-02-19, 09:38:51

Das sind 5 Wochen nach der Computex... Weltuntergang.
Wenn dafür alles sofort gut läuft und Verfügbarkeit gegeben ist, finde ich das besser als überhastet zu einem Eventtermin releasen zu müssen.

Nightspider

2019-02-19, 10:18:33

maximus_hertus

2019-02-19, 10:27:30

Erst ab Mitte Juli? Da kann ich dann auch noch die restlichen 4-5 Monate bis zum Intel überbrücken, vergleichen und mich dann entscheiden. Finde ich ehrlich gesagt etwas enttäuschend.

4-5 Monate? Hast du einen anderen Kalender? Stand heute kommt Intel erst 2020 und eher nicht im Januar (kaufbar). Überhaupt ist es bei Intel teilweise heftig, wie früh man vor Verkaufsstart die Produkte präsentiert. Der 28 Kerner wurde zur Computex 19 präsentiert, erst 7(!) Monate später dann der echte Launch...

Imo deutet vieles auf einen Start nicht vor März / Ende Februar 2020. Chinese New Year ist Ende Januar, von daher würde man eher nicht um dieses Datum herum launchen / den Verkaufsstart legen.

Piefkee

2019-02-19, 11:10:53

Niemand weiß wann Icelake kommt.

Anscheinend gibt es kein Icelake für Desktop. Comet lake soll im q1 2020 im 14nm +++++ kommen. Danach h2 soll Tiger in 10nm kommen...

Pirx

2019-02-19, 11:18:49

lt Erfahrung kommt AMD meist eher später, alle anderen eher früher;)

Linmoum

2019-02-19, 11:31:41

Was heißt hier "erst" am 7.7? Es hieß Mitte 2019, das passt wunderbar dazu. Massiver Vorsprung gegenüber Intel, wo immer noch nicht klar ist, was wann in 10nm für den Desktop kommen wird.

Wenn AMD wie bei den bisherigen beiden Ryzen-Launches erneut genug CPUs zum Marktstart parat hat, wird das lecker. Quelle halte ich erstmal für glaubwürdig, die hatten Bilder der VII bereits im Dezember veröffentlicht.

Menace

2019-02-19, 13:48:01

Ryzen 3000 mit X570 mit Launch erst am 7.7. lt. Red Gaming Tech:

:rolleyes:

AMD sollte erst einmal die Servervariante (Rome?) raushauen. Da müssen erst einmal viele Marktanteile gewonnen werden. Und das ist für die Entwicklung zukünftiger Produkte noch wichtiger.

@Dunkeltier: Welche Logik. :freak: Die Zeit bleibt gleich, wann intel erscheint.

BoMbY

2019-02-19, 15:19:28

Ryzen 3000 mit X570 mit Launch erst am 7.7. lt. Red Gaming Tech:
http://www.redgamingtech.com/exclusive-ryzen-3000-navi-release-date-specs-intel-comet-lake/

An einem Sonntag? Macht Sinn ...

Screemer

2019-02-19, 15:27:54

als hätte es noch nie Marketingveranstaltungen an sonn- und Feiertagen gegeben...

HOT

2019-02-19, 15:31:00

:rolleyes:

AMD sollte erst einmal die Servervariante (Rome?) raushauen. Da müssen erst einmal viele Marktanteile gewonnen werden. Und das ist für die Entwicklung zukünftiger Produkte noch wichtiger.

@Dunkeltier: Welche Logik. :freak: Die Zeit bleibt gleich, wann intel erscheint.
Das sind vollkommen unterschiedliche Produkte und die Lanches werden sich gegenseitig nicht beeinflussen.

maguumo

2019-02-19, 15:42:42

Gipsel

2019-02-19, 15:57:32

Das sind vollkommen unterschiedliche Produkte die das selbe Chiplet verwenden. Möglicherweise haben sie davon auf absehbare Zeit noch nicht genug auf Halde liegen, dann können sich die Launchtermine natürlich beeinflussen.Die Verkaufsvolumen im Serverbereich sind vermutlich gegenüber der Nachfrage im Desktopbereich relativ klein. Die Serverangebote könnten deswegen früher starten (zumindest solange es kein Problem mit dem IO-Die gibt, was sich ja unterscheidet). Aber der Launch im Desktopbereich wird wohl kaum merklich von den paar für den Serverlaunch benötigten Dies verzögert, zumal da auch etwas andere Bins zur Anwendung kommen dürften (Serverparts achten eher auf niedrigen Verbrauch bei doch eher moderatem Takt).

maguumo

2019-02-19, 16:01:33

Nicht bedacht wie groß der Mengenunterschied zwischen den benötigten Chips ist, stimmt natürlich.

BoMbY

2019-02-19, 16:11:17

als hätte es noch nie Marketingveranstaltungen an sonn- und Feiertagen gegeben...

Ja, gibt es. Bei anderen Firmen. Bei AMD bisher niemals. Der Launch war immer an einem Wochentag, bevorzugt glaube ich Dienstags oder Donnerstags.

Leonidas

2019-02-19, 16:45:40

Stimmt, das ist ein Gegenargument. Wir reden hier über den echten Launchtermin, die Ankündigung soll ja vorher schon auf der Computex stattfinden. Launchtage sind üblicherweise Donnerstag und Dienstag.

Das mit "7.7." könnte natürlich der Grund für die Ausmahme sein. Das AMD aber überhaupt Navi zum selben Tag geplant haben könnte, macht es für mich unwahrscheinlich. Niemand legt zwei wichtige HW-Launches auf denselben Tag.

maximus_hertus

2019-02-19, 16:52:44

Der 7.7. liegt zudem am Unabhängigkeitstag/WE (4.7., da haben viele ein langes WE).

Da in den USA afaik die Kalenderwoche am Sonntag anfängt, könnte mit 7.7. auch die entsprechende Woche gemeint sein.Also z.B. Dienstag, 9.7. und/oder Donnerstag 11.7.. Da man nur die Woche festgelegt hat, gibt man den 7.7. an mit der Woche ab dem 7.7. :)

rentex

2019-02-19, 16:54:34

Warum nicht, wenn sie sehr viel Vertrauen in ihr Produkt haben...könnte Intel ein ungemütlich spannendes Wochenende bereiten und nen Kater Montag (also miesen Wochenstart) bringen😂
Aufmerksamkeit wäre vollständig da😉

Complicated

2019-02-19, 16:57:06

Complicated

2019-02-19, 17:01:31

Das AMD aber überhaupt Navi zum selben Tag geplant haben könnte, macht es für mich unwahrscheinlich. Niemand legt zwei wichtige HW-Launches auf denselben Tag.
Das stimmt.
Ein solches Vorgehen würde nur bei einem OEM Launch mit Komplettsystemen Sinn ergeben. Vielleicht war das ein Argument oder ein Zugeständnis um größer bei dem OEMs einzusteigen...Intel hat schließlich wenig anzubieten zu den statt findenden Messen 2019.

hilo

2019-02-19, 18:19:09

Na ob Sonntag oder nicht finde ich ehrlich gesagt vergleichsweise unspannend vor dem Hintergrund, daß Intels Comet Lake erst 2020 dann immer noch in 14 nm (+++++++++++++) kommen soll. "Bummer", wenn's stimmt. Da rätselt doch keiner über irgendeinen Wochentag oder Monat in 2019!?!

Linmoum

2019-02-19, 18:31:35

Erst 2020 wäre auch unabhängig von 14nm++++++ oder doch 10nm mies für Intel. Dann natürlich noch die spannende Frage mit wie vielen Kernen. Zen2 erst mit 12C würde passen, sodass man easy einen 16C nachschieben wird, wenn Intel dann auch mal so weit ist.

Und natürlich die Frage danach, wann Intel dann wieder konkurrenzfähig (keine einzelnen Parameter, liebe Single Core-Freunde ;) ) sein wird. Fast schon Antik und jetzt wird es wieder Realität.

M4xw0lf

2019-02-19, 18:43:16

TSMCs aktueller 7nm-Prozess basiert genau wie Intels 14(alle Varianten) und 10nm noch auf 193nm ArF-Laser-Lichtquelle. An sich ist "14/10nm" vs "7nm" kein gravierender technologischer Nachteil.
(Abgesehen davon, das Intel die letzte 193nm-Ausbaustufe aka 10nm wohl einfach nicht in den Griff bekommt, und den Schritt zu EUV anscheinend noch nicht zu gehen bereit ist.)

hilo

2019-02-19, 19:02:19

Naja, ist ja erstmal auch nur 'ne Scheißhausparole. Das Ungute ist eigentlich eher, daß manch einer (ich z.B.) das Intel mittlerweile sogar zutrauen würde und, und da hat Linmoum glaube ich einen guten Punkt, daß sich der 16-Kerner bei AMD dann 2019 wohl rar machen würde. Wobei das keineswegs Linmoums Aussage war, sondern schon meine erweiterte Interpretation seiner Beitrags ist (nicht, daß ich ihm etwas in den Mund legen will).
Kann man sich aus Verbrauchersicht echt nicht wünschen.

RitterRost

2019-02-19, 19:12:58

Ich vermute mal, dass so ein Produkt-Launch viele Leute bei AMD beschäftigt. Also die PR-Abteilung und technischen Support z.B.
Schon alleine deshalb denke ich nicht, dass sie alles auf einen Termin legen KÖNNEN.
Ich denke, sie werden zur Jahresmitte versuchen, so lange wie möglich auf der medialen Welle zu reiten. Rome, Ryzen3 und Navi sind doch gute Themen... dazwischen etwas Zeit für die Reviewer und die Konkurrenz.

Gipsel

2019-02-19, 19:23:46

TSMCs aktueller 7nm-Prozess basiert genau wie Intels 14(alle Varianten) und 10nm noch auf 193nm ArF-Laser-Lichtquelle. An sich ist "14/10nm" vs "7nm" kein gravierender technologischer Nachteil.Wenn du so an die Sache rangehst: Alle Nodes seit den 0,13µm (130nm) nutzen ArF-Laser mit 193nm und sind demzufolge kein gravierender technologischer Nachteil. ;)
Also Packdichte und auch Performancedaten widersprechen Deiner These da recht deutlich. TSMCs 7nm haben auch ohne EUV-Belichter mal locker gut die doppelte Packdichte der Transistoren im Vergleich zu intels 14nm. Intel benötigt die 10nm (die in etwa ähnliche Werte schaffen wie TSMCs 7nm), um in dem Aspekt mitzuhalten (und mittelfristig bietet es auch auch Kostenvorteile, nicht nur bessere Performance und mehr Transistoren).

M4xw0lf

2019-02-19, 19:34:43

Wenn du so an die Sache rangehst: Alle Nodes seit den 0,13µm (130nm) nutzen ArF-Laser mit 193nm und sind demzufolge kein gravierender technologischer Nachteil. ;)
Also Packdichte und auch Performancedaten widersprechen Deiner These da recht deutlich. TSMCs 7nm haben auch ohne EUV-Belichter mal locker gut die doppelte Packdichte der Transistoren im Vergleich zu intels 14nm. Intel benötigt die 10nm (die in etwa ähnliche Werte schaffen wie TSMCs 7nm), um in dem Aspekt mitzuhalten (und mittelfristig bietet es auch auch Kostenvorteile, nicht nur bessere Performance und mehr Transistoren).
Schon, was ich meine ist, dass beide (bzw alle) die gleichen technologischen Voraussetzungen haben, da sie ja eh alle die mehr oder weniger gleichen Lithographiemaschinen am Start haben. Dass TSMC im know-how aktuell einen Vorsprung hat und dass Intel noch nicht dasselbe Level herausholt, ist natürlich offensichtlich.

HOT

2019-02-19, 20:19:42

Oder irgendjemnad meinte einfach die 7 muss jetzt immer für alle 7nm Produkte irgendwie herhalten...also ganz logisch der 7.7.
Entweder das AMD Marketing benutzt das solange keine 7nm CPUs der Konkurrenz zu sehen sind um immer wieder darauf hinzuweisen oder ein Fanboy denkt sich das genau so.
Jo das Marketing wird da den Ausschlag gegeben haben, genau wie bei der Radeon VII, wird eben der Ryzen da gelauncht und ich nehme an Navi10 dann vorgestellt als erste PCIe4-Grafikkarte in - Überraschung - 7nm.

Piefkee

2019-02-19, 21:40:11

Schon, was ich meine ist, dass beide (bzw alle) die gleichen technologischen Voraussetzungen haben, da sie ja eh alle die mehr oder weniger gleichen Lithographiemaschinen am Start haben. Dass TSMC im know-how aktuell einen Vorsprung hat und dass Intel noch nicht dasselbe Level herausholt, ist natürlich offensichtlich.

So ein Schwachsinn... natürlich gibt es gravierende Unterschiede bei der verschiednen Nodes... die scannner haben daran nicht wirklich einen Anteil.

Intel schafft es mit sicherheit lauffähige 10nm zu produzieren jedoch nicht mit einen yield der sich wirtschaftlich lohnt

davidzo

2019-02-19, 22:13:10

Niemand legt zwei wichtige HW-Launches auf denselben Tag.

Naja, das kann man schon machen, es spart unheimlich Ressourcen und Zeit. Für solche Termine sind ja alle wichtigen Manager für ein paar Tage geblockt und all die Journalisten einzufliegen und unter zu bringen inkl. Rahmenprogramm ist auch nicht billig. Von daher kann ich das Nachvollziehen dass man sich zwei Launches im Zeitraum von wenigen Tagen lieber spart.
Ich stimme dir aber zu dass ein Sonntagslaunch total unrealistisch ist. Dienstags kann man viel mehr Journalisten erreichen und der Handel kann auch mit Produktlistungen reagieren, Sonntag macht da überhaupt keinen Sinn.

mczak

2019-02-19, 22:56:20

Intel benötigt die 10nm (die in etwa ähnliche Werte schaffen wie TSMCs 7nm), um in dem Aspekt mitzuhalten (und mittelfristig bietet es auch auch Kostenvorteile, nicht nur bessere Performance und mehr Transistoren).
Wobei intel für die erste Generation 10nm bezüglich Performance und Power kaum was versprochen hatte - der sollte bloss ähnlich gut sein wie 14nm++, halt einfach viel dichter gepackt, was aber allein ja eigentlich keine Vorteile bietet (ausser dass es günstiger sein sollte, wenn man denn die Probleme vernünftig in den Griff bekommt).
10nm+ sollte dann laut den Roadmaps definitiv besser sein als 14nm++, ich habe aber keine Ahnung ob der noch gleich aussieht wie geplant. Der Sprung von 14nm++ zu 10nm+ könnte aber deutlich kleiner sein (punkto Performance und Stromverbrauch) als das bei TSMC von 16nm zu 7nm offensichtlich der Fall ist. Trotzdem dürfte so ein Comet Lake in 14nm+++ da Probleme haben gegen Zen 2 - intel's Glück ist aber dass auf dem Desktop Stromverbrauch praktisch kein Mensch interessiert, und das CPU-Design eine genügend hohe IPC und Taktgrenze hat um mitzuhalten (bei MT-Last dann halt auf Kosten eines höheren Stromverbrauchs). Klar gegen 16 Zen 2 Kerne reicht das nicht mit einem 10-Kerner, aber z.B. in Spielen liegt man dann vermutlich immer noch locker vorne weil die nun mal keine 16 Kerne benötigen und die Speicherlatenzen tiefer sind.

HOT

2019-02-19, 23:43:36

Für Latenzen bringt man offenbar den 9900kfc mit eDRAM.
Nach letztem Stand hat 10nm+ etwas weniger Leistung als 14nm++ aber natürlich eine erheblich bessere Performance pro Watt - hinzu käme die breitere Architektur Sunny Cove. Leider scheint Icelake Intels neuer Broadwell zu werden - nur Mobil und 2021 dann Icelake SP.

Leonidas

2019-02-20, 07:29:46

Naja, das kann man schon machen, es spart unheimlich Ressourcen und Zeit. Für solche Termine sind ja alle wichtigen Manager für ein paar Tage geblockt und all die Journalisten einzufliegen und unter zu bringen inkl. Rahmenprogramm ist auch nicht billig. Von daher kann ich das Nachvollziehen dass man sich zwei Launches im Zeitraum von wenigen Tagen lieber spart.

Das sehe ich komplett anders. Diese Zeit will man sich gönnen, nicht sparen! Da ist man da mal in aller Munde und kann die Diskussion bestimmen. Gerade deswegen kommen niemals 2 Produkte am selben Tag - es sei denn, Produkt No.2 soll unter dem Glanz von Produkt No.1 versteckt werden, weil No.2 nur mittelprächtig ist.

Bei zwei gutklassigen Produkte gibt es immer 2 Launches - Stichwort doppelte Aufmerksamkeit. Zudem dürfte AMD die Hardwaretester einen Husten, wenn sie die doppelte Arbeit zum selben Launchtag machen sollen (auch wenn das jetzt kein Entscheidungskriterium für AMD ist).

Zurück zum Thema: Wenn sich AMD seiner Sache sicher sein kann, könnte man mit einem 12C antreten und den 16C später nachschieben, wenn Intels Comet Lake klarer wird. Das kommt auch auf das Preisgefüge an: 12C+16C zusammen an einem Tag bedeutet, ein finales Preisgefüge aufzustellen. Zuerst den 12C und den 16C später bedeutet, das man spielen kann, wenn man will - sprich den 12C zuerst hoch ansetzen und dann reduzieren, wenn der 16C nachfolgt.

rentex

2019-02-20, 07:35:35

Klingt einleuchtend.

MSABK

2019-02-20, 07:39:04

Intel soll ja angeblich einen 8 Kerner für Notebooks bringen. Mal sehen was AMD da macht, eigentlich müssen die da mitgehen.

Brillus

2019-02-20, 08:03:26

Das sehe ich komplett anders. Diese Zeit will man sich gönnen, nicht sparen! Da ist man da mal in aller Munde und kann die Diskussion bestimmen. Gerade deswegen kommen niemals 2 Produkte am selben Tag - es sei denn, Produkt No.2 soll unter dem Glanz von Produkt No.1 versteckt werden, weil No.2 nur mittelprächtig ist.

Bei zwei gutklassigen Produkte gibt es immer 2 Launches - Stichwort doppelte Aufmerksamkeit. Zudem dürfte AMD die Hardwaretester einen Husten, wenn sie die doppelte Arbeit zum selben Launchtag machen sollen (auch wenn das jetzt kein Entscheidungskriterium für AMD ist).

Zurück zum Thema: Wenn sich AMD seiner Sache sicher sein kann, könnte man mit einem 12C antreten und den 16C später nachschieben, wenn Intels Comet Lake klarer wird. Das kommt auch auf das Preisgefüge an: 12C+16C zusammen an einem Tag bedeutet, ein finales Preisgefüge aufzustellen. Zuerst den 12C und den 16C später bedeutet, das man spielen kann, wenn man will - sprich den 12C zuerst hoch ansetzen und dann reduzieren, wenn der 16C nachfolgt.

Bzgl. Cores erwarte auch zuerst nur 12c und 16c wird erstmal als Kontor-Kontor zurückgehalten.

Fragman

2019-02-20, 08:04:27

Intel soll ja angeblich einen 8 Kerner für Notebooks bringen. Mal sehen was AMD da macht, eigentlich müssen die da mitgehen.

Hat AMD diesen Markt eigentlich auf dem Schirm?
Wenn man mal AMD Notebooks sieht, was eh schon selten ist, dann immer mit AMD GPU und dann denk ich mir immer, "Nein Danke!".
Ich stimme aber zu, wäre schön, wenn man da die Option auf nen 8core Ryzen hätte, schon der Leistung wegen. Aber halt gern in Verbindung mit einer CUDA GPU. ;)

HOT

2019-02-20, 08:56:31

Dank 7nm und Intel weiterhin fehlender 10nm könnte Ryzen3 ausnahmsweise auch in Notebooks eine Alternative sein, da klar besseres Perf/W, allerdings ist das ja keine APU und die Blockadehaltung der Hersteller (siehe MSI) müsste sich da erst mal aufweichen. Bleibt also dennoch unwahrscheinlich das Ganze. Das wird sich wohl erst mit Renoir ändern - dieses Produkt könnte für Intel richtig gefährlich werden im Notebookmarkt sollte sich Icelake auch hier weiter verzögern.

maguumo

2019-02-20, 09:20:13

Es gab doch im Januar Gerüchte über T495, 495s und X395 von Lenovo mit AMD APUs, angeblich im Juni. Da war dann wohl nichts dran.

amdfanuwe

2019-02-20, 09:23:12

Außer bei R3 hat AMD SMT eingeschaltet. Alle CPUs haben freien Multiplikator. Warum sollte da nur erstmal eine 12 Core CPU kommen? Dazu besteht keine technische Notwendigkeit.
Da keine Konkurrenz da ist, kann man die 12 und 16 Kerner entsprechend hoch einpreisen.

Am interessantesten wird doch, ob der 8 Kerner schneller als ein 9900K im Gaming wird, billiger wird er eh sein. Ob AMD die Gaming CPU Krone Intel entreißen kann.
Dazu ein Preis/Performance Knüller für Full-HD Gaming bzw. WQHD, schon ist die Gaming Gemeinde am toben. ( Ich denke an Vega 64 bzw. RTX 2060 Gamingleistung für < 300€ )

Opprobrium

2019-02-20, 09:30:23

Bzgl. Cores erwarte auch zuerst nur 12c und 16c wird erstmal als Kontor-Kontor zurückgehalten.
Könnte mir auch eine Klotzen statt Kleckern Strategie vorstellen. Wenn man erstmal nur den 12 Kerner veröffentlicht werden viele auf den 16-Kerner warten, oder schauen wie Intel reagiert. Wenn man gleich den 16er raushaut hat man Tatsachen geschaffen und kann dann immer noch im Herbst mit den TR 3000ern aufwarten.
Es gab doch im Januar Gerüchte über T495, 495s und X395 von Lenovo mit AMD APUs, angeblich im Juni. Da war dann wohl nichts dran.
Die APUs sind ja was anderes und wurden schon vor Wochen angekündigt, das ist kein Problem :smile:

amdfanuwe

2019-02-20, 09:37:04

Es gab doch im Januar Gerüchte über T495, 495s und X395 von Lenovo mit AMD APUs, angeblich im Juni. Da war dann wohl nichts dran.
Wieso? Erstens haben wir noch kein Juni und zweitens werden die wahrscheinlich auf Picasso basieren.

Matisse könnte in einer 35/45W Version für Notebooks auch interessant werden.
Mal sehen, was sich AMD noch einfallen läßt.

Screemer

2019-02-20, 09:41:46

Die APUs sind ja was anderes und wurden schon vor Wochen angekündigt, das ist kein Problem :smile:
Die 3000 apus sind aber Zen+ kombiniert mit vega. Haben also quasi nix mit den ryzen 3xxx zu tun. Diese apus kommen wohl mit Navi und erst in 2020 (Renoir).

amdfanuwe

2019-02-20, 09:47:15

Ich sehe kein konkurrenz Problem zwischen Threadripper und AM4 16 Kerner.
Threadripper hat höheres TDP Budget, mehr PCIe, mehr Speicherbandbreite und wahrscheinlich bis zu 64 Kerne. AM4 16 Kerner werden also geringeren ALL Core Takt bieten und bei manchen Anwendungen ins Bandbreitenimit laufen.

Korvaun

2019-02-20, 09:49:20

amdfanuwe

2019-02-20, 09:56:18

Der Aufwand dafür extra dafür eine eigene Plattform zwischen Server und Consumer zu haben ist schon sehr groß.
Welcher Aufwand? Die Platform existiert, die CPUs sind von den Server CPUs abgeleitet. Kaum Aufwand, riesen Image Gewinn.

Screemer

2019-02-20, 09:56:49

Ich kann mir gut vorstellen das 16 "Consumer" Kerne erst mit Ryzen 4000 kommen insbesondere um Threadripper dieses Jahr nicht noch weiter in eine eh schon kleine Nische zu drücken. Threadripper wäre dann eigentlich nur noch für extreme Spezialfälle interessant die mehr RAM/Bandbreite brauchen oder 24+ Kerne (abgesehen von den Leuten dies einfach haben wollen weil es zu kaufen ist ;)). Der Aufwand dafür extra dafür eine eigene Plattform zwischen Server und Consumer zu haben ist schon sehr groß.das halte ich für schlüssig. Consumer-16-kerner könnten so lange in der Pipeline bleiben bis entweder Intel kommt oder amd mit einem zen2 basierenden threadripper selbst aufschlägt. Imho werden wir auch keinen so schnelle Ablösung der ryzen 3000 Serie sehen. Ryzen 2000 war einfach zu simpel und eine zu niedrig hängende Frucht um diese nicht mitzunehmen. Sollte sich nicht ein hardwarebug einschleichen, der einfach mit einem neuen stepping gefixt werden kann und gleichzeitig ein Performanceplus bringt, dann sollte uns ryzen 3000 recht lang begleiten.

Korvaun

2019-02-20, 10:45:38

Wir werden 2020 sicherlich Ryzen 4000 sehen, egal ob das jetzt sinnvoll ist oder nicht. Außer es gibt irgendwelche gravierenden Probleme.

Die Kunden (hier: Endgerätehersteller) wollen jedes Jahr neue Prozzies/GPUs um neue PC/Notebooks verkaufen zu können, selbst nen einfacher "Rebrand" reicht da schon für die Masse ;)

HOT

2019-02-20, 10:53:36

Wird Zen3 geben, das ist seit Jahren bekannt. Man braucht für 7 EUV eh ne neue Maske, da kann man auch einen echten Refresh bringen.
Dank der Chiplets kann man ja jetzt auch jedes Jahr ein neues Die im jeweils aktuellen Prozess bringen, den I/O und die Plattform betrifft das ja gar nicht, was die Validierung ernorm erleichtern dürfte und den Zeitbedarf vom Tapeout bis zum Launch auch stark verringern könnte.
Zen4 in 5nm wird sicherlich dann wieder einen I/O-Chip bekommen und eine neue Plattform mit DDR5, danach ist wieder für ein paar Chipletgenerationen Pause mit großen Änderungen. Die CPU jedoch ist immer auf dem neuesten Stand.

Opprobrium

2019-02-20, 10:54:08

Die 3000 apus sind aber Zen+ kombiniert mit vega. Haben also quasi nix mit den ryzen 3xxx zu tun. Diese apus kommen wohl mit Navi und erst in 2020 (Renoir).

Eben. Ging ja nur um die Sorge, dass durch die (spekulative) Veröffentlichung der 3000er CPUs die Produktcerfügbarkeit der (mobilen, bereits im Januar gelaunchten) 3000er APUs betroffen sein könnte. Und da besteht nunmalkein Zusammenhang. Außer vielleicht, dass AMD die 3000er Desktop APUs erst zusammen mit den CPUs launchen könnte.

Complicated

2019-02-20, 12:37:10

Klingt einleuchtend.

Nicht wenn es ein OEM-Launch sein soll der sowohl CPU als auch GPU in einem Desktop-system oder gar einer ganze Serie benötigt. Um Anteile bei HP, Dell oder Lenovo zu steigern würde AMD sich wohl schon auf so etwas einlassen. Auch der Sonntag wäre dann kein Problem, da Retail noch gar nicht beliefert würde.

Brillus

2019-02-20, 15:31:06

Hat AMD diesen Markt eigentlich auf dem Schirm?
Wenn man mal AMD Notebooks sieht, was eh schon selten ist, dann immer mit AMD GPU und dann denk ich mir immer, "Nein Danke!".
Ich stimme aber zu, wäre schön, wenn man da die Option auf nen 8core Ryzen hätte, schon der Leistung wegen. Aber halt gern in Verbindung mit einer CUDA GPU. ;)

Kannst du mir Mal bitte die ganzen Notebooks mit dedizierter AMD GPU Posten, ich suche sowas in bis jetzt nur das TUF Gaming. Und das hat eigentlich noch eine GPU Stufe kleiner als ich möchte.

Fragman

2019-02-20, 15:49:42

https://www.alternate.de/AMD-Portal/Notebooks-mit-AMD-CPU

Als ein Beispiel, sind halt meistens die APU's.

BoMbY

2019-02-20, 17:33:39

Wird Zen3 geben, das ist seit Jahren bekannt.

So wie es aussieht dürfte wohl bereits Zen5 in der ersten Design-Phase sein.

amdfanuwe

2019-02-20, 19:08:20

Kannst du mir Mal bitte die ganzen Notebooks mit dedizierter AMD GPU Posten,
Besser wie 560X ist die Auswahl nicht groß.
https://geizhals.de/?cat=nb&xf=11294_10+5792+-+RX+580%7E11294_10+8286+-+RX+Vega+56%7E8149_dedizierte+Grafik

Brillus

2019-02-20, 19:22:29

Besser wie 560X ist die Auswahl nicht groß.
https://geizhals.de/?cat=nb&xf=11294_10+5792+-+RX+580%7E11294_10+8286+-+RX+Vega+56%7E8149_dedizierte+Grafik
Jo und die sind leider 17 Zoll und 300+Watt, beides leider für mich ein KO-Kriterium.

Wirds wohl das TUF ohne WIndows werden + Ram erweiterung sobald es lieferbar ist. Da warte ich drauf weil bei Arternate stand es Ende Januar schon mal als versandfertig in 3 Tagen da und dann waren es wieder 4 Wochen.

Leonidas

2019-02-21, 08:48:02

Könnte mir auch eine Klotzen statt Kleckern Strategie vorstellen. Wenn man erstmal nur den 12 Kerner veröffentlicht werden viele auf den 16-Kerner warten, oder schauen wie Intel reagiert. Wenn man gleich den 16er raushaut hat man Tatsachen geschaffen und kann dann immer noch im Herbst mit den TR 3000ern aufwarten.

Guter Überlegung. Daran wird man derzeit bei AMD sicherlich intern arbeiten bzw. die Köpfe rauchen lassen.

Threadripper hat höheres TDP Budget, mehr PCIe, mehr Speicherbandbreite und wahrscheinlich bis zu 64 Kerne.

Eigentlich war TR für Zen 2 nur bei 32C geplant bzw. der Sockel TR4 ist nur dafür ausgerichtet. Aber eventuell baut AMD diese Planung doch noch um, um TR3000 etwas mehr Bumms zu geben.

Denniss

2019-02-21, 10:17:13

Klotzen kann man vielleicht schon mit dem 12-Kerner, kommt drauf an wie schnell der wird im Vergleich zum 9900K. Den 16-Kerner kann man aber immer noch nachschieben, ich hätte lieber noch ein As im Ärmel statt vorzeitig alle Karten auszuspielen.

basix

2019-02-21, 10:28:51

unl34shed

2019-02-21, 10:46:47

Vor allem könnte man mit dem 16C auch einen Teil von Intels S2066 abgreifen.
Zumindest dann wenn RAM und Packe nicht so wichtig sind.

Der_Korken

2019-02-21, 10:50:29

Man könnte den 16C eventuell deswegen zurückhalten, um die TR-Plattform nicht zu kannibalisieren. Wobei AMD das beim 1800X vs 1900X auch nicht weiter gestört hat. Oder AMD plant für nächstes Jahr wieder einen "Zen2+" mit etwas mehr Takt und hebt sich den 16C dafür auf.

basix

2019-02-21, 10:51:37

Wenn man Faktor 2x für den 16-Kerner gegenüber dem 2700X annimmt wird man sehr oft auf etwa 7980XE Niveau landen.

@Der_Korken: Threadripper 3 kommt ja ebenfalls kurz darauf. Hier gibt es dann nochmals mehr Performance oder gar bis 48C.

maximus_hertus

2019-02-21, 10:52:02

Mit max 12C braucht man weniger voll funktionierende Chiplets. Bzw. diese gehen an Epyc (natürlich würden dann auch intakte 16 Kerne als 12 Kerner verkauft).

Evtl startet man mit: 6C/6T, 6C/12T, 12C/24T und ggf. einem 8C/16T, der aus zwei Chiplets besteht (je Hälfte deaktiviert).

Wenn die Fertigung genug 16 Kern CPUs ausspuckt, die zudem ausreichend hoch takten und bei max 105W liegen, dann werden die auch direkt kommen. Allerdings befürchte ich, dass der 16C zu oft hinter dem 12C landen wird dank Power Budget und/oder Takt sowie dem Windows-Scheduler.

Bei einem späteren Launch der 16C CPU kann man die besten Chiplets sammeln um möglichst immer den bestmöglichen Takt / Stromverbrauch zu bekommen.

SKYNET

2019-02-21, 10:52:51

Ein Ass im Ärmel? Wäre ein schlechtes, da nach dem Zen 2 Release jeder wüsste wie stark dieses Ass sein würde: Taktraten und Energieverbrauch kann man relativ leicht extrapolieren (ca. auf 10% genau) und dass 16C möglich sind weiss auch jeder. 12C vs. 10C ist evtl. noch zu nahe beieinander, hier könnte man auch zu Intel greifen (vor allem, wenn die Spieleperformance noch leicht hinter Intel liegen sollte). AMD mit 16C ist weit vor Intel mit 10C. Das ist ein deutlich stärkeres Plus wenn die Spieleperformance nicht wirklich besser oder etwas schlechter sein sollte. Ich sehe deutlich mehr Gründe, den 16C gleich zu Beginn zu bringen. Nur schon wegen dem Aha-Effekt.

WEIT vor intel mit 16 kernen, intel hat auf desktop nur 8 kerne als maximum, das andere sind schon die TR4 deviate aka sockel 2011-3 :wink:

oder anders gesagt: wir stehen am gleichen punkt wie zu erscheinen von Zen1, 8 kerne vs. 4 kerne bei intel... nur das diesmal auch die IPC gleichwertig bzw. besser sein wird.

würde sagen, für intel wird das ein hartes jahr, und schätze die verluste bei den retail CPU verkäufen nach erscheinen von zen2 auf 80-90% ein, die restlichen sind intelfans die aus prinzip nix anderes kaufen. :upara:

aber ansonsten gehe ich auch davon aus, das AMD nen full-in macht, 16 kerne auf desktop und intel auch bei der IPC die rücklichter zeigen, werde am tag wo die reviews online gehen, mich schön mit nem panache(alsterwasser/radler/shandy je nach region/land) hinsetzen, dazu nen sack chips und mir die gesichter der verzweifelten intel fans vorstellen ;D

nairune

2019-02-21, 10:55:19

Kann mir nicht vorstellen, dass der 16C (lange) zurückgehalten wird. Es soll doch vorerst jährliche Updates geben, soll der 16C dann nur 3 Monate auf dem Markt sein, bevor die neue Generation kommt?

maximus_hertus

2019-02-21, 10:58:10

WEIT vor intel mit 16 kernen, intel hat auf desktop nur 8 kerne als maximum, das andere sind schon die TR4 deviate aka sockel 2011-3 :wink:

oder anders gesagt: wir stehen am gleichen punkt wie zu erscheinen von Zen1, 8 kerne vs. 4 kerne bei intel... nur das diesmal auch die IPC gleichwertig bzw. besser sein wird.

würde sagen, für intel wird das ein hartes jahr, und schätze die verluste bei den retail CPU verkäufen nach erscheinen von zen2 auf 80-90% ein, die restlichen sind intelfans die aus prinzip nix anderes kaufen. :upara:

aber ansonsten gehe ich auch davon aus, das AMD nen full-in macht, 16 kerne auf desktop und intel auch bei der IPC die rücklichter zeigen, werde am tag wo die reviews online gehen, mich schön mit nem panache(alsterwasser/radler/shandy je nach region/land) hinsetzen, dazu nen sack chips und mir die gesichter der verzweifelten intel fans vorstellen ;D

Realitätscheck nicht bestanden :D

Für viele sind die Gaming Benchmarks entscheident und da sieht es aktuell nicht wirklich gut aus. Ein 9900K liegt 20-30% vor dem 2700X (manchmal sogar 40+%). Das muss man erstmal aufholen und einfach nur 16C werden dabei nicht helfen.

Erst wenn AMD durchgängig (in fast allen Games) vorne liegt müsste sich Intel überlegen, ob sie sich um den Dsktop Gedanken machen müssen.

Der Server Markt ist da naürlich anders, wobei die bisherige MArktdurchdringung von Epyc leider sehr bescheiden ist. Ich hoffe es komt der Durchbruch mit Rome.

Der_Korken

2019-02-21, 11:00:04

@Der_Korken: Threadripper 3 kommt ja ebenfalls kurz darauf. Hier gibt es dann nochmals mehr Performance oder gar bis 48C.

Wird TR3 direkt so hoch gehen? Hätte gedacht, dass es bei 4 Chiplets mit 32C bleibt.

Mit max 12C braucht man weniger voll funktionierende Chiplets. Bzw. diese gehen an Epyc (natürlich würden dann auch intakte 16 Kerne als 12 Kerner verkauft).

Evtl startet man mit: 6C/6T, 6C/12T, 12C/24T und ggf. einem 8C/16T, der aus zwei Chiplets besteht (je Hälfte deaktiviert).

Ich glaube nicht, dass die Ausbeute so mies ist bei den kleinen Chiplets. Das von AMD vorgeführte ES mit 8C und ~65W hatte auch nur ein Chiplet verbaut.

SKYNET

2019-02-21, 11:11:53

Realitätscheck nicht bestanden :D

Für viele sind die Gaming Benchmarks entscheident und da sieht es aktuell nicht wirklich gut aus. Ein 9900K liegt 20-30% vor dem 2700X (manchmal sogar 40+%). Das muss man erstmal aufholen und einfach nur 16C werden dabei nicht helfen.

Erst wenn AMD durchgängig (in fast allen Games) vorne liegt müsste sich Intel überlegen, ob sie sich um den Dsktop Gedanken machen müssen.

Der Server Markt ist da naürlich anders, wobei die bisherige Marktdurchdringung von Epyc leider sehr bescheiden ist. Ich hoffe es komt der Durchbruch mit Rome.

naja, da der multicore boost schon 4.6GHz sein wird beim 3700X(nach den CB15 ergebnissen zumindest stark anzunehmen), wirds 1-2C sicherlich nicht unter 4.9GHz sein... und da speichertakt bei CB kaum was bringt(eher timings), und der 3er 3200er speicher bekommen wird, wars das wohl mit der führung in games :biggrin:

bin nur ein optimistischer realist... :wink:

btw. in multicore macht mein 2700X nen 9900k ja auch total nass, der lebt nur durch seinen hohen 1-2C 5GHz boost... und da werden kommende spiele, auch eher nen strich durch die rechnung machen :cool:

maximus_hertus

2019-02-21, 11:51:29

rentex

2019-02-21, 11:58:19

10% hinter dem 9900K ist kein Beinbruch, wenn Verbrauch und Temps passen.

basix

2019-02-21, 12:05:10

WEIT vor intel mit 16 kernen, intel hat auf desktop nur 8 kerne als maximum, das andere sind schon die TR4 deviate aka sockel 2011-3 :wink:

Intel bereitet doch einen 10C für S1151 vor? Deswegen nehme ich das als potentielles Konkurrenzprodukt ;)

Wird TR3 direkt so hoch gehen? Hätte gedacht, dass es bei 4 Chiplets mit 32C bleibt.

Keine Ahnung ob max. 32C oder 48C. Wenn AMD aber 3/4 in (ist ja nicht all in ;D) gehen will sieht 48C vs. 18/28C ziemlich fett aus. Ausserdem hätte man eine "natürliche" Evolution verglichen mit Threadripper 2. Threadripper 4 kommt dann mit 64C und Server mit Zen 3 bietet max. 96C.

//differentRob

2019-02-21, 12:08:10

Es bleibt doch noch abzuwarten, ob Zen2 mit dem neuen 7nm Prozess auch in eine Taktwall donnert wie Zen(+). Sollte der neue Prozess keine harte Taktwall haben, dürfte Zen2 auch für OC mal wieder eine höchst interessante CPU werden. Zen(+) OC ist so spannend wie ein Sack Reis in China :rolleyes:

Stellt sich dann die Frage was besser gehen wird 8er / 12er :D

amdfanuwe

2019-02-21, 13:27:34

Mal grad die Preise gescheckt:
16C 2950X 849€
16C 1950X 559€
12C 2920X 608€
12C 1920X 388€

9900k >500€

Technisch spricht kein Grund gegen 16 Core AM4 und 64 Core TR.
Da könnte AMD Mondpreise für verlangen. Warum sollten sie sich das Geschäft entgehen lassen?
Und wenn der 8 Core mit dem 9900k mithalten kann, warum sollte man den für unter 300€ verkaufen?
Könnte mir durchaus vorstellen, dass AMD diesmal verdienen will.
Wird Preis/Leistung immer noch wesentlich besser als Intel sein und auch etwas besser als die Vorgängergeneration aber einen 9900k Killer für 150€ erwarte ich wirklich nicht.
Könnte mir durchaus folgende Preise vorstellen:
16C 600€
12C 400€
8C 300€
6C 200€
Wenn Konkurrenz aufkommt oder die alte Generation abverkauft ist, kann man immer noch Preise senken um das Geschäft etwas anzukurbeln.

Piefkee

2019-02-21, 13:44:33

Screemer

2019-02-21, 14:03:46

SKYNET

2019-02-21, 14:08:40

Man wird halt sehen müssen, ob das reicht. Wäre es wünschenwert? Ja klar. Aber irgendwie bin ich skeptisch. Am Ende landet Zen 2 rund 10% hnter dem 9900K bei der Gaming Performance und alle schreien rum wie schlecht AMD doch ist und unspielbar bzw. Spiele-"Schwäche". Das brennt sich in den Köpfen und es wird für AMD noch schwerer.

Für mich habe ich eh den Plan mir den 3700X (oder was da kommen wird) zu holen. Dank Drop-In Kompatibilität ist das ja auch sehr einfach :)

bei mir wirds wenn nen upgrade auf das max an kernen, klotzen, nicht kleckern ;D ausserdem will ich den CB15 faden nen wenig aufmischen :biggrin:

10% hinter dem 9900K ist kein Beinbruch, wenn Verbrauch und Temps passen.

wollt grad sagen, wenn das ding dann mit 65W angegeben ist, und real nur 90W brauch, ist das weit hinter nem 9900k :biggrin:

Es bleibt doch noch abzuwarten, ob Zen2 mit dem neuen 7nm Prozess auch in eine Taktwall donnert wie Zen(+). Sollte der neue Prozess keine harte Taktwall haben, dürfte Zen2 auch für OC mal wieder eine höchst interessante CPU werden. Zen(+) OC ist so spannend wie ein Sack Reis in China :rolleyes:

Stellt sich dann die Frage was besser gehen wird 8er / 12er :D

wer streute eigentlich das gerücht einer taktwall? O_o

wenn ich ausserhalb von 3DC/CB schaue(techpowerup, HWL usw.) sind da einige wo der 2700X mit jenseits der 4350MHz AC rennt bei +/- 1.4V, einige sogar 4400-4450... ist einfach von der chipgüte abhängig, und das die richtig guten die 4.4GHz schaffen überwiegend im 2950X landen, weil der einfach 1-2C boost auf 4.4GHz hat, scheint niemand zu sehen... behauptet ja auch niemand das nen 8700k ne taktwall bei 5.2GHz hat(geköpft) nur weil die meisten genau da "aufgeben" müssen mit normaler kühlung(luft/wasser).

Bitte nenn mir die Anzahl Menschen der einen 9900K kauft und dann in 1080p spielt? Die meisten wird 1440p oder 4K in dieser preisklasse interessieren. Der Vorsprung bei Games liegt mM zwischen 0-20% je nach Anwendung und Auflösung.

alle die mehrheitlich MP shooter zocken würde ich sagen, die haben nen 24" max 25" in FHD stehen...

HOT

2019-02-21, 15:20:28

Bitte nenn mir die Anzahl Menschen der einen 9900K kauft und dann in 1080p spielt? Die meisten wird 1440p oder 4K in dieser preisklasse interessieren. Der Vorsprung bei Games liegt mM zwischen 0-20% je nach Anwendung und Auflösung.
Das ist leider nicht richtig. Der riesengroße Löwenanteil spielt nach wie vor in FHD.
Ist ja auch nicht schlimm, gibt ja Downsampling.

Realitätscheck nicht bestanden :D

Für viele sind die Gaming Benchmarks entscheident und da sieht es aktuell nicht wirklich gut aus. Ein 9900K liegt 20-30% vor dem 2700X (manchmal sogar 40+%). Das muss man erstmal aufholen und einfach nur 16C werden dabei nicht helfen.

Erst wenn AMD durchgängig (in fast allen Games) vorne liegt müsste sich Intel überlegen, ob sie sich um den Dsktop Gedanken machen müssen.

Der Server Markt ist da naürlich anders, wobei die bisherige MArktdurchdringung von Epyc leider sehr bescheiden ist. Ich hoffe es komt der Durchbruch mit Rome.

1.) sind es maximal 20%, alles andere sind Einzelfälle, in denen die CPU-Leistung eh keine Rolle spielt und
2.) darf man hier die Powercheaterei der Mobo-Hersteller nicht außer Acht lassen. Die AMDs können zwar auch nicht höher takten, laufen aber auch nur mit ihrer TDP, nicht mit 180W im Extremfall.

So wie es aussieht dürfte wohl bereits Zen5 in der ersten Design-Phase sein.

Mal ne Roadmap wagen :D.

2019 -> Matisse Zen2 (Ryzen3)
2020 -> Vermeer Zen3 (echter Zen2 Refresh mit neuem Die) (Ryzen4)
2021/2 -> Zen4 (immernoch AM4 in 5nm) (Ryzen5)
2022/3 -> Zen4 (AM5, neues I/O, neuer Sockel, gleiches 5nm-Chiplet) (Ryzen6)
2023/4 -> Zen5 (AM5, gleiches I/O, 3GAAF) (Ryzen7)