AMD - Zen 3, 7 nm, 2020 (Vermeer, Cezanne, Genesis Peak & Milan) [Archiv] - Seite 3

Gipsel

2019-10-28, 15:25:06

Ich meine nicht physikalische Herstellungs-Layer sondern dass man Logik und Leiterbahnen auf unabhängige Schichten setzt wie es bei 3dnend schon der Fall ist. Bei CPUs sollte man noch die Leiterbahnen auf extra Layer machen damit die wie Brücken und Tunnel in einer Stadt viel zu lange Wege vermeiden!
Du meinst etwa so?
https://static.techspot.com/articles-info/1840/images/2019-05-06-image.png
Ganz unten im Bild sind die Transistoren, die Metal-Layer darüber stellen die Verbindungen zwischen den Transistoren her.

Oder hier mal mit ein wenig mehr räumlichem Eindruck:
https://i.pinimg.com/564x/15/1c/94/151c94ed1daba7873c81173afffe8114.jpg

Setsul

2019-10-28, 15:40:27

@HOT:
Ich habe doch extra geschrieben "Der CCX ist tot, es lebe der CCD."
Genau das meine ich ja mit der Fehlinterpretation. Wir sind uns ja einig dass das keine CCX mehr sind. Ich habe auch definitiv geschrieben, dass das irgendwann passieren wird.
Es ging mir damals um dieses "ach klebt einfach 2 Kerne mehr an den CCX, das geht schon". Das geht eben nicht.

Anscheinend nennt selbst AMD das was jetzt kommt nicht mehr CCX.
Also was ist das für eine starre Ansicht, die so nicht funktioniert?

@mboeller:
Im übertragenden Sinn.
Die Marke ist tot, der Sockel ist tot, also wer liest heute noch "S940" als "Opteron" oder umgekehrt? Im ersten Moment sicher verwirrend.
Ich meine wir sind hier im Zen Thread, da konnte ich mir das nicht verkneifen.

@Hammer des Thor:
Ich weiß echt nicht worauf du hinaus willst.
Gerade bei 3D-NAND sind die Schichten nicht unabhängig sondern alle identisch und durchkontaktiert.

Hier einfach mal ein Bild:
https://en.wikichip.org/w/images/4/41/intel_22nm_rules.png
Wo möchtest du jetzt Brücken und Tunnel einbauen?

EDIT:
@Gipsel:
Die Bilder sind natürlich noch besser.

S940

2019-10-28, 17:22:25

Ggf. ist beim L3 aber irgendwann die Lücke bezüglich Latenz zum L2 doch so groß, dass man dann doch in Richtung L4 geht.
Ich fände nen Ausbau nach unten interessanter, Stichwort L0 Caches ;)
Der µOp-Cache, den jetzt auch AMD einbaut, ist nichts anderes als ein L0-I-Cache. Deshalb konnte AMD auch den L1I auf 32kB verkleinern, weil der L0I verdoppelt wurde.

Der nächste Schritt wäre jetzt eigentlich ein L0-D-Cache. Mit SMT würde es richtig interessant werden, da ein L0-Cache per Definition klein genug wäre, um sich mehr davon leisten zu können. Z.B: für jeden Thread einen eigenen L0, oder bei SMT4 2 für je 2 Threads, etc. pp.

Forschungspapers gibts davon mehr als genügend, schon seit den 1990ern. Nur hats bisher noch keiner implementiert. Wird mal langsam Zeit ...

IMO ne spannendere Geschichte als langsamer, schnöder L4 :D

P.S: Nein ich bin nicht tot und finde Witze darüber - auch im "übertragenen Sinne" unangebracht.

Setsul

2019-10-28, 18:02:46

Das Problem ist die Latenz. Der Sinn mehrerer Levels ist ja die deutlich niedrigere Latenz bei deutlich kleineren Caches.
L1 ist eigentlich das Ende weil unter 3-5 Takten geht nichts mehr. Bei einem Takt nennt sich das Ding Register. L0I funktioniert weil µop-Caches und andere predecoded Caches (Qualcomm hatte doch auch mal einen) eben trotzdem ein paar Takte Latenz sparen, aber eben dadurch dass die Decode-Pipelinestufen wegfallen.

Was gibts für Papers zum L0D? Dank TLBs wird es da sehr schwierig noch etwas rauszuholen.
Man kann aber an sich natürlich an der Hierarchie was machen. Also ein L1I+L1D und unified L2 pro Kern sind ja kein Gesetz.

SMT4 ist natürlich wieder erst bei Zen4, aber ja, mehrere L1Ds sind natürlich denkbar. POWER9 hat auch je einen L1I und L1D pro SMT4 Kern bzw. Hälfte obwohl sich der gesamte SMT8 "Kern" einen L2 teilt.
Umgekehrt wäre auch für AVX512 denkbar anstatt nur den L2 zu vergrößern wie bei Intel und durch die Latenz bei allem anderen langsamer zu werden ein Level mehr einzuschieben. Also 32/256/2048 kB pro Kern und dann eben erst beim L4 mehrere Kerne dranhängen. Das ist natürlich auch noch Zukunftsmusik aber wenn man jetzt bei Zen4 oder 5 dann 16 Kerne oder so an einen einzigen L3 hängt könnte die Latenz wieder nicht so toll sein, sodass es Sinn ergibt die bei Intel bewährten 2 MB pro Kern mit ~30 Takten zu erhalten durch eine Ebene mehr und dafür eben mit einem kleineren, aber schnelleren L2 etwas zu kompensieren wenn der L1D vor lauter AVX512 überquillt.

Ich meinte wirklich nur die Marke, nicht dich persönlich. Opteron ist tot, es lebe Epyc und so.

Zossel

2019-10-28, 19:50:37

Der nächste Schritt wäre jetzt eigentlich ein L0-D-Cache. Mit SMT würde es richtig interessant werden, da ein L0-Cache per Definition klein genug wäre, um sich mehr davon leisten zu können. Z.B: für jeden Thread einen eigenen L0, oder bei SMT4 2 für je 2 Threads, etc. pp.

L0-D-Cache sind die CPU-Register, gibt es schon seit Jahrzehnten. "Registerlose" oder "Stackorientierte" Architekturen haben sich nicht durchgesetzt.

S940

2019-10-29, 01:00:34

L0-D-Cache sind die CPU-Register, gibt es schon seit Jahrzehnten.
Na ne, auf den Registern wird doch gerechnet. Caches sind per Definition Zwischenspeicher, die die Daten nur durchschleußen dabei aber schnell verfügbar machen.

Ein Paper gibts z.B. hier:
https://www.ics.uci.edu/~nlduong/pubs/cases2012.pdf

Zwar für low-power, aber die diskutieren auch frühere Ansätze für den high-perf. Einsatz.

Nur zur Größeneinordung: Wir reden hier maximal von 1 kB. In obigen Paper gehts nur um bis zu 256 Bytes.

Hammer des Thor

2019-10-29, 01:38:27

Du meinst etwa so?
https://static.techspot.com/articles-info/1840/images/2019-05-06-image.png
Ganz unten im Bild sind die Transistoren, die Metal-Layer darüber stellen die Verbindungen zwischen den Transistoren her.

Oder hier mal mit ein wenig mehr räumlichem Eindruck:
https://i.pinimg.com/564x/15/1c/94/151c94ed1daba7873c81173afffe8114.jpg

Achso, dann werden die Verbindungen schon über "Brücken" gebaut? Noch vor wenigen Jahren waren die Leiterbahnen extrem lang und haben die grössten Teil der Verlustleistung ausgemacht da sie um Transistoren auf einer Ebene gelegt werden mussten.

maguumo

2019-10-29, 02:21:28

Das war schon immer so. Selbst 10 µm MOSFET hatte zwei (?) Metal Layer als damit vor knapp einem halben Jahrhundert der Intel 4004 produziert wurde.

mboeller

2019-10-29, 07:02:41

Achso, dann werden die Verbindungen schon über "Brücken" gebaut? Noch vor wenigen Jahren waren die Leiterbahnen extrem lang und haben die grössten Teil der Verlustleistung ausgemacht da sie um Transistoren auf einer Ebene gelegt werden mussten.

verwechselst du das ganze mit den Leiterbahnen in Mainboards?

Bei Mainboards verlegte man die Leiterbahnen wirklich oft in einer Ebene.

https://de.wikipedia.org/wiki/Leiterbahn

Leiterplatten für sehr einfache Schaltungen können unter Umständen mit nur einer Leiterbahnebene auskommen, die beispielsweise auf einer Seite einer Leiterplatte aufgebracht und strukturiert wurden. Doch können die wenigsten Schaltungen so stark entflochten werden, dass sich bei nur einer Ebene keine Leiterbahnen kreuzen. Mit Ausnahme einiger Fertigungstricks, wie Überbrückungen einer Leiterbahn mithilfe eines Bauelements, ist daher mindestens eine weitere Ebene notwendig, beispielsweise zweiseitige Leiterplatten. Bei modernen, sehr komplexen Leiterplatten werden daher mehrlagige sogenannte Mehrebenen- bzw. Multilayer-Leiterplatten verwendet,

Zossel

2019-10-29, 07:47:53

verwechselst du das ganze mit den Leiterbahnen in Mainboards?

Bei Mainboards verlegte man die Leiterbahnen wirklich oft in einer Ebene.

Selbst solche Kisten aus der Steinzeit wie der Altair 8080 oder KIM-1 waren doppelseitig. Digitaltechnik lässt sich wesentlich schlechter entflechten als typischer Analogkram.

basix

2019-10-29, 17:17:31

Multi-Layer ist wirklich nichts neues.

Was mir aber trotzdem durch den Kopf geschossen ist: Transistoren sind nur auf der untersten Lage verbaut, richtig? Und die oberen Lagen sind dann die Metal Layer für deren Verdrahtung. Nun die Frage: Kann man die Transistoren nicht ebenfalls auf mehreren Lagen verteilen, z.B. 2-4? Das ergäbe bei gleichbleibender Strukturgrösse allenfalls einen guten Boost an Packdichte. Thermische Ableitung etc. sind sicher ein Problem und noch mehr Transistoren auf selbem Raum ebenfalls. Irgendwie ist "Transistor Stacking" aber dennoch ein reizvoller Gedanke. Das geht in Richtung "Monolithic 3D ICs" (https://en.wikipedia.org/wiki/Three-dimensional_integrated_circuit#Monolithic_3D_ICs)

Setsul

2019-10-29, 19:53:23

Bulk nicht wirklich. SOI definitiv nicht. FinFET wäre immernoch schwierig. Aber mit GAA/nanowires sollte es theoretisch möglich sein.

Nightspider

2019-10-29, 23:55:18

Sicher? Man braucht doch einen Silizium Einkristall für Transistoren usw. oder? Wie soll das mit GAA gehen? Damit sind die Transistoren nur bisschen höher aber du stapelst nicht mehrere Transistoren übereinander.

Falls man irgendwann Silizium in einem regelmäßigen Muster aufdampfen und das dann wieder dotieren könnte, dann könnten wirklich mehere Silizium-Layer incl. Schaltkreisen erzeugen. Würde dann aber arschteuer werden.

Eher könnte man vielleicht noch winzige Kondensatoren für Speicher in der dritten Dimension aufdampfen.

Ansonsten bleibt nur mehrere Silizium Chips zu stapeln und das ist schwieriger, weil du dann tausende TSVs brauchst, das Ganze löten musst usw.

Setsul

2019-10-30, 12:21:25

Naja so wie man stacked nanowires baut. Erstens muss es nicht Si sein, InGaAs usw. gibts ja auch, zweitens muss man kein regelmäßiges Muster aufdampfen. Man baut sich volle Schichten und ätzt dann wieder weg.
Es geht eher darum, dass die Gates in alle Richtungen abgeschlossen sein müssen, damit sie keine Verbindung zu den Metal Layers darunter bilden können.
Aber ein paar Verbindungen braucht man trotzdem und das wird auch sicher interessant. Normalerweise muss man an den unteren Schichten nicht mehr ran sondern baut immer nur oben drauf, aber dafür müsste man entweder nachträglich wieder Kontaktpunkte freiätzen oder das mehr oder weniger gleichzeitig mit den Gates machen. Sicherlich aufwendig.

Wohl kaum sinnvoll. Bestenfalls verdoppeln sich die Kosten wenn man alles verdoppelt, abgesehen vom Wafer, aber der ist außerhalb von SOI sowieso nicht so teuer. Transistorendichte ist aber eigentlich nicht das Problem. Metal Layers/Routing ist die größere Einschränkung, deshalb werden das ja immer mehr. Kleinere Transistoren wollen wir eigentlich hauptsächlich weil sie weniger Strom brauchen und da bringt Stacking ja nichts. Deshalb ist es wohl einfacher und sinnvoller einfach Dies/Wafer zu stacken. https://youtu.be/oIG9ztQw2Gc?t=1465

basix

2019-10-30, 17:54:41

Die hier http://www.monolithic3d.com/why-monolithic-3d.html re-usen irgendwas um SOI herum, um Transistoren zu stapeln. Glaube zwar nicht, dass die ein Produkt haben. Ist eher sowas wie ein Patent-Troll.

Der Hauptvorteil soll darin liegen, dass die Leitungslängen abnehmen. Das ist vorteilhaft, da Delay & Kapazität geringer wird und bei so kleinen Strukturen mit überproportionalen R-Anstieg in den Leiterbahnen wie heute der Leiterbahnwiderstand mit der verringerten Länge abnimmt. Geringerer Widerstand bedeutet geringeren Drive Strom und somit geringerer Energieverbrauch. Durch die verringerte Länge braucht es auch weniger Repeater ergo weniger Transistoren ergo man ist effizienter. Das ist alles ziemlich schlüssig. Ausserdem wird die Die Size im Idealfall fast linear verringert. Könnte also auch bezüglich Kosten vorteilhaft sein (abzüglich der höheren Komplexität und zusätzlichen Prozessschritte).

Im Idealfall kann man sich irgendwie sowas bauen:

Layer 1: CPU
Layer 2: Cache (gemeinsam genutzt von CPU und GPU)
Layer 3: Metal Layer 1
Layer 4: GPU
Layer 5: Nochmals Cache oder alternativ DRAM
Layer 6: Metal Layer 2
Layer 7: I/O
Layer 8-n: Metal Layer 3-n

Da die vertikale Distanz gering ist, könnte man Cache und allenfalls auch die Register deutlich näher an den Rechenwerken platzieren als beim heutigen "2D" Aufbau. Da Daten schubsen in heutigen Prozessordesigns der primäre Energieverbraucher ist, könnte sich das also stark lohnen. Das ganze geht dann auch stark in Richtung Processing In Memory, wo AMD schon ein paar mal was gezeigt (Konzepte). Vielleicht sehen wir das ja mit Zen 4 oder 5 :D

Eldoran

2019-11-01, 17:54:58

Im embedded Bereich gibt es eine Integration von Speicher in BEOL, allerdings habe ich schon länger nichts neues darüber gelesen und vor allem bezieht sich das immer auf kleine Chips mit wenig Energieverbrauch und unter relativ alten Fertigungstechnologien - wie bei embedded eben üblich.

Es ist ja auch nicht so, also ob da vertikal viel Platz wäre - da kommen einige Lagen für die ganze Leitungen hinzu. Man darf auch nicht vergessen, dass die unteren feinen Lagen linear sein müssen, also schon einfache zweidimensionale Leitungsführungen mehrere Lagen benötigen. So ein Beispiel mit Bild:
https://fuse.wikichip.org/news/641/iedm-2017-globalfoundries-7nm-process-cobalt-euv/4/

Eldoran

2019-11-01, 17:59:19

Echte 3D Stapeln gibt es glaube ich nur beim Flash.

Grabhopser

2019-11-02, 01:49:13

Mehrere Transistor-Layer bleiben wohl bis auf weiters Wunschträume (ausgenommen Wafer stacking etc.).
Die Gründe sind wie immer vielfältig, die beiden wichtigsten sind jedoch, dass die Si-Epitaxie wirklich gut nur auf Eiskristallen funktioniert, sowie die Tatsache, dass man im BEOL nicht mehr das thermische Budget hat, das man für neue Transistoren benötigen würde.

Tobalt

2019-11-02, 02:43:23

STTMRAM Integration in vias ist glaub ich relativ reif schon. allerdings verlangt die Benutzung davon sicher einige deutliche Änderungen in der Prozessor Architektur. deshalb kommt es zuerst bei kleinen embedded chips.
läuft das gut, werden die Ingenieure zu amd und Co abgeworben und machen dort neue Designs.

Zossel

2019-11-02, 16:26:57

wirklich gut nur auf Eiskristallen funktioniert

Da sind sicherlich Einkristalle gemeint?

Piefkee

2019-11-04, 12:02:12

https://twitter.com/TUM_APISAK/status/1191219613356310528

AMD Ryzen Threadripper 3970X 32-Core Processor ��✅

Sieht doch nach einen guten Lineup aus.
Wahrscheinlich wird das so aussehen:

3950X 16-Core --> AM4 (Dualchannel) Nov19
3960X 24-Core --> TRX40 (Quadchannel) Nov19
3970X 32-Core --> TRX40 (Quadchannel) Nov19
3980X 48-Core --> WRX80 (Octachannel) Q1 2020
3990X 64-Core --> WRX80 (Octachannel) Q1 2020

dildo4u

2019-11-04, 12:03:54

Der nutzt Zen 2.

BoMbY

2019-11-04, 14:36:08

Der Sockel heißt sTRX4:

https://pbs.twimg.com/media/EIhlE2sX0AAmwmb.jpg:large

https://videocardz.com/newz/trx40-motherboards-for-3rd-gen-threadripper-start-to-leak

Edit: Ach, die Namen waren wohl schon bekannt, sTRX4 und sWRX8 - war an mir vorbei gegangen:

https://www.gamersnexus.net/news-pc/3510-hw-news-threadripper-8-channel-4-channel-leaks

BoMbY

2019-11-04, 21:55:26

Zum Thema SMT4 gibt es noch eine Interessante aktuelle Aussage (https://www.techpowerup.com/review/1usmus-custom-power-plan-for-ryzen-3000-zen-2-processors/):

Just to clarify: the Windows scheduler is not SMT aware—only the Windows core-parking algorithm is SMT aware.

gravitationsfeld

2019-11-04, 22:07:44

Gibt's dazu ne Quelle ausser den Artikel? Halte ich fuer unglaubwuerdig.

Tesseract

2019-11-04, 23:42:52

klingt plausibel, der schudeuler von windows ist generell ziemlich dämlich.
ein beispiel: lässt man CB20 mit 8 threads auf einem 8C/16T laufen switcht der scheduler wie ein gestörter auf allen 16 virtuellen cores herum, pinnt man hingegen die 8 threads einfach auf 0, 2, 4,... geht die performance um fast 10% nach oben.

gravitationsfeld

2019-11-04, 23:53:35

Armaq

2019-11-05, 00:50:24

Plausibilitaet ist nicht genug. Da werden Dinge einfach behauptet. Ich will eine Quelle.

Ich kann mir es nicht vorstellen, dass Microsoft nach 15 Jahren Hyperthreading immer noch keine Aenderungen am Scheduler vorgenommen hat.
Das könnte doch eigentlich nur MS belegen, oder jemand testet es extensiv, sodass abstreiten nicht mehr möglich ist?

gravitationsfeld

2019-11-05, 01:31:38

Das ist mein Punkt. Das Internet behauptet immer viel.

robbitop

2019-11-05, 06:05:21

Hat zwar nichts mit SMT aber mit dem Scheduler zu tun. Beim Threadripper 2990WX (32 Cores, 2x Dies mit Memorycontrollern und 2x Dies ohne) ist die Performance unter Windows bis heute grottig. Unter Linux gab es seit Anfang an die Performance, die man von der CPU erwartete. Der Linuxscheduler scheint deutlich besser zu sein was Topologyawareness angeht und da scheint auch ein gewisser Automatismus dahinter zu stecken.

Bezüglich SMT. Die PCGH hatte zuletzt einen Test zum Einfluss von SMT gemacht. Beim 9900k und 3900X. In den meisten Spielen kostete SMT Performance (bei 8 bzw 12 Cores sind auch ohne SMT genug Threads verfügbar). War in etwa im 5-10% Bereich. Hat das nicht auch mit dem Scheduler zu tun? Es wäre doch nett, wenn er erstmal die Threads auf die Kerne legt, die „echt“ sind und wenn es darüber hinaus noch Bedarf gibt, dann die virtuellen belegt. Aber in der Praxis kann ich das Verhalten, das Tesseract beschreibt, bestätigen. Es wird fröhlich hin und her geswitcht. Zwischen allen Cores.

Armaq

2019-11-05, 08:46:31

Das ist mein Punkt. Das Internet behauptet immer viel.

Aber MS ist nicht bekannt dafür sowas zuzugeben.

AnnoDADDY

2019-11-05, 09:13:02

Also bei mir wird die Last zuerst auf die hauptkerne gelegt und dann auf die virtuellen. Zumindest laut taskmanager. Ich denke schon das Windows smt mitbekommt.

BoMbY

2019-11-05, 09:24:25

Das könnte nur ein dummer Workaround sein, dass immer zuerst jeder zweite Kern genutzt wird. Könnte man leicht testen wenn man SMT deaktiviert. Mache ich vielleicht heute Abend mal.

HOT

2019-11-05, 12:07:48

AFAIK priorisiert Windows nur die echten Kerne. Das ist deren ganzer SMT-Support :freak:.
MMn hat sich da im Grundsatz seit Vista genau gar nichts geändert, es gibt nur nen Haufen Modifikationen. Für echten SMT-Support usw. müssten die das komplett renovieren denke ich.

Tesseract

2019-11-05, 12:18:06

AFAIK priorisiert Windows nur die echten Kerne. Das ist deren ganzer SMT-Support :freak:

es gibt keine "echten" und "unechten" kerne. SMT ist wie eine kasse mit zwei schlangen. ein thread am core 0 ist genau so schnell wie einer am core 1 wenn der andere jeweils nicht belastet wird.

HOT

2019-11-05, 12:51:17

Aaaalter...
Windows priorisiert jeden zweiten Thread, sodass die Kerne zuerst mit nur einem Thread ausgelastet werden, das war mir auch klar lol. Darf man nicht mal etwas flapsig auftreten?

G3cko

2019-11-05, 13:12:14

Ich habe mich damals intensiv mit dem Sheduler beschäftigt. Der dürfte nach wie vor eine Katastrophe sein. Die Haswell-E CPUs konnten erstmals einzelne Kerne unabhängig in den Tiefschlaf versetzen was bei singlecorelast dazu führte das der Sheduler weiterhin wie bekloppt die Last von einen Kern zum nächsten schubste obwohl die Kerne noch schliefen. Die Kerne konnten also gar nicht so schnell aufwachen und hochtakten, sodass massiv die Singlecore-Leistung einbrach.

MS "löste" das Problem in dem man die Schlaffunktion unter win 10 deaktivierte.

Ich gehe nicht davon aus, dass der Sheduler überarbeitet wurde oder irgendeine verbesserte Priorisierung besitzt. Zukünftig kommen ja noch unterschiedlich starke Cores hinzu, neben SMT. Hatte Intel ab Broadwell-E nicht sowieso einen einzelnen etwas höhertaktenden Core. Glaube das funzt auch nicht ideal.

https://www.hardwareluxx.de/community/f11/singlecore-turboproblem-nicht-nur-beim-haswell-e-1042104-7.html#post24730409

robbitop

2019-11-05, 13:50:01

Interessanterweise ist der Scheduler augenscheinlich bei Linux wesentlich smarter. Und das bei einem open source OS.

gravitationsfeld

2019-11-05, 18:17:50

Linux ist bei so gut wie allem wesentlich schneller als Windows. Das ist nichts neues.

Aber woher kommt das "selbst bei einem open source OS"? Dir ist schon klar, dass 90% der Linux Chanelists von Intel, IBM etc. kommen?

HOT

2019-11-05, 19:07:41

Mich würd mal interessieren, warum der Windows-Scheduler das dämliche Gespringe der Threads andauernd macht, das ist ja total kontaproduktiv.

Wenn man dem auf den Grund geht kommt da bestimmt mal ein Grund raus, warum das Ende der 90er mal toll war oder sowas, würd mich jedenfalls nicht überraschen.

Complicated

2019-11-05, 19:26:49

Vor allem wenn man bedenkt, dass MS ja durchaus mit Windows für ARM z.B. schon bei dem Snapdragon 835 auch mit Big.Little Cores umgehen konnte. Villeicht ist das ein Hinweis darauf, dass es wirklich von grundauf neu gestrickt werden muss, wenn da bisher nichts portiert wurde in die x86-64 Welt von Microsoft.

CrazyIvan

2019-11-05, 20:36:34

Warum das bei MS so ist? Weil ihnen das schon immer am Ar... vorbei ging.
Gab da dieses schöne Buch "inside Intel" in den Neunzigern. Da wurde von Intel Ingenieuren berichtet, die MS mit Codebeispielen davon überzeugen wollten, dass Excel auf damals aktuellen Prozessoren bis zu 16x schneller laufen konnte. Die Antwort war, dass Performance egal sei und nur neue Features interessieren.

Zossel

2019-11-05, 22:31:02

Nakai

2019-11-05, 22:34:08

Interessanterweise ist der Scheduler augenscheinlich bei Linux wesentlich smarter. Und das bei einem open source OS.

Der Linux-Kernel hat die, mit Abstand, höchste Code-Qualität...und das mit OpenSource und ohne definiertem Entwicklungsprozess...kurz Entwicklungsanarchismus. Das geht auch nur weil die ganzen Maintainer und Contributors eine extrem hohe Kompetenz aufweisen.

Es ist schon schade, wie es sein kann, dass ein OpenSource-Projekt jegliche wirtschaftliche Entwicklungsarbeit einfach mal in die Schranken weist. Das wird auch die Zukunft sein: OpenSource.

r-or

2019-11-05, 22:38:26

MS wird schon wissen, warum sie keinen Bock haben am Kernel groß rumzubasteln. Man bedenke welche Auswirkungen das z.B. auf legacy Software haben kann.

Das ist ja auch der einzige Grund, warum Windows überhaupt noch im Enterprise Bereich eingesetzt wird: die Früchte von Jahrzehnten von lock-in ins MS ecosystem. Sobald sie die Kompatibilität brechen, werden alle diese Firmen überdenken, ob sie Windows noch brauchen.

Irgendwann wird es kommen, aber dann hat MS wahrscheinlich eine brauchbare Alternative: ihre eigene Linux distribution.

Deswegen sind Features die Kunden einfangen viel wichtiger als Performance: die wird schon. Im Laufe der Zeit. Oder einer neuen MS Office Version. Für Geld, natürlich

Setsul

2019-11-06, 00:06:04

Wenn ich mich richtig erinnere war das so eine Eigenart des Windows-Schedulers, dass er idle cores immer bevorzugt. Die Prioritätenliste wird durchgegangen und der erste Kern im Leerlauf genommen den die aktuell eingestellte Prozessoraffinität erlaubt. 1. ein am Anfang zugewiesener Kern (zählt hoch mit jedem neuen Thread damit nicht mehrere Threads eines Prozesses auf dem selben Kern landen), 2. vorheriger Kern, 3. jetziger Kern und 4. der freie Kern mit der höchsten Nummer. Wenn keiner frei ist dann die gleichen Prioritäten nochmal für alle Kerne, was natürlich mit Option 1 endet wenn nichts an der Affinität verändert wurde. Damit sollten einerseits möglichst viele Kerne genutzt werden aber andererseits ein Thread möglichst wenig wandern und auch wieder zurück zu einem Kern gehen von dem er verdrängt wurde sobald es geht. Load-Balancing entsteht da natürlich nur wenn ein Kern irgendwann fertig ist mit allen Threads die ihm zugewiesen wurden, nicht durch irgendwelche aktiven Bemühungen. Funktioniert aber an sich trotzdem, wenn alle Kerne ausgelastet sind wird die Arbeit ja nicht weniger dadurch dass man die gleiche Anzahl Threads auf jedem Kern hat und wenn ein Kern tatsächlich keine Arbeit mehr hat bekommt er mehr zugeteilt.
Probleme gibts dann wenn nur ein paar Kerne idle sind. Der aktuelle Kern ist per Definition nicht idle. Wenn also irgendein anderer Kern idle ist wird der Thread rübergeschoben. Jetzt ist der Kern aber per Definition auch nicht mehr idle. Also schieben wir auf den nächsten (falls frei) oder den ersten falls der frei ist oder jetzt alle Kerne beschäftigt sind. Aber damit beginnt das Problem von vorne. Wenn auf dem zweiten Kern in der Zwischenzeit nicht ein anderer Thread gelandet ist gehts von Kern 1 oder 3 wieder auf 2. Und so kann man ewig Ping Pong spielen.

Leonidas

2019-11-06, 04:39:11

Rembrandt

Gibt es zu diesem Codenamen außerhalb den Vermutungen eines YouTubers eine belastbare Grundlage?

Platos

2019-11-06, 09:46:40

Was für ein Prozess ist das auf den Bildern von Gipsel und setsul?

BoMbY

2019-11-06, 10:32:35

MS wird schon wissen, warum sie keinen Bock haben am Kernel groß rumzubasteln.

Das Hauptproblem bei Microsoft sind Millionen Zeilen Legacy Code an welche sich niemand mehr ran traut.

amdfanuwe

2019-11-06, 10:45:59

Das Hauptproblem bei Microsoft sind Millionen Zeilen Legacy Code an welche sich niemand mehr ran traut.
Handoptimiert von Bill Gates

Mortalvision

2019-11-06, 11:11:14

gestern meinen 3600X eingebaut: 4,4 GHz allcore macht er bei Last und 70C mit. Jedes MHz mehr bootet er zwar, stürzt in Games aber nach 5 min ab. Der Speicher läuft jetzt auf docp mit 3600-16-16-16-32. Auch da: das ist an der Grenze, weil das Asus Prime X470 nach spec nur bis 3433 MHz RAM OC anbietet.

Etwas mehr Schwuppdizität im Öffnen von Programmenim Gegensatz zum vorherigen 2600X@4,2ghz und RAM 16-16-16-3200 ist da. Sehr schön ist die massiv aufgebohrte IPC mit mehr L2 Cache. Surviving Mars Endgame hat jetzt 100fps, Stellaris Endgame ohne Ruckeln. Supreme Commander 40% mehr fps (nicht, dass man es bei nem Game von 2007 nötig hätte).

pipin

2019-11-06, 11:26:40

Gibt es zu diesem Codenamen außerhalb den Vermutungen eines YouTubers eine belastbare Grundlage?

Leider nicht. Das ganze basiert ja auch nur auf einem Linkedin-Eintrags eines AMD Mitarbeiters indem folgendes stand:

"5/6/7 nm technology for AMD Renoir, Rembrandt, Durango CCD projects"

https://twitter.com/blueisviolet/status/1188701042768171008

Birdman

2019-11-06, 11:55:56

Mich würd mal interessieren, warum der Windows-Scheduler das dämliche Gespringe der Threads andauernd macht, das ist ja total kontaproduktiv.
Der Grund dafür ist relativ simpel, es dient zum verhindern von Hotspots.

Grundsätzlich geht man halt mal davon aus, dass man eine Many-Core CPU hat auf der ein (1) Prozess/Thread mit 100% CPU läuft.
Wenn dieser immer auf dem gleichen Core drehen würde, dann kann es dazu kommen dass die CPU überhitzt und sich runtertakten muss. (oder die Turboclocks nicht halten kann)
Dementsprechend kann/wird die Performance im Endeffekt besser sein, wenn man diesen Tasks immer mal wieder auf einen anderen Core verschiebt.

Die Challenge ist nun aber, dies möglichst optimal zu machen, was je nach CPU Architektur und Applikation (mehrere Threads mit mehr oder weniger Load) halt nicht so einfach ist.
Vor ein paar Monaten hat Microsoft ja einen Scheduler Patch für Ryzen gebracht, welcher den Modus für die Core Auswahl beim Thread verschieben ändert.
Früher wurde hier afaik jeweils der Core priorisiert der physisch am weitesten weg war (positiv für die Hitzeverteilung und somit das Throtteling), neu wird der Core priorisiert der am nächsten liegt. (positiv für die Cache Assoziativität)
Schlussendlich hat beides Vor- und Nachteile und ich gehe davon aus dass die alte Methode für einen Grossteil von Applikationen von Vorteil war, aber bei Games halt negative Folgen hat.
Daher hat es AMD durch diesen Patch ändern lassen, da die Balken bei Spielen wichtiger sind.

BoMbY

2019-11-06, 12:48:42

Waren wir nicht kürzlich bei SRAM als Stapel auf der CPU?

CONFIGURATION OF MULTI-DIE MODULES WITH THROUGH-SILICON VIAS (http://www.freepatentsonline.com/20190332561.pdf)

DrumDub

2019-11-06, 13:10:48

HOT

2019-11-06, 13:24:59

Der Grund dafür ist relativ simpel, es dient zum verhindern von Hotspots.

[...]

Das kann schon sein, nur aktuell ist so ein Vorgehen halt nicht mehr. Ich find Setsuls Erklärung recht plausibel was die Funktionsweise angeht. Ist halt alles veraltete Vorgehensweise. Bei Zen2 ist der beste Core am besten immer ausgelastet. Auch das ganze Powermanagement und Cachemanagement kommt mit der Vorgehensweise ja nicht gut klar.
Das muss eben von anno dazumal sein, als Kerne noch per SMP über einen Bus liefen. Aber ich denke, M$ wird da jetzt auch nicht mehr drumherum kommen, da ja auch Intel mit seinem Meshing unbedingt hier eine Erneuerung des Schedulers braucht.
Oder man macht das "Windows on Linux" Konzept mal wahr, also ein Linux als technische Basis für ein Windows-System. Es gab ja derartige Spekulationen.

iuno

2019-11-06, 13:50:25

Zossel

2019-11-06, 18:40:07

Es ist schon schade, wie es sein kann, dass ein OpenSource-Projekt jegliche wirtschaftliche Entwicklungsarbeit einfach mal in die Schranken weist. Das wird auch die Zukunft sein: OpenSource.

Bei Opensource sieht jeder was das im Zweifelsfall für ein Scheiß ist.
Closedsource muß nur gerade gut genug für die Shareholder sein.

Berniyh

2019-11-06, 18:45:39

Der Linux-Kernel hat die, mit Abstand, höchste Code-Qualität...und das mit OpenSource und ohne definiertem Entwicklungsprozess...kurz Entwicklungsanarchismus. Das geht auch nur weil die ganzen Maintainer und Contributors eine extrem hohe Kompetenz aufweisen.
Der wesentliche Punkt dürfte da ein anderer sein:
Linux (insbesondere der Kernel) deckt schon seit langer Zeit ein riesiges Spektrum von Anwendungsmöglichkeiten ab und da gehören auch insbesondere Projekte wie Cluster und Supercomputer dazu.
Auf solchen Maschinen (egal ob es nun um die Monsterprojekte geht oder kleinere Instanzen) kann man sich einen ineffektiven Scheduler einfach nicht erlauben.
Linux kam daher schon sehr früh in den Zwang auf vielen Cores sehr gut zu funktionieren, eine Optimierung die Windows erst in den letzten Jahren wirklich aufgezwungen wurde.
Und nicht nur das, auch die Hersteller und Nutzer derartiger Maschinen können natürlich ihre Optimierungen dafür einbringen.

Weiterhin kommt noch dazu, dass unter Linux durch das Open Source Konzept relativ einfach ist Optimierungen durchzuführen bzw. ggf. auch neue Scheduler separat zu entwickeln und – wenn dann integriert – auch für das eigene System auszuwählen.
Beim CPU Scheduler war Linus Torvalds zwar immer sehr reserviert was Änderungen angeht, aber dennoch hat es auch hier schon viele interessante Entwicklungen gegeben. Die Hürde für einen echten Wechsel ist aber wesentlich höher als an anderen Stellen (wie z.B. dem IO Scheduler).

Berniyh

2019-11-06, 18:46:54

Oder man macht das "Windows on Linux" Konzept mal wahr, also ein Linux als technische Basis für ein Windows-System. Es gab ja derartige Spekulationen.
Nennt sich Wine. :P

Zossel

2019-11-06, 19:16:41

Hier hat jemand mal verschiedene Linux-Scheduler für verschiedene Spiele verglichen: https://www.youtube.com/watch?v=XDXMkN8m_FY

Leider steht nicht dabei welche Spiele das sind.

Andere interessante Vergleiche Windows vs. Linux(native|proton|DXVK|VLK) finden auch noch bei dem Youtube-User: https://www.youtube.com/channel/UCDmXLiZTBaFuCOXjy6mdw5w/videos

Berniyh

2019-11-06, 19:40:17

Hier hat jemand mal verschiedene Linux-Scheduler für verschiedene Spiele verglichen: https://www.youtube.com/watch?v=XDXMkN8m_FY

Leider steht nicht dabei welche Spiele das sind.
Assassin's Creed: Origins, Far Cry New Dawn und Tom Clancy's Ghost Recon Wildlands.
Siehe hier:
https://flightlessmango.com/benchmarks/XDXMkN8m_FY

Andere interessante Vergleiche Windows vs. Linux(native|proton|DXVK|VLK) finden auch noch bei dem Youtube-User: https://www.youtube.com/channel/UCDmXLiZTBaFuCOXjy6mdw5w/videos
Der User ist in dem Bereich Linux/Wine/Proton relativ bekannt (und auch nicht immer frei von Kritik).

Ich persönlich habe mit proton inzwischen eigentlich auch recht gute Erfahrungen gemacht.
Nicht jedes Spiel in meiner Steam Datenbank läuft, aber ein recht großer Teil. Meistens auch mit sehr guter bis fast nativer Performance.
Das Engagement von Valve im Linux Bereich zeigt so langsam richtig gute Ergebnisse.
Daher plane ich mittelfristig komplett auf Linux umzusteigen (Desktop läuft schon seit 12-13 Jahren auf Linux).
Bis dahin muss Windows 7 noch irgendwie auf dem Spiele PC durchhalten.

Zossel

2019-11-06, 19:47:19

Der User ist in dem Bereich Linux/Wine/Proton relativ bekannt (und auch nicht immer frei von Kritik).

Für mich sind das die ersten Benchmarks die entsprechende Vergleichen machen.

Berniyh

2019-11-06, 20:05:53

Für mich sind das die ersten Benchmarks die entsprechende Vergleichen machen.
Da gab es schon vorher welche, z.B. bei Phoronix.

Es ist aber ohnehin sehr vom Spiel abhängig, im Grunde muss man also seine eigenen Benchmarks durchführen. Gibt durchaus einige Spiele die sehr rumzicken, andere laufen dagegen quasi nativ.

In Bezug auf den Scheduler: da gibt es bei Phoronix sehr viele Benchmarks zu verschiedenen Schedulern.
Interessanterweise zu den oben verlinkten (CFS ist Standard, die anderen sind separater Entwicklung außerhalb des mainline trees) noch nicht.

x-force

2019-11-06, 20:50:07

"nativ" (aka windowsleistung) kann doch nicht das ziel sein, bei dem vergurkten kernel&scheduling von windows

Thunder99

2019-11-06, 21:17:44

Ist halt die Referenz da unter Linux es in der Regel langsamer läuft (oftmals aber wegen der Grafik/Treiber)

Berniyh

2019-11-06, 21:31:42

"nativ" (aka windowsleistung) kann doch nicht das ziel sein, bei dem vergurkten kernel&scheduling von windows
Bei Spielen ist ja meistens die Grafikkarte der limitierende Faktor, da ist man froh, wenn dort auf dem Weg (DX -> Vulkan) nicht noch viel an Leistung verloren geht. ;)
Schneller kommt aber tatsächlich auch vor, ist aber eher die Seltenheit.

Dedizierte Benchmarks Windows vs Linux im CPU Limit (also z.B. ältere Spiele bei 720p) habe ich bislang glaube ich noch nicht gesehen.
Aber das halte ich auch eher für akademisch, braucht doch eigentlich kein Mensch.

Viel Benchmarks mit statistischer Auswertung – wie das unter Windows inzwischen Standard ist – habe ich bislang auch noch nicht gesehen.
Liegt aber auch daran, dass hier teilweise noch die Tools fehlen.
Da werden aktuell aber die Grundlagen geschaffen (z.B. Vulkan Overlays).

Tools wie Fraps oder OBS sind aber definitiv Mangelware. Die Spielergemeinschaft unter Linux ist halt doch nur eine kleine Gruppe (bislang und auch mittelfristig).

Nakai

2019-11-06, 21:44:46

Dass "der Kernel" anarchistisch entwickelt wird ist voelliger Quatsch. Es kann schon jeder machen was er will, nur kommt das dann halt niemals in mainline und ist damit voellig irrelevant.
Ansonsten gibt es einen Konsens zu einem Prozess der klaren Regeln folgt und strikt hierarchisch aufgebaut ist.

Es gibt keinen Prozess. Punkt.
Wenn man das mit funktioneller Sicherheit (ISO26262, IEC61508) oder generelle Automotiv/Luft/Raumfahrt vergleicht ist das kein Prozess.
Und klar gibt es Maintainer die über ihre Funktion wachen und Quatsch nicht in den Mainline lassen. Das zeichnet einfach gute Entwickler aus.

Der ueberwiegende Grossteil der Arbeit an Linux ist bezahlte Arbeit, das ist auch ueberhaupt kein Gegensatz. Oder warum soll Linux keine "wirtschaftliche Entwicklungsarbeit" sein bzw. sich zu diesen abgrenzen?

Das habe ich nicht ausgeschlossen. Die Firmen brauchen das auch für ihre eigene Zwecke. In Zukunft werden viele ClosedSource-Projekte eingestampft oder auf OpenSource umgestellt, weil man das alleine nicht mehr packt.

iuno

2019-11-06, 22:57:54

Es gibt keinen Prozess. Punkt.
Du laberst Muell. Punkt.

Setsul

2019-11-07, 00:00:11

Open Source Development läuft einfach auf einer anderen Basis als "kommerzielle" Entwicklung. Wenn bei Microsoft ein Feature verlangt wird kommt das von oben, das wird gemacht so dass es funktioniert, idealerweise im Zeitplan/Budget bleibt und das wars dann. Eine Windows-Version muss zu der Zeit rauskommen und mit den Features die angekündigt wurden.

Bei Linux schreiben irgendwo auf der Welt irgendwelche Leute an irgendwelchen Features die von irgendwem gewünscht sind. Außer "es wäre schon das bei Version x.yz zu haben" und bei Security Patches gibts keinen festen Zeitplan. Es wird von anderen entschieden ob das wirklich gebraucht wird. Was zum Ende des merge window nicht fertig ist muss draußen bleiben. Was den Standards nicht genügt wird abgelehnt. Und ja da gibt es einen extrem hierarchischen Prozess. Am Ende muss alles von Linus Torvalds gemerged werden und der pulled nur von den top-level maintainers die er alle kennt und von denen er weiß, dass sie nur das auf die Liste setzen das seinen Standards genügt. Die wiederum machen das gleiche mit den Leuten in ihrem Fachgebiet und so weiter. Nichts Anarchie. Also man kann vielleicht so anarchisch wie man will entwickeln, aber im irgendwas in den mainline kernel zu bekommen muss man sich auf der untersten Ebene der Hierarchie einreihen.

Nakai

2019-11-07, 00:44:26

Du laberst Muell. Punkt.

Keine. Argumente. Next. Punkt.

Open Source Development läuft einfach auf einer anderen Basis als "kommerzielle" Entwicklung. Wenn bei Microsoft ein Feature verlangt wird kommt das von oben, das wird gemacht so dass es funktioniert, idealerweise im Zeitplan/Budget bleibt und das wars dann. Eine Windows-Version muss zu der Zeit rauskommen und mit den Features die angekündigt wurden.

Bei Linux schreiben irgendwo auf der Welt irgendwelche Leute an irgendwelchen Features die von irgendwem gewünscht sind. Außer "es wäre schon das bei Version x.yz zu haben" und bei Security Patches gibts keinen festen Zeitplan. Es wird von anderen entschieden ob das wirklich gebraucht wird. Was zum Ende des merge window nicht fertig ist muss draußen bleiben. Was den Standards nicht genügt wird abgelehnt. Und ja da gibt es einen extrem hierarchischen Prozess. Am Ende muss alles von Linus Torvalds gemerged werden und der pulled nur von den top-level maintainers die er alle kennt und von denen er weiß, dass sie nur das auf die Liste setzen das seinen Standards genügt. Die wiederum machen das gleiche mit den Leuten in ihrem Fachgebiet und so weiter. Nichts Anarchie. Also man kann vielleicht so anarchisch wie man will entwickeln, aber im irgendwas in den mainline kernel zu bekommen muss man sich auf der untersten Ebene der Hierarchie einreihen.

Der Entwicklunsgprozess hat sich im Laufe der Dekaden entwickelt. Nichts wurde vorgeschrieben, sondern es hat sich so ergeben. Ihr denkt das Linus Torvalds initial definiert hat, wie etwas gelebt wird? Ja, Strukturen die sich daraus ergeben, kann man als Prozess sehen. Der ist sogar schemenhaft niedergschrieben.

Ihr denkt wohl, das mein Entwicklungsanarchismus einen negativen Beigeschmack hat? Nein, im Gegenteil. Das ist der produktivste Weg ein "Produkt" zu entwickeln. Es müssen nur feste Strukturen entstehen. Viele OpenSource-Projekte scheitern schon daran und daraus kann man sogar Korrelationen ziehen.

aufkrawall

2019-11-07, 01:05:50

Windows ist traditionell zu doof für viele Threads. Das muss aber im Umkehrschluss nicht bedeuten, dass es unter Linux nicht auch Probleme bei Spielen geben kann. Hier gab es Probleme mit der Verteilung auf verschiedene CCX bei Ryzen:
https://www.gamingonlinux.com/articles/shadow-of-mordor-on-amd-ryzen-cpu-suffers-from-a-performance-hit-due-to-non-optimal-thread-scheduling.9741
Kann ein OS das überhaupt automatisiert garantiert optimal zuweisen?

Und kennt Linux die besten Kerne als solche, für optimale Thread-Verteilung für den Boost? Wenn nicht, funktioniert das vermutlich auch nicht besser als unter Windows.

Brillus

2019-11-07, 01:26:30

=Floi=

2019-11-07, 01:39:11

Kann ein OS das überhaupt automatisiert garantiert optimal zuweisen?

auch so ein thema, warum das nicht der chipsatztreiber machen kann oder ein extra sheduler. Bei der gpu macht auch der treiber die arbeit.
Win möchte so viel machen, aber schafft es nicht wirklich das optimal zu lösen.

Berniyh

2019-11-07, 07:05:27

Der Entwicklunsgprozess hat sich im Laufe der Dekaden entwickelt. Nichts wurde vorgeschrieben, sondern es hat sich so ergeben. Ihr denkt das Linus Torvalds initial definiert hat, wie etwas gelebt wird? Ja, Strukturen die sich daraus ergeben, kann man als Prozess sehen. Der ist sogar schemenhaft niedergschrieben.
Insbesondere ist es absolut falsch den Linux Kernel als allgemein gültiges Beispiel für Open Source zu verwenden.
Das Entwicklungsmodell des Kernels ist ein sehr spezifisches Modell für genau dieses Projekt.
Bei den meisten Open Source Projekten läuft das ganz anders.
Windows ist traditionell zu doof für viele Threads. Das muss aber im Umkehrschluss nicht bedeuten, dass es unter Linux nicht auch Probleme bei Spielen geben kann. Hier gab es Probleme mit der Verteilung auf verschiedene CCX bei Ryzen:
https://www.gamingonlinux.com/articles/shadow-of-mordor-on-amd-ryzen-cpu-suffers-from-a-performance-hit-due-to-non-optimal-thread-scheduling.9741
Selbstverständlich gibt es da Probleme.
Das wird auch bei weitem nicht das einzige Problem sein.
Für Spiele ist Linux bislang wirklich nicht optimiert, was auch nur logisch erscheint, denn die Anzahl der Spieler (oder auch nur Desktop Nutzer) ist im Vergleich anderer Nutzer (Server, IOT, Mobiltelefone etc.) sehr gering.
Kann ein OS das überhaupt automatisiert garantiert optimal zuweisen?
Ja, das ist schon möglich, erfordert aber schon tiefergehende Logik.
Und kennt Linux die besten Kerne als solche, für optimale Thread-Verteilung für den Boost? Wenn nicht, funktioniert das vermutlich auch nicht besser als unter Windows.
Das kann man doch alles im CPU Treiber bestimmen.
Muss ja letztendlich nur eine statistische Auswertung machen (das ginge auch automatisiert).

Generell ist es bei Linux so, dass viele der Optimierungen erst mit der Zeit kommen.
z.B. auch für die Compiler, um optimierte Software erstellen zu können.
Anfangs liegt die Priorität immer darauf erst mal einen stabilen Ist-Zustand herzustellen, später wird dann optimiert.
Gegenüber Windows dauert das tendenziell etwas länger, da es eben durch den Review- und Integrations-Prozess durch muss und das dauert geschätzt mindestens ein halbes Jahr, plus die Zeit die Distributionen brauchen um das in einem aktuellen Release unter zu bringen (zwischen 0 und 0.5 Jahren).
Je nachdem, wann die Änderungen erstellt wurden kann also vom Release ab auch gerne mal ein ganzes Jahr vergehen.

Für Gamer (die ja gerne immer nach den letzten 1-2 % in der Performance suchen und generell eher ungeduldig sind) ist das natürlich nicht unbedingt optimal.

Ganon

2019-11-07, 07:35:19

Kann ein OS das überhaupt automatisiert garantiert optimal zuweisen?

Nicht unbedingt. Es kommt auch darauf an von wie vielen Threads man nun redet und wie hoch der Synchronisierungsaufwand zwischen ihnen ist. Keine Ahnung mit wie vielen Threads das Spiel dort arbeitet.

Wenn du einen hohen Synchronisierungsaufwand hast und mehr Threads startest als ein CCX bei AMD verarbeiten kann, dann ist das verdammt schlecht. Kommunikation zwischen den CCX ist lahm. Da kann der Scheduler nicht wirklich viel gegen machen. Er hat weder den Speicher noch die Zeit einen solchen Fall zu untersuchen und einfach Threads _nicht_ auf noch vorhandene und freie Kerne zu packen.

Wenn du einen hohen Synchronisierungsaufwand und weniger Threads startest, als ein CCX verarbeiten kann, dann sollte der Scheduler es in einem CCX belassen. Das war vermutlich 2017 noch nicht sonderlich gut im Kern umgesetzt.

Wenn du einen geringen Synchronisierungsaufwand hast, dann ist es normalerweise vollkommen egal. Das ist bei "normaler" Multithreading Software wie Bild- Videoverarbeitung und Rendering der Fall.

Der PS3-Emulator RPCS3 startet z.B. auf Ryzen-CPUs auch nicht mehr für jede SPU einen Thread und bindet diese manuell auf einen CCX. Im Normalfall würde er sonst für jede SPU (8 Stück) und die PPU einen Thread starten und ständig synchronisieren. Auch wenn dabei theoretisch Rechenleistung flöten geht, weil Kerne nicht genutzt werden, ist der Overhead der Synchronisierung schlimmer. Aber ein Emulator ist hier auch ein sehr extremes Bespiel.

Darum wünschen sich auch viele, dass AMD mehr Kerne pro CCX verbaut.

iuno

2019-11-07, 10:27:34

Keine. Argumente. Next. Punkt.
Kommen von dir ja auch nicht. Du hast meine ernsthafte Frage auch nicht beantwortet.

Ja, Strukturen die sich daraus ergeben, kann man als Prozess sehen. Der ist sogar schemenhaft niedergschrieben.
Also sind wir uns ja einig, was willst du dann noch fuer Argumente?

Ihr denkt das Linus Torvalds initial definiert hat, wie etwas gelebt wird?
Nein, natuerlich war es so nicht. Das heisst aber nicht, dass es heute keinen Prozess gibt. Und da du es offenbar besser weisst, verstehe ich die verqueren Aussagen nicht.

aufkrawall

2019-11-07, 12:39:08

Für Spiele ist Linux bislang wirklich nicht optimiert, was auch nur logisch erscheint, denn die Anzahl der Spieler (oder auch nur Desktop Nutzer) ist im Vergleich anderer Nutzer (Server, IOT, Mobiltelefone etc.) sehr gering.

Da muss aber offenkundig auch nicht extra so wahnsinnig viel optimiert werden, wie man etwa am SotTR-Port sieht. Wobei hier die Skalierung mit 6C/8C Ryzen vs. Windows interessant wäre.

Generell ist es bei Linux so, dass viele der Optimierungen erst mit der Zeit kommen.

Das scheint mir eher ein AMD-Problem zu sein. Mit ihrem Takt-Governor für Zen sind sie ja jüngst mal wieder auf die Nase gefallen, während bei Intel häufig vieles Monate vorher fertig ist.

Wenn du einen hohen Synchronisierungsaufwand und weniger Threads startest, als ein CCX verarbeiten kann, dann sollte der Scheduler es in einem CCX belassen. Das war vermutlich 2017 noch nicht sonderlich gut im Kern umgesetzt.

Die Frage ist, ob das heute besser ist.
Wenigstens gab es für RadeonSI eine Verbesserung, die evtl. auch Mordor hilft:
https://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-GLThread-Zen-Land
Wo wir wieder da wären, dass der Userspace es selbst auf die Reihe bekommen muss.

Ganon

2019-11-07, 13:33:06

Die Frage ist, ob das heute besser ist.
Wenigstens gab es für RadeonSI eine Verbesserung, die evtl. auch Mordor hilft:
https://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-GLThread-Zen-Land
Wo wir wieder da wären, dass der Userspace es selbst auf die Reihe bekommen muss.

Mir war so als gab es diverse Patchsets die das Scheduling-Verhalten hier verbessert haben. Aber ich denke ein manuelles (externes) festlegen der Threads auf einen CCX dürfte immer noch das schnellste Ergebnis bringen. Dass die Anwendungen und Spiele jetzt alle Ryzen spezifische Thread-Optimierungen erhalten halte ich eher für unwahrscheinlich. Generell ist es aber auch kein Hexenwerk von der Anwendung heraus Threads an die Cores festzunageln.

Linux selbst schiebt aber Threads sowieso nicht so arg umher.

gravitationsfeld

2019-11-07, 18:59:25

Das scheint mir eher ein AMD-Problem zu sein. Mit ihrem Takt-Governor für Zen sind sie ja jüngst mal wieder auf die Nase gefallen, während bei Intel häufig vieles Monate vorher fertig ist.
Hilft halt auch, wenn man seit Jahren immer wieder nur die gleiche Architektur in 14nm++++ unterstuetzen muss.

Berniyh

2019-11-07, 19:52:10

Da muss aber offenkundig auch nicht extra so wahnsinnig viel optimiert werden, wie man etwa am SotTR-Port sieht. Wobei hier die Skalierung mit 6C/8C Ryzen vs. Windows interessant wäre.
Den Teil hatte ich eher auf das gesamte System bezogen. Das war jetzt auch nicht AMD-spezifisch gemeint, sondern einfach generell auf Linux bezogen.
Das scheint mir eher ein AMD-Problem zu sein. Mit ihrem Takt-Governor für Zen sind sie ja jüngst mal wieder auf die Nase gefallen, während bei Intel häufig vieles Monate vorher fertig ist.
Das mag sein.

Ein Teil des Problems ist, dass AMD vor einigen Jahren – als die Kohle knapp war – einen Teil des (CPU) Kernel Teams gefeuert hatte.
Deshalb und, da man beim GPU Treiber immer noch ein bisschen im Backlog hängt, schafft man es nicht so stark vorzuarbeiten.
Aber so langsam bessert sich das. Die Performance ist gut, der Support für neue Produkte ist teilweise schon zu Release oder vorher zumindest rudimentär vorhanden und featuremäßig schließt man langsam zum closed source Treiber auf.
Da hat sich schon verdammt viel getan in den letzten Jahren.
Aber dennoch liegt da noch ein ziemlich großer Berg von Arbeit vor AMD.

aufkrawall

2019-11-07, 20:56:34

Den Teil hatte ich eher auf das gesamte System bezogen. Das war jetzt auch nicht AMD-spezifisch gemeint, sondern einfach generell auf Linux bezogen.

Ist mir schon klar. Trotzdem braucht Linux nicht weitere Optimierungen, um mit Windows bei der Spiele-Performance mithalten zu können.
Man kann das nur schlecht vergleichen, weil es kaum native Linux-Spiele ohne großartige Abstraktion Abstrahierung gibt. Eine der wenigen Ausnahmen ist Serious Sam: Fusion, und das läuft im CPU-Limit unter Linux schneller als unter Windows. Zudem klatscht in dem Spiel radv-aco auch den Vulkan-Treiber von AMD selbst an die Wand. ;D

Berniyh

2019-11-07, 20:59:18

Dass amdvlk nun nicht sooo der Bringer ist ist jetzt nicht wirklich eine Neuigkeit. :p

danarcho

2019-11-07, 22:14:02

@aufkrawall meinst du gegen windows bzw amdgpu-pro?

aufkrawall

2019-11-07, 22:32:21

@aufkrawall meinst du gegen windows bzw amdgpu-pro?
Afair gegen alle amdvlks. Aber auch mit Nvidia war unter Linux in dem Spiel die CPU-Performance besser als unter Windows.

Berniyh

2019-11-07, 22:51:49

amdgpu-pro ist letztendlich amdvlk (ob exakt in der veröffentlichten Version sei mal dahin gestellt).

gravitationsfeld

2019-11-07, 23:11:06

amdgpu-pro benutzt den AMD closed source shader compiler, amdvlk nicht.

Leonidas

2019-11-08, 06:20:39

Leider nicht. Das ganze basiert ja auch nur auf einem Linkedin-Eintrags eines AMD Mitarbeiters indem folgendes stand:
"5/6/7 nm technology for AMD Renoir, Rembrandt, Durango CCD projects"
https://twitter.com/blueisviolet/status/1188701042768171008

Danke für die Klarstellung. Leider ist damit nicht klar, für was "Rembrandt" steht ... natürlich kann es die Zen-3-APU sein, aber auch vieles andere.

Berniyh

2019-11-08, 07:26:44

Danke für die Klarstellung. Leider ist damit nicht klar, für was "Rembrandt" steht ... natürlich kann es die Zen-3-APU sein, aber auch vieles andere.
Das dürfte vermutlich die Zen 3 APU sein, Ryzen 4000 ist ja Vermeer.

Ich persönlich würde mich an "Durango" mehr stören. Da wüsste ich jetzt nicht wofür das stehen könnte.
Threadripper 5000 könnte sein, da sich sicherlich irgendwo ein Hügel mit dem Namen Durango findet, aber vermutlich ist es einfach irgendein Custom Project.

HOT

2019-11-08, 08:20:37

MadPenguin

2019-11-08, 08:39:57

Das ist keine Zen3-APU. Die würd ja in der Liste hier auftauchen:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-4-november-2019
tut sie aber nicht. Daher wird die das Schicksal von Picasso teilen, also Renoir refreshen. Eine Zen3-APU gibts sicherlich auch, aber erst Anfang 22.
MMn refresht AMD sowieso alle RDNA1-Chips und APUs noch mal in 6nm. Nur alle RDNA1.5 und Zen3-Geschichten werden 7nm+ mMn. Die nächste denkbare Iteration wäre dann ja sowieso nicht vor 5nm Pro, also irgendwann in 22 denkbar bei GPUs.

Kurze Frage, weil ich zwischen Codenamen der einzelnen CPUs oder/und APUs nicht mehr wirklich durchblicke. AMD hat für Anfang 2020 mobile 7nm APUs angekündigt, richtig? Also ein ZEN2? Zen2 mit welcher Technologiestufe bei iGPU? Weiß man das schon?

HOT

2019-11-08, 08:51:34

Vega. GFX909 nach Liste, also klare Sache.

MadPenguin

2019-11-08, 08:58:49

Vega. GFX909 nach Liste, also klare Sache.

Danke! Dann heißt es warten auf Q1/2020. :)

BoMbY

2019-11-08, 18:02:06

hmmm

https://i.imgur.com/PUAcnz4.jpg

https://i.imgur.com/2HmZosT.png

https://twitter.com/I_Leak_VN/status/1192823870799204352

Edit: bzw.

https://i.imgur.com/MJvZlm6.jpg

https://twitter.com/VideoCardz/status/1192846584062660608

SKYNET

2019-11-08, 21:23:13

HBM2 monster?

https://twitter.com/VideoCardz/status/1192848545247891456

DozerDave

2019-11-11, 16:22:29

... Ein Teil des Problems ist, dass AMD vor einigen Jahren – als die Kohle knapp war – einen Teil des (CPU) Kernel Teams gefeuert hatte.
Deshalb und, da man beim GPU Treiber immer noch ein bisschen im Backlog hängt, schafft man es nicht so stark vorzuarbeiten.
Aber so langsam bessert sich das. ...
Aber dennoch liegt da noch ein ziemlich großer Berg von Arbeit vor AMD.

Was ist das denn für eine Aussage? Du kannst nirgendwo im Backlog hängen. Deine Aussage klingt danach, dass Du einen Projektplan abarbeitest. Ein Backlog muss sich jederzeit verändern können!!!
Betrachte es mal aus der Perspektive: Keine Items im Backlog = Produkt tot.
Somit wirst Du nie Dein Backlog abarbeiten.

Complicated

2019-11-11, 17:33:02

Auch eine seltsame Idee die Fertigung der GPU zu verzögern weil der Treiber! Noch nicht fertig ist ^^

Berniyh

2019-11-11, 18:04:13

Was ist das denn für eine Aussage? Du kannst nirgendwo im Backlog hängen. Deine Aussage klingt danach, dass Du einen Projektplan abarbeitest. Ein Backlog muss sich jederzeit verändern können!!!
Betrachte es mal aus der Perspektive: Keine Items im Backlog = Produkt tot.
Somit wirst Du nie Dein Backlog abarbeiten.
Ach herrje, du hast Probleme. Dass sich Menschen immer an so Nebensächlichkeiten aufhängen müssen …

Letztendlich war das einzig und alleine auf die Tatsache bezogen, dass die Open Source Treiber unter Linux etwas hinterher hinken, d.h. dass neue Produkte nicht zwingend schon bei Release unterstützt werden (früher war das der Normalfall).
Dazu kommen noch fehlende Features (z.B. OpenCL oder Freesync), welche jetzt nach und nach kommen, aber eben Jahre nach der ursprünglichen Einführung.
Das kannst du jetzt als Backlog oder anders bezeichnen, ist mir eigentlich egal.

Bei den Closed Source Treibern sieht das im Normalfall anders aus, so langsam nähern sich die Open Source Treiber aber dem an.

Genau aus dem Grund können wir ja inzwischen auch hier und da aus den Treibern auf noch nicht veröffentlichte Produkte schließen.
Das wäre vor 3-4 Jahren noch undenkbar gewesen.

Brillus

2019-11-11, 18:28:38

Genau aus dem Grund können wir ja inzwischen auch hier und da aus den Treibern auf noch nicht veröffentlichte Produkte schließen.
Das wäre vor 3-4 Jahren noch undenkbar gewesen.
Was auch der Grund ist das die Treiber für neue dgpus so spät kommen gerade topdogs, die Marketingabteilung hat da ein veto.

CrazyIvan

2019-11-11, 18:50:28

Berniyh

2019-11-11, 19:18:50

Was auch der Grund ist das die Treiber für neue dgpus so spät kommen gerade topdogs, die Marketingabteilung hat da ein veto.
Das bezweifle ich.

In den Treibern gibt es eh wenig Code-Branches für die unterschiedlichen GPUs und wenn, dann ist es eher generisch.
Wirklich viel Rückschlüsse kann man da nicht ziehen.
Die wirklich interessanten – HW-spezifischen – Dinge sind in den Firmware Dateien implementiert und die haben wir ja nur in Binärform, auch unter Linux.
Die Firmware wird zudem auch immer erst recht kurz vor Release freigegeben, die muss ja nicht durch den Reviewprozess.

Brillus

2019-11-11, 19:37:01

Das bezweifle ich.

In den Treibern gibt es eh wenig Code-Branches für die unterschiedlichen GPUs und wenn, dann ist es eher generisch.
Wirklich viel Rückschlüsse kann man da nicht ziehen.
Die wirklich interessanten – HW-spezifischen – Dinge sind in den Firmware Dateien implementiert und die haben wir ja nur in Binärform, auch unter Linux.
Die Firmware wird zudem auch immer erst recht kurz vor Release freigegeben, die muss ja nicht durch den Reviewprozess.

Die Info kam von AMD Mitarbeiter (Birdman Phoronix-Forum).

DozerDave

2019-11-11, 19:44:35

LOL!
Backlog wird zu deutsch grundsätzlich als Rückstand übersetzt. Nicht die ganze Welt besteht aus SCRUM. Oder darf man einen 100 Meter Lauf jetzt auch nicht mehr als "Sprint" bezeichnen?

🤣
Rückstand wie treffend.
(Achtung kann Spuren von Sarkasmus beinhalten) <- Einen dank für die Korrektur geht an @CrazyIvan ;)

Sprint ist ohne Zweifel der schlechteste Begriff überhaupt. Aber zurück zum Thema: Zen 3.

Berniyh

2019-11-11, 19:46:52

Du meinst Bridgman, oder?

Dennoch kann ich mir das nicht so richtig vorstellen, denn es gibt eigentlich keinen wirklichen Grund dafür.
Hast du einen Link dazu? Würde mir gerne mal anschauen was genau er da geschrieben hat.

CrazyIvan

2019-11-11, 20:38:25

???
https://dict.leo.org/german-english/backlog

Und vielleicht solltest Du bei Gelegenheit gleich mal noch die Bedeutung von Ironie nachschlagen.

��
Rückstand wie treffend.
(Achtung kann Spuren von Ironie beinhalten)

Sprint ist ohne Zweifel der schlechteste Begriff überhaupt. Aber zurück zum Thema: Zen 3.

DozerDave

2019-11-11, 21:49:04

Ach herrje, du hast Probleme. Dass sich Menschen immer an so Nebensächlichkeiten aufhängen müssen …

Letztendlich war das einzig und alleine auf die Tatsache bezogen, dass die Open Source Treiber unter Linux etwas hinterher hinken, d.h. dass neue Produkte nicht zwingend schon bei Release unterstützt werden (früher war das der Normalfall).
Dazu kommen noch fehlende Features (z.B. OpenCL oder Freesync), welche jetzt nach und nach kommen, aber eben Jahre nach der ursprünglichen Einführung.
Das kannst du jetzt als Backlog oder anders bezeichnen, ist mir eigentlich egal.

Bei den Closed Source Treibern sieht das im Normalfall anders aus, so langsam nähern sich die Open Source Treiber aber dem an.

Genau aus dem Grund können wir ja inzwischen auch hier und da aus den Treibern auf noch nicht veröffentlichte Produkte schließen.
Das wäre vor 3-4 Jahren noch undenkbar gewesen.

Danke 😊 mir geht es gut. Und wie geht es Dir?
Das Vorgehen bei AMD zeigt doch gerade, dass Sie Backlog richtig verstehen und nicht irgendeinen Plan von anno dazumal umsetzten.
Immer an den Bedürfnissen der Konsumenten ausrichteten ist doch top! Die Frage ist doch jetzt nur was für Verbesserungen mit jeder Generation kommen wird.

CrazyIvan

2019-11-12, 06:20:22

Nunja, auf der APU Seite lassen sie sich für meinen Geschmack leider ein wenig zu viel Zeit. Liegt aber vor allem daran, dass ich dringend ein neues Notebook brauche und so kurz vor Renoir nicht noch Intel kaufen möchte.
Schade, dass der Chiplet Ansatz anscheinend nicht für Mobile taugt. Die damit verbundene Flexibilität hätte es ermöglicht, die Kadenz wieder an Desktop anzugleichen. Aber vielleicht überrascht man uns ja dann bei Zen 3 ;)

DozerDave

2019-11-12, 08:37:11

Naja wenn die GPU Entwicklung sich beschleunigt und die CPU-Entwicklung einmal verzögern sollte, kann es ja sein, dass wir eines Tages in den APUs den letzten CPU Teil haben und die neuste GPU.
Renoir wird ja auf Zen 2 + Vega basieren. Navi wäre interessanter.

Aber mal sehen, ob das/ die GPU Team/s zum CPU Entwicklungszyklus aufschließen können.

reaperrr

2019-11-18, 16:18:01

https://realmoney.thestreet.com/investing/technology/amd-inks-new-server-cpu-deals-15170073

Auszug:
Norrod also had some interesting comments about the performance gains that will be delivered by AMD's third-gen Epyc CPUs, which are codenamed Milan and expected to enter production around Q3 2020.

When asked about what kind of performance gain Milan's CPU core microarchitecture, which is known as Zen 3, will deliver relative to the Zen 2 microarchitecture that Rome relies on in terms of instructions processed per CPU clock cycle (IPC), Norrod observed that -- unlike Zen 2, which was more of an evolution of the Zen microarchitecture that powers first-gen Epyc CPUs -- Zen 3 will be based on a completely new architecture.

Norrod did qualify his remarks by pointing out that Zen 2 delivered a bigger IPC gain than what's normal for an evolutionary upgrade -- AMD has said it's about 15% on average -- since it implemented some ideas that AMD originally had for Zen but had to leave on the cutting board. However, he also asserted that Zen 3 will deliver performance gains "right in line with what you would expect from an entirely new architecture."

Damit ist ein zweistelliger IPC-Anstieg nicht nur möglich, sondern sogar wahrscheinlich.

w0mbat

2019-11-18, 16:29:16

Vor allem höher als die +15% IPC von Zen2. Ich sehs schon kommen: Zen3 +30% IPC auf Zen2 und 5GHz all-core dank 7nm+ :D

Ich warte schon auf den Ryzen 5 4600 :ugly:

Kehaar

2019-11-18, 16:38:01

https://realmoney.thestreet.com/investing/technology/amd-inks-new-server-cpu-deals-15170073

Auszug:

Damit ist ein zweistelliger IPC-Anstieg nicht nur möglich, sondern sogar wahrscheinlich.

Vor allem höher als die +15% IPC von Zen2. Ich sehs schon kommen: Zen3 +30% IPC auf Zen2 und 5GHz all-core dank 7nm+ :D
Wenn das auch nur teilweise wahr werden sollte, dann frag ich mich, was Intel zuletzt so gemacht hat X-D

w0mbat

2019-11-18, 16:44:40

Versucht bei 5G Modems Fuß zu fassen, eigene diskrete GPUs zu bauen, 10nm zum laufen zu bringen und sich auf der Skylake Architektur von 2015 ausruhen :D

Kehaar

2019-11-18, 16:55:08

War mehr eine rhetorische Frage. Insbesondere da zuletzt meist der Standpunkt vertreten wurde, dass die Zeit von größeren Leistungssteigerungen (insbesondere IPC) vorbei wäre. Und jetzt zeigt das kleine AMD, das evtl. doch noch was geht.

Setsul

2019-11-18, 17:14:39

Langsam, da steht weder dass der Unterschied von Zen2 zu Zen3 größer sein wird als von Zen1 zu Zen2 noch dass das alles IPC ist.

Berniyh

2019-11-18, 17:52:40

"completely new architecture" bezieht sich doch vermutlich darauf, dass das CCX/CCD umgebaut wird auf 8C CCD als kleinste Einheit?

Aber ist schon interessant, was AM4 so an Entwicklung durch gemacht hat.

Würde dann gerne mal Benchmarkvergleiche sehen kleinste CPU auf der Plattform vs. größte CPU auf der Plattform und das für AM3 und AM4.
Ich glaube die Spreizung bei AM4 dürfte deutlich größer sein mit den kleinen APUs vs. den 16C Vermeer.

Ravenhearth

2019-11-18, 18:05:16

Langsam, da steht weder dass der Unterschied von Zen2 zu Zen3 größer sein wird als von Zen1 zu Zen2 noch dass das alles IPC ist.
Doch, schon. Da Zen 3 performance gains "right in line with what you would expect from an entirely new architecture." liefern soll, und das dem eher evolutionären Schritt von Zen 2 entgegen gestellt wird, wird schon stark impliziert dass der Schritt zu Zen 3 größer ausfällt als der zu Zen 2. Außerdem gehts in dem ganzen Absatz um die Architektur und IPC, die dürfte daher auch hier gemeint sein.

Vor allem höher als die +15% IPC von Zen2. Ich sehs schon kommen: Zen3 +30% IPC auf Zen2 und 5GHz all-core dank 7nm+ :D
Das finde ich ehrlich gesagt etwas zu optimistisch, aber bis zu 20% mehr IPC halte ich nach diesen Aussagen für möglich. Beim Takt natürlich auch mehr, allerdings nur ein paar Hundert MHz, vielleicht so 10%.

Ich warte schon auf den Ryzen 5 4600 :ugly:
Ja, ich plane derzeit meinen Ryzen 5 2600 bis 2021 zu behalten und wenn Ryzen 5000 für AM5 rauskommt günstig einen Ryzen 4600 oder 4700X auf mein B450-Board zu schnallen. :D

Linmoum

2019-11-18, 18:16:21

Das, was der 3950X jetzt mit TR 2000 macht, macht der 12C Zen 3 im nächsten Jahr mit dem 3950X.;)

Aber beeindruckend, wenn sie sie da ein Performanceplus von >=20% ggü. Zen2 schaffen sollten. Scheint mir nach der Aussage allerdings mehr als realistisch. Wobei ja der Wegfall der CCX und das 8C CCD als Ganzes alleine schon einiges bringen dürfte.

Tesseract

2019-11-18, 18:29:35

lest das ganze doch im kontext: wenn er direkt nach der aussage zen 3 sei eine komplett neue architektur gleich mal lang und breit erklärt, dass zen 2 für eine evolutionstufe ungewöhnlich viel zugelegt hat und was die gründe dafür sind ist das ein starkes indiz dafür, dass der sprung von 2 auf 3 eben nicht größer sein wird und man sich deswegen absichern will. "what you would expect from an entirely new architecture" bedeutet wahrscheinlich ~10-15% wie man sie bei den intel-tocks in den letzten generationen gesehen hat.

Ravenhearth

2019-11-18, 18:33:04

Nö. Er sagt zwar, dass Zen 2 für eine Evolution ungewöhnlich viel gebracht hat, aber es war halt trotzdem nur eine Evolution. Zen 3 wird dagegen "an entirely new architecture", was eindeutig einen größeren Sprung beinhaltet.

Linmoum

2019-11-18, 18:34:50

Ravenhearth

2019-11-18, 18:36:17

Und 10-15% ist sicherlich auch nicht das, was man von einer komplett neuen Architektur erwartet. Weder bei CPUs, noch GPUs, noch sonstwo. Rund 10% hat ja schon Zen+ alleine als simpler Refresh gebracht.
Letzteres war allerdings nur maximal zur Hälfte auf die IPC zurückzuführen, um die es hier gerade geht. ;)
(nur damit keine Missverständnisse aufkommen)

LasterCluster

2019-11-18, 19:00:56

Wenn er extra darauf hinweist, dass ZEN2 ein ungewöhnlich hoher Sprung war, dann wirkt das im Kontext -wie Tesseract erwähnt hat- eher einschränkend. Aber eben einschränkend gegenüber der Erwartung: "Wenn die Evolution schon 15% bringt, dann muss die neue Arch ja sicher 30+% bringen!!!!11" .
Realistisch dürfte grob sowas wie bei Ice Lake drin sein, da dies zeigt was man heutzutage von neuen Archs erwarten kann

Setsul

2019-11-18, 23:54:52

@Ravenhearth:
Wenn er sich sicher wäre hätte er es gesagt und nicht impliziert. Das sagt mir dass der Sprung wieder irgendwo in der Größenordnung ist, hoffentlich größer aber nicht garantiert.
Der ist auch intelligent genug um von performance zu sprechen wenn er performance meint und IPC zu sagen wenn er IPC meint. Für den Kunden ist letztendlich egal wo die Leistung herkommt.

@Linmoum:
Nicht Takt und IPC vermischen. Bei Zen+ waren 2-3% durch den L2, der Rest war Takt.
Wenn bei Zen3 15% mehr Takt und nur 5% IPC kommen wird sich keiner beschweren außer den Leuten die jetzt schon von +30% IPC Minimum und drölf GHz fantasieren.

Nightspider

2019-11-19, 00:15:06

10% mehr IPC reichen ja schon aus um Intel zu schlagen.

Den Rest wird 7nm EUV machen.

Mein Tipp:

Bei 10% mehr IPC und 5% mehr Takt (entspricht ~250Mhz mehr) wird Zen 3 mit Comet Lake gleichziehen und bei allem darüber wird man Intel auf bei Single Thread Tests schlagen.

robbitop

2019-11-19, 04:59:27

Naja AMD muss jedes Jahr nachlegen. Wenn Intel 10 nm erstmal gefixt hat oder 7 nm vernünftig laufen hat man es nicht nur mit ICL zu tun(+18% IPC auf SKL) sondern auch mit Golden Cove (angeblich nochmal +15% auf ICL).
SKL Cores bleiben nicht für immer die Messlatte.

Aber man sieht ja, dass die jährliche Execution zu funktionieren scheint. Dennoch darf man Intel nicht unterschätzen. Die arbeiten sicherlich von Ryzen angestachelt mit Hochdruck an der Wiederauferstehung. Wie damals mit Core 2.

dildo4u

2019-11-19, 05:13:19

Intel muss erstmal demonstrieren das sie 8 oder 16 Kerns dies fertigen können,ich vermute das wenn das passiert der Takt höstens für Server taugt.Die Gaming Chips könnten 2022 in 7 nm kommen.

robbitop

2019-11-19, 05:34:22

Warum sollen sie das nicht können? Das ist deren Tagesgeschäft. Ggf sinkt der maximale Takt ein wenig. Ggf aber auch nur der all core turbo bedingt durch tdp.
Außerdem wird das Geld nicht nur im Gamer PC verdient. ;)

Wie gesagt - man sollte Intel nicht unterschätzen. Die haben locker eine Größenordnung mehr Ressourcen. Die haben halt lange mangels Konkurrenz gepennt. Das wird nicht ewig so bleiben.

dildo4u

2019-11-19, 06:27:29

Die Frage ist ob sie 16 oder 32 Cores ohne Chiplets erreichen können.
Ein Umbau nach Chiplets + einer Art Infinity Fabrik ist mit Sicherheit nicht in 2 Jahren machbar.

robbitop

2019-11-19, 06:33:21

Takt hat mit Chiplets IMO wenig zu tun. Eher mit Signallaufzeiten, kritischen Pfaden, wie schnell ein Transistor schalten kann etc. Chiplets bringen gute Yields, da sie kleiner sind. Auch sparen sie Masken, wenn man Chiplets in unterschiedlichen Produkten verbauen will. Dafür kostet es extra Energie und Latenz für die Offchip Kommunikation.

Die Frage ist, ob die Vorteile auch für Intel überwiegen. Wenn ja, gibt es keinen Grund, der Intel von Chiplets abhalten kann. Fabric haben sie. Und gemacht haben sie es auch schon (Clarkdale IIRC zuletzt).

Chiplets waren ein smarter Move von AMD. Aber es ist keine großartige Neuheit. Da ist etwas viel Hype.

w0mbat

2019-11-19, 08:30:41

Mit Zen2 hat AMD schon einen IPC Vorsprung. Der einzige Grund wieso Intel in ST zT noch etwas schneller ist, ist der Taktvorteil und die besseren RAM-Latenzen.

Auch wenn Zen3 nur 10% mehr IPC bring und keine Verbesserungen beim Takt wars das insg. für Intel.

Piefkee

2019-11-19, 08:32:17

Chiplets waren ein smarter Move von AMD. Aber es ist keine großartige Neuheit. Da ist etwas viel Hype.

Ein Chiplet für Server, Desktop, Konsolen und eventuell Mobile? Zeigt mir bitte mal was die Konkurrenz so macht. ;D
Chiplets ist Revolutionär, besonders aus der Sicht von AMD mit TSMC.

robbitop

2019-11-19, 08:43:04

Wie gesagt: der move war smart. Aber Chiplets sind nichts neues. IBM hat das vor über 10 Jahren schon gemacht. Und es hat auch Nachteile.
Bei einem teuren Prozess mit begrenzten Yields sind kleine Chiplets super. Wenn man wenig Ressourcen für Masken und unterschiedliche Chips hat ist das super. Wie gesagt: sehr gut. Aber hat auch Nachteile und technologisch nicht neu.

Mit Zen2 hat AMD schon einen IPC Vorsprung. Der einzige Grund wieso Intel in ST zT noch etwas schneller ist, ist der Taktvorteil und die besseren RAM-Latenzen.

Auch wenn Zen3 nur 10% mehr IPC bring und keine Verbesserungen beim Takt wars das insg. für Intel.
Dann zieht AMD mit Skylake Produkten gleich in Spielen oder überholt ihn leicht. IMO „das wars“ ist da etwas optimistisch ausgedrückt.
In Anwendungsbenchmarks trifft das aber zu. Und zwar schon heute. Aber 5-10% sind IMO kein „das wars“. ;)
Und wie gesagt: Skylake lebt nicht für immer.
Es bleibt zu hoffen, dass AMD jedes Jahr schön nachlegt. Denn ein starkes AMD bedeutet starken Wettbewerb. Und das ist gut für uns Endkunden.

Und damit das so bleibt darf AMD Intel nicht nochmal unterschätzen. Immer vom Schlimmsten ausgehen (so wie Zen 2 als ICL Wettbewerber gedacht war) und wenn es besser ist: sich freuen und was draus machen.

Pirx

2019-11-19, 09:23:34

Mit Zen2 hat AMD schon einen IPC Vorsprung. Der einzige Grund wieso Intel in ST zT noch etwas schneller ist, ist der Taktvorteil und die besseren RAM-Latenzen.
...
und wer weiß, was in der Richtung noch so alles in der Software schlummert:mad:: https://www.computerbase.de/2019-11/mkl-workaround-erhoeht-leistung-auf-amd-ryzen/

HOT

2019-11-19, 09:36:12

robbitop

2019-11-19, 09:56:46

Bei Clarkdale gab es auch keinen großen Nachteil. Da wanderte der IMC genau wie bei Zen 2 in ein GPU Chiplet. Latenz war kaum gestiegen und Leistungsaufnahme auch kaum. Sicher hatte man vor 10 Jahren noch keine so moderne Fabric wie heute. Aber ich würde mich wundern, wenn Intel das nicht auch hinbekommen würde wenn sie es wollten.
Und wie groß die Nachteile bei den großen IBM Power CPUs mit MCM waren, weiß auch keiner. Das soll AMDs Chiplets nicht schlechtreden. Ganz im Gegenteil. Gut gemacht und die richtige Idee zur richtigen Zeit. Sie war wie maßgeschneidert für AMD. Aber man muss es auch nicht überhypen.

Ich bin jedenfalls froh, dass Zen 3 doch deutlich nachlegen wird. Weiterhin gibt es also ordentliche Performanceentwicklung pro Zeiteinheit statt ein dreiviertel Jahrzehnt Stillstand. Das haben wir dem Wettbewerb und somit AMD zu verdanken. :)

SKYNET

2019-11-19, 11:27:44

Dass man die Chiplets ohne großartige Nachteile so hinbekommen hat ist sehr wohl revolutionär.

Außerdem war doch von Anfang an klar, dass Zen 1 nur eher ein Zen 0,5 ist, bei dem sogar erst in der + Variante die Handbremse gelöst wurde. Was bin ich dafür bespruckt worden.
Zen2 ist Zen ohne Kompromisse (sogar ein bisschen mehr, weil ja schon ein bisschen Zen3-Technik drinsteckt) und Zen3 die eigentliche Nachfolgearchitektur. Wieviel Performance das bringt ist natürlich ne ganz andere Kiste und kaum vorhersehbar.

sagte ja auch das gleiche, das zen1 nur halbfertig war, man musste den einfach damals schon bringen, sonst wäre man wohl definitiv konkurs gegangen... AMD setzte alles auf eine karte ein halbgares produkt zu bringen und es hat sich gelohnt gehabt.

ich selber halte nen 30% IPC sprung von zen2 zu zen3 eher für wunschdenken, wird wohl eher im gesammten 30% sein zum jeweiligen vorgängermodell(IPC + mehr an takt), was natürlich trotzdem ein fetter schlag für intel ist, die nur 5-7% machen pro generation(takt + IPC), wärend AMD in nur 2 generationen um knapp 40% zugelegt hat(IPC + takt) und somit dann in 3 generationen an die 70% zulegen wird... ähnliches gabs zuletzt mit dem sprung von P4 --> C2D/Q --> core(gesammt ca. 60%)... und ich bezweifel das intel das jemals wieder schaffen wird... denke wir werden jetzt ein paar jahre ryzen dominanz sehen, so wie es mit der core dominanz war... intel wird sicherlich irgendwann zurück schlagen, aber sicherlich nicht in den kommenden 3-4 jahren, sie haben einfach nix und sind zu gross und träge um schnell was liefern zu können.

YfOrU

2019-11-19, 12:05:19

Halte ich für deutlich zu pessimistisch. Mit Sunny, Willow und Golden Cove hat Intel von 2019 - 2021 drei High Performance CPU Architekturen auf der Roadmap.

Das ist schon erheblich mehr als "nix haben". Vor allen mit Blick darauf das Sunny Cove gegenüber Skylake ordentlich (IPC) zugelegt hat und die Nachfolger mehr als nur "Refreshs" sind.

HOT

2019-11-19, 12:08:14

Also Sunny Cove ist schonmal eher meh, vor allem im MT. Das wird sicherlich noch besser, aber Wunder sollte man da auch nicht erwarten. Alder Lake mit Golden Cove wird sicherlich interessant werden, aber da sind wir schon bei Zen3 Refresh oder Zen4.

amdfanuwe

2019-11-19, 12:28:57

Die Frage ist, ob die Vorteile auch für Intel überwiegen. Wenn ja, gibt es keinen Grund, der Intel von Chiplets abhalten kann. Fabric haben sie. Und gemacht haben sie es auch schon (Clarkdale IIRC zuletzt).

Chiplets waren ein smarter Move von AMD. Aber es ist keine großartige Neuheit. Da ist etwas viel Hype.
Die große Neuheit ist AMDs Infinity Fabric. Und da hapert es bei Intel. Mehrere unterschiedliche Chips Cache Cohärend effizient miteinander kommunizieren zu lassen.
Da kann Intel 2 Chips zusammenkleben, zu mehr reicht es bei ihnen aber nicht.
Sei es drum, bis 16 Core kann man auch ohne Chiplets noch gut was auf den Markt bringen. Aber da schießen ihnen die eigenen Fabs in den Fuß. Und dummerweise sind diese größer als die 4C Chips, mit denen die Fabs vor ein paar Jahren noch gut ausgelastet waren. Dadurch fehlt es jetzt an Kapazität.

Bambuslooter

2019-11-19, 12:30:45

Der 8 Kerner, vmtl. 4700X, sollte durch ein 8 Kern CCD doch immens an Latenz einsparen?
Interne Latenzen innerhalb der 4 Kerne unterboten sogar Intels ~44ns, wenn ich mich recht entsinne.
Spieleperformance sollte dementsprechend massiv zulegen?

Kann mich noch dran erinnern, dass die ersten Zen2 Server "Leaks" 12-15% IPC mehr genannt haben. Kam sogar minimal mehr IPC raus.
Wenn man vorsichtig rangeht, 10-12% + 5% Taktvorteil (mehr erwarte ich einfach nicht mehr).
Dann noch den immensen Latenzvorteil bei der Zusammenlegung der 8 Kerne(r).

Kann schon ein großer Sprung werden.

Bei der unterstützten Ramgeschwindigkeit erwarte ich nicht mehr als die jetzigen 3200. Beim OC sollte die IF vielleicht 4000er Ram mitmachen. Träumerei meinerseits.

Den EcoMode könnte man als Standard etablieren. Echt beeindruckende Ergebnisse vom 3950X die man auf pcgh erblicken durfte zwischen 105W und 65W.

HOT

2019-11-19, 13:09:29

IPC ist wie immer Anwendungsabhängig. Es gibt Anwendungen, bei denen Zen2 nur 5% IPC-Vorteil bringt, es gibt aber auch welche, bei denen sind es 25%. Deshalb ist dieser Wert auch purer unbrauchbarer BS oder besser gesagt Umgangssprache für Laien oder MarketingBS für Hersteller. Pro-Kern-und-Takt-Leistung-über-einen-Durschnitt-an-Anwendungen ist eigentlich das was gemeint ist. Das gibts aber so nicht, deshalb wird das auch immer eine Streiterei bleiben in dem Punkt.

Setsul

2019-11-19, 17:55:11

@amdfanuwe:
Cascade Lake-AP ist einfach UPI. Das geht bis 8 Sockel. Selbst 4 Dies mit je 38 Kernen auf ein Package zu kleben würde Intel ein müdes Lächeln kosten und immernoch 2P Systeme erlauben.

@Bambuslooter:
Die Frage ist ob die Latenz bei doppeltem L3 so bleibt. Zen2 ist auch ein bisschen langsamer als Zen1.
Aber selbst wenn die Latenz gleich bleibt bringt das natürlich nichts für alles das vorher schon auf 4 Kernen lief (ob jetzt 4 oder 8 Threads) und in 16 MB L3 gepasst hat oder eben auch in 32 MB nicht passt. Also wenn sich die Threads für jedes Frame durch 100 MB Daten (oder mehr) arbeiten müssen ändern auch 32 MB wenig. Es wird in jedem Frame ein Großteil rausgeworfen und dann beim nächsten wieder neu vom RAM geholt.
Latenz zum RAM bleibt auch erstmal gleich egal was man mit dem L3 macht.

Wobei es sicherlich Workloads gibt die mit 8 Kernen an einem Cache oder einfach generell wegen working set >16 MB durch den L3 deutlich zulegen werden.

Complicated

2019-11-19, 18:08:39

Da wanderte der IMC genau wie bei Zen 2 in ein GPU Chiplet.
GPU Chiplet bei Zen2? Habe ich etwas verpasst?

Intels Problem ist der Interconnect, auch schon bei Clarkdale. Ob EMIB das bringt was AMD mit IF geschafft hat ist zu bezweifeln.

Tesseract

2019-11-19, 20:37:27

Die Frage ist ob die Latenz bei doppeltem L3 so bleibt.

mal abgesehen davon ist die zusammenlegung der CCX alleine keine verdoppelung. das hilft in einigen sonderfällen (z.B. <=4T oder viele threads die sich ein kleines datenset teilen), wenn aber >4T jeweils ihr eigenes süppchen kochen wird das kaum was bringen bzw. in einigen wenigen fällen sogar kontraproduktiv sein wenn sich mehr cores gegenseitig die werte rausschmeißen.
in der gesamtheit sicher positiv, selbst inkl. potenziell schlechterer latenzen, aber sicher nicht so viel wie eine echte verdoppelung.

auch beim takt wär ich vorsichtig. ein octa-komplex ist zunächst mal eher im nachteil was die taktbarkeit angeht - da weniger modular - was man mit besserer optimierung bzw. fertigung ausgleichen muss.
ich denke der hauptgrund warum AMD überhaupt auf 8C CCX geht ist wohl primär die skalierung über 64 cores hinaus bzw. für weniger NUMA domains(?).

robbitop

2019-11-19, 22:18:28

Hat Intel nicht im Zusammenhang mit Xe ein passendes Interconnect vorgestellt? Ich kann mir gut vorstellen dass Intel entsprechendes Fabric sicherlich auch entwickeln kann, wenn sie es nicht schon getan haben buw dabei sind. ;)

Also Sunny Cove ist schonmal eher meh, vor allem im MT. Das wird sicherlich noch besser, aber Wunder sollte man da auch nicht erwarten. Alder Lake mit Golden Cove wird sicherlich interessant werden, aber da sind wir schon bei Zen3 Refresh oder Zen4.

SC ist IMO bis dato nur in Bezug auf maximale Taktraten eingeschränkt. Die 15W CPU versägt die Vorgängerversion bei Anandtech deutlich. Perf/W scheint also nicht verkehrt zu sein. Zumindest ist das für Server und Mobile wichtiger als maximale Taktrate. Und da wird eine Menge Gewinnspanne gemacht.
Und niemand weiß, ob die maximalen Taktraten nicht noch gefixt werden. (10nm++ oder 14nm+++ Portierung)

Willow Cove sieht eher wie ein Refresh aus. Golden Cove legt noch mal einen drauf.

Bis es richtig richtig ernst wird, hat man aber Zen3 schon draußen und Zen 4 in der Mache.

Berniyh

2019-11-19, 22:38:33

Hat Intel nicht im Zusammenhang mit Xe ein passendes Interconnect vorgestellt? Ich kann mir gut vorstellen dass Intel entsprechendes Fabric sicherlich auch entwickeln kann, wenn sie es nicht schon getan haben buw dabei sind. ;)
Intel hat doch extra dafür ein Konsortium gegründet, bei dem übrigens auch AMD Mitglied ist.

Vermutlich wird es am Ende dann mehr oder weniger gleich zu IF sein, aber eben mit dem Intel Stempel drauf.

Setsul

2019-11-19, 23:19:02

@Tesseract:
Für die Latenz zählt erstmal nur dass jetzt ein einzelner L3 doppelt so groß ist. Ja, im Gegensatz zu Zen2 gibts keinen Vorteil durch höhere Gesamtkapazität, also wird alles was mit 16 MB / 4 Kernen glücklich war wohl eher minimal schlechter laufen.

Taktbarkeit habe ich wenig Bedenken, die Kerne sind da relativ unabhängig.

Skalierung ist nett, aber da die Grenzen zwischen den Dies viel stärker auffallen, vor allem seit dem gemeinsamen IOD, ist das wohl eher nebensächlich. Mehr Kerne an einem gemeinsamen LLC sind einfach besser, solange sich die Latenz in einem gewissen Rahmen hält. Was nur 4 Kerne braucht wird bei 5 Takten langsameren L3 wohl kaum in ein Loch fallen. Aber alles darüber hinaus mag die CCX wirklich nicht. Es ist besser alles gut zu können als einen Teil minimal besser, dafür beim Rest hinter Intel zu liegen. Ein CCD mit einem L3 und 8 Kernen ist da schon nicht schlecht.
Wenn man sich an die Ringe vor Skylake erinnert waren das auch jeweils 8-12 Kerne. Andererseits gibts bei SKL-SP SNC Mode weil das Ganze nach oben Grenzen hat. Ich denke mehr als 12-16 Kerne kann man nicht sinnvoll alle untereinander mit ähnlicher Latenz verbinden ohne dass der Stromverbrauch oder die Latenz übermäßig ansteigt.
Deshalb ist es ja so interessant wie der Zen3 L3 aufgebaut ist. Ich denke das Konzept CCX ist wirklich begraben und das wird etwas flexibler.

Lehdro

2019-11-19, 23:51:48

Ich denke das Konzept CCX ist wirklich begraben und das wird etwas flexibler.
inb4: Zen4 hat 16C CCDs mit 2x 8C CCX. ;)

Nightspider

2019-11-20, 00:21:32

Was ist eigentlich am Infinity Fabric so besonders, das Intel das nicht in wenigen Jahren auf die Beine stellen können soll?

Brillus

2019-11-20, 00:51:19

Was ist eigentlich am Infinity Fabric so besonders, das Intel das nicht in wenigen Jahren auf die Beine stellen können soll?

Im großen und ganzen würde ich mal sagen garnichts, mit ihrem Mesh hat Intel ja was ähnliches. Sie hatten es halt bis jetzt noch nicht für nötig gehalten (mehr Absatz -> mehrere verschiedene Designs lohnen sich eher, nicht soviele Core im Consumer Segment).

Ich glaub auch Intel hat schon lange vor AMD Ryzen gebracht hatte an Chiplets geforscht, alles andere wäre Epic-Fail die Sau wurde schon lange genug durch das EDA-Dorf getrieben in Form von 2,5D Stacking (EMIB anyone), und eigentlich hatte auch niemand bezweifelt das man irgendwann an den Punkt kommt wo man es braucht.

Die Sache ist halt einfach das so was neues halt am besten von Grund auf angelegt werden will und dann hat man halt seine 3-5 Jahre (+ Intel Prozessverspätung).

Final war AMD einfach der Meinung das es früher sinnvoll ist (im Vergleich zu Intel) und schien damit Recht behalten zu haben. Was nichtmal heißt das es im Intel Fall sogar früher Chiplet die richtige Entscheidung gewesen wäre.

amdfanuwe

2019-11-20, 01:43:37

Im großen und ganzen würde ich mal sagen garnichts, mit ihrem Mesh hat Intel ja was ähnliches.
Dann versuch mal das Mesh über die Chipgrenzen nach außen zu leiten.
Da reichen dir die Leitungen nicht, wegen der veränderten Latenzen funktioniert das ganze nicht mehr und säuft Strom ohne Ende.

Hammer des Thor

2019-11-20, 03:03:58

auch beim takt wär ich vorsichtig. ein octa-komplex ist zunächst mal eher im nachteil was die taktbarkeit angeht - da weniger modular - was man mit besserer optimierung bzw. fertigung ausgleichen muss.
ich denke der hauptgrund warum AMD überhaupt auf 8C CCX geht ist wohl primär die skalierung über 64 cores hinaus bzw. für weniger NUMA domains(?).

Intel bekommt doch einen höheren Takt trotz Okta-Ringbus hin!. Warum soll das die Taktbarkeit mindern, wenn der L3 Takt unabhängig von den Core-Takten läuft? Um einzelne Kerne übertakten zu können muss der eh asyncron laufen.

Setsul

2019-11-20, 09:55:42

Leute, begreift doch dass ein Interconnect für alles kein Vorteil bei der Leistung ist, sondern ein Nachteil.
IF hat on-chip die gleichen Latenzen wie QPI/UPI off-chip. Das heißt nicht, dass UPI schlecht ist oder dass das Mesh schlecht ist. Die sind beide bei den Aufgaben die sie erfüllen mindestens genauso gut, wenn nicht besser, vor allem das Mesh.

Intel ändert sein LLC Design alle 10 Jahre oder selterner, das inter-socket Interconnect alle 10 Jahre oder seltener und das on-chip Interconnect alle 10 Jahre oder seltener.
Aber AMD soll mit weniger Ressourcen bitte alles neu entwickeln von heute auf morgen.
IF existiert weil es alles kann. Vielleicht nicht großartig, aber gut genug. Die Alternative wäre nochmal den K10 L3 wiederzuverwenden, weil das schon bei Bulldozer so gut funktioniert hat (ich hoffe man erkennt die Ironie) oder mit Hypertransport rumzukrebsen.

IF ist eigentlich ein recht schlechtes on-chip Interconnect dafür ein passables off-chip Interconnect, aber wenn der Großteil der Verbindungen zwischen Chiplets/Sockets ist und nur 1-8 zwischen CCX auf einem Die sind (was ja bald auch noch wegfällt) dann würde ich auch eher in ein gutes off-chip Interconnect investieren, das noch jahrelang und auch für GPUs verwendet werden kann und wird.

UPI hat zwischen Sockeln die Latenz die IF auf einem Sockel hat. Intel muss nichts in wenigen Jahren auf die Beine stellen, sie haben es schon seit Jahren.
Cascade Lake-AP war so unspektakulär weil es für Intel so simpel ist. Die können das jederzeit. Sie mussten einfach nicht. Intel kann es sich leisten einen 2C ULT, 4C ULT, 2C, 4C, 6C, 8/10C, 10C server, 18C und einen 28C Die aufzulegen. AMD ist glücklich wenn sie jedes Jahr einmal 8C und ne APU ausbringen.
Magny Cours war auch schon MCM. War bloß nicht so gut. Bulldozer war auch MCM. War bloß scheiße.
Für die Ressourcen die AMD hat ist Zen einfach verdammt gut geworden. Im Gegensatz zu K10 ne neue Architektur. Im Gegensatz zu Bulldozer in sich stimmig.

Das einzige was IF besser kann als UPI ist GPUs verbinden. Weil Intel keine GPUs hat, also das nie brauchte. Und siehe da, kaum haben sie GPUs, haben sie auch ein Interconnect dafür. Mit EMIB. Besser als einfach nur durchs Package wenn man hohe Bandbreite braucht.

Piefkee

2019-11-20, 11:52:17

Setsul

2019-11-20, 12:11:46

Eben nicht.
Bei Zen1 wurden 4/8 Dies mit je einem eigenen memory controller verbunden. Genau das macht UPI auch. IFOP und IFIS sind natürlich unterschiedliche PHYs aber das ist das geringste Problem.
Bei Threadripper haben 2 von 4 Dies keinen aktiven memory controller. Kein Unterschied, funktioniert genauso. Kohärenz ist Kohärenz. Bei Zen2 hat jetzt eben keines der Chiplets einen eigenen memory controller mehr. Ist vom Zugriff aber nicht anders als bei Zen1 wenn man alle Daten vom RAM im anderen Sockel holen muss.
Das alles kann UPI auch. Also nein, es ist nichts anderes.

Wie gesagt, dass IF alles mit allem verbindet ist aus der Not geboren, nicht weil 90 ns Latenz von Kern 0-3 zu Kern 5-7 auf dem selben Die erstrebenswert sind.

Lehdro

2019-11-20, 14:06:33

Die sind beide bei den Aufgaben die sie erfüllen mindestens genauso gut, wenn nicht besser, vor allem das Mesh.

Kannst du das bitte mal genauer ausführen, das interessiert mich jetzt. Wo hat Intels Mesh spezifische Vorteile gegen aktuelle IF Implementierungen? Latenz kann es laut diesen Grafiken schon einmal nicht sein, es sei denn Intel hat das Mesh mittlerweile beschleunigt:

https://i.redd.it/740adxy0i3931.png
https://3dnews.ru/assets/external/illustrations/2017/06/19/954174/multicore.png
Alles von 3dnews.ru
Zum Vergleich pcper zum initialen Launch:
https://hardforum.com/data/attachment-files/2019/05/214920_latency_pingtimes_0.png
Laut diesen Bildern wäre ein zwei Chiplet 3900/3950X zwar nicht latenzärmer als ein Ringbus 6950X, aber Skylake X würde geschlagen werden. Der wird aber mit zunehmender Größe nochmal deutlich langsamer. Sehe nicht warum das beim kommenden TR3000 der Fall sein sollte - immerhin macht es nun keinen Unterschied mehr ob Cross CCX oder Cross CCD angesprochen wird.

Bambuslooter

2019-11-20, 16:54:28

@Setsul danke für deine ausführlichen Antworten.
Den L3 hatte ich meinen Ausführungen sogar vergessen und mich rein auf die Verdopplung der Kerne in einem Komplex versteift.
Meiner Meinung nach hat der Zugriff auf mehr als 4 Kerne ja doch schon für Probleme gesorgt.
Wenn das jetzt wegfiel, müsste die Performance in Spielen gut ansteigen.

Complicated

2019-11-20, 17:10:01

Entscheidend ist auch AMDs IF über PCIe. Da geht Intel eben nicht die Standards mit bisher...nun setzen Sie auf PCIe5, was beileibe nicht in der Schublade liegt bei Ihnen.

Dann der Vergleich Mesh vs. IF. Auch AMD nutzt kein IF um die Kerne miteinander zu verbinden in einem CCX. Erst ausserhalb des CCX kommt IF zum Einsatz. Mit 8 Cores im CCX wird auch etwas meshartiges verwendet.
Solange Intel keine kleineren Cluster nutzt wie AMD für die Kerne werden Sie eben Meshes nutzen müssen, da der Rinbus ab einer Kernzahl nicht mehr die beste Option ist. Ich denke man sieht genau wo AMD die Latte höher setzt und so genau in diese Lücken sticht mit der Erhöhung der Kernzahl. Intel kann aber auch nicht alle 12 Monate die Richtung der Entwicklung ändern.

Ich denke die Sorgen rund um die Sidechannel Schwächen werden Intel viel Zeit und Geld kosten, so dass AMD womöglich schnell auf die vernachlässigten Bereich fokussieren kann und Intel damit vor sich her treiben wird die nächsten 2 Jahre.

Und wenn sich am Ende herausstellt, 10nm waren gar nicht das Problem, sondern doch die Architektur, dann kann es noch lustig werden.

Setsul

2019-11-20, 18:33:25

@Lehdro:
Im wesentlichen das hier:
https://images.anandtech.com/doci/14694/TinyMembenchEpyc2.png
Nicht vergessen dass der 8280 nur 38,5 MB L3 hat. Also schon für 16 MB muss man zu einigen Slices. Intel hätte überhaupt keinen Spaß mit nur 1,375 MB pro Slice wenn sie nicht 20 Slices mit so niedriger Latenz verbinden könnten. Ohne Mesh gäbs keinen 28C Die auf 14nm. Die Kerne sind größer, der 1 MB L2 ist größer, nur durch den kleineren L3 passt das alles auf 700mm².

Nebenbei hat sich die intra-CCX Latenz beim 3900X auch fast halbiert und das kann man beim besten Willen nicht aufs IF schieben.
3dnews.ru hat übrigens mit 3600 MHz RAM getestet. Wenn man das Mesh übertaktet kommt man auf 60ns Ping. Das ist nicht das Problem.
IF schluckt auch einen Haufen Strom. https://www.anandtech.com/show/13124/the-amd-threadripper-2990wx-and-2950x-review/4
Auf 7nm ist das Problem ziemlich im Griff und AMD konnte bei der Latenz was machen. Aber auf einem ähnlichen Prozess sah es schon ziemlich übel aus. Selbst mit den Verbesserungen bei Zen2 würde ich bei gleichem Prozess (z.B. Intel 14nm für beide) auf das Mesh setzen.
Dass AMD 7nm genießen darf während Intel irgendwelche 400W Cascade Lake-AP Monstrositäten präsentiert hat sich Intel natürlich selbst eingebrockt, liegt aber nicht am Mesh.

Um zurück zu meinem ersten Bild zu kommen:
Man stelle sich jetzt vor AMD baut einen 32+ MB L3, bekommt auch so eine wunderschöne flache Linie bis ~30 MB (wahrscheinlich etwas höher als die jetzige, aber unter der von Intel) und dort wo das inter-die IF dann 100+ ns produziert geht bei Intel auch die Latenz nach oben weil ihnen einfach der L3 insgesamt ausgeht. Klarer Sieg auf ganzer Linie. Und genau deshalb macht AMD das. Weil das genau die Schwäche des CCX ist und jetzt ist Zeit und Geld da um den CCX und diese Schwäche loszuwerden.

Lehdro

2019-11-20, 18:54:15

@Lehdro:
Im wesentlichen das hier:
Cool, danke, das nenne ich mal eine fundierte Antwort. :)
Also krankt es beim IF eher am Zugriff auf den Cache, als an der reinen Latenz zwischen den Kernen per se - da sich das halt alles nochmals addiert durch die L3-Slices über verschiedene CCX/CCDs.

Beim Stromverbrauch muss man aber Anmerken dass das nicht 1:1 vergleichbar ist, da deutlich anders agiert wird, schon alleine was verfügbares I/O (was eben auch zum Uncore gehört) angeht. Denke mal da ist noch ordentlich Potenzial, AMD hat da ne fremdeingekaufter Menge PHYs drin und das Potential zum Undervolten war zumindest bei den mir bekannten 2xxxer Threadrippern ziemlich gigantisch, sofern man nicht über 3200 DDR4 gehen will. Denke dass das mit dem I/O Die und entsprechendem Binning auch angegangen werden kann (oder wurde, hat jemand Epyc 7xx2 I/O Verbrauchsdaten?).

basix

2019-11-20, 20:19:58

Wie sieht das eigentlich mit dem IF "MUX" auf dem CCD aus. Wenn pro Chiplet nur noch 1x 8C CCX vorhanden ist, fällt da nicht etwas Logik weg und die Latenz verringert sich automatisch?

Setsul

2019-11-21, 00:02:44

@Lehdro:
Ich denke die Latenz ist mittlerweile im Griff. 500 Takte waren aber auch abnormal.
Probleme gibts erstens unter Last, schließlich muss alles durch eine einzige Verbindung anstatt wie beim Mesh sich die am wenigsten belastete von zig Routen aussuchen zu können, und zweitens durch die Trennung der Caches. Die L3s sind strikt Victim-Caches der L2s in dem CCX. Was nicht in dem CCX gebraucht wird landet auch nie in dem L3. Ist egal ob Platz wäre. Auch wenn zwei CCX auf den gleichen Daten arbeiten werden die Lines die in einem fremden L3 vorhanden sind in den L2 geholt und dafür fällt irgendwas anderes in den L3 und noch etwas anderes aus dem L3 raus. Wenn die neue Line in den L3 fällt und eine andere verdrängt ist sie jetzt eben in zwei L3s. Man gewinnt nichts an Latenz, weil der RAM ja auch bei 70ns liegt und man gewinnt nichts an Kapazität weil jede Line die man von fremden L3s holt eine andere verdrängt. Sieht zwar auf dem Papier toll aus die 256 MB L3, aber effektiv arbeitet jeder Kern mit 16 MB die er sich mit 3 anderen teilt. Manchmal reicht das eben nicht. Ist natürlich weniger häufig als bei Zen1, aber ideal wären eben 30+ MB.

@basix:
Theoretisch ja. Dafür wird wohl etwas an Logik dazukommen für einen komplexeren L3. Unterm Strich wird der Durchschnitt wohl niedriger sein.

Der_Korken

2019-11-21, 09:53:14

Wäre es bei 8 Kernen an einem L3 nicht irgendwann lohnenswert den L3 von Victim auf Inclusive umzustellen? Wenn man alle Daten in allen L2s überprüfen muss, klingt das für mich nach einem Kohärenz-Alptraum, denn es kommen immer mehr Kerne dazu. Außerdem ist AMD mittlerweile bei 4MB L3/Core und 0,5MB L2/Core, d.h. es "kostet" nur noch 1/8 des Caches, statt 1/4 wie bei Zen 1. Können bei einem inklusiven Cache die Daten im L3 weiterverwendet werden, wenn ein Prozess innerhalb eines CCX (oder wie auch immer das bei Zen 3 heißen wird) den Kern wechselt? Das würde Wechsel deutlich billiger machen.

Setsul

2019-11-21, 10:52:09

Richtig, 1/8 ist die Grenze bei der man normalerweise sagt dass inklusiv sinnvoll ist.
Ist die Frage wie das ganze aufgebaut wird, ob mit Slices wie bei Intel die nur für die Inklusivität des eigenen Kerns zuständig sind oder eher zentral.

Beim CCX hat sich AMD um die Koordination der L2s gedrückt weil der L3 shadows tags vom L2 hat und die direkt prüfen kann. Ich hab ja schonmal geschrieben dass ein 8 Slice L3 in dieser Form aber geometrisch nicht ideal ist für die Latenzen und es generell einfach an Flexibilität fehlt. Die feste Aufteilung der Adressen bedeutet es muss immer der gesamte L3 aktiv sein. Das ist weder der Effizienz noch den Yields zuträglich. Bei 32 MB müsste man dann unverhältnismäßig viel Redundanz einbauen damit nicht ein einziger Fehler in diesem Cache 8 funktionierende Kerne nutzlos macht.

Ich könnte natürlich völlig falsch liegen und ob es inklusiv wird oder nicht steht auch in den Sternen (und irgendwo in internen AMD Dokumenten) aber ich denke eben dass das nicht einfach nur ein 8 Kern CCX wird, sondern eine größere Überarbeitung um die Nachteile loszuwerden oder zumindest zu reduzieren.

Complicated

2019-11-21, 14:32:21

Dann müsste sich AMD vom MOESI-Protokoll verabschieden. Das würde ich derzeit ausschließen, da dies derzeit AMDs Vorteil bei Interconnects ist
MOESI bietet keinen wesentlichen Vorteil gegenüber MESI, wenn das Verbindungsnetzwerk zwischen Prozessoren und Speichercontroller ein*Bus*ist. Es ist hingegen bei direkten Netzwerken von Vorteil, wie zum Beispiel bei AMD-Opteron-Systemen. Das Vermeiden des Zurückschreibens von modifizierten Cache-Lines sorgt hier für die Entlastung von Verbindungsnetzwerk und Speichercontroller. Außerdem kann die Kommunikation zwischen zwei oder mehreren CPUs bzgl. Latenz und Übertragungsrate signifikant besser sein als zwischen CPU und Hauptspeicher. Bei*Multicore-CPUs*mit jeweils eigenen Caches pro Core ist dies meist der Fall.

mboeller

2019-11-21, 15:21:44

wenn es nach dieser alten Präsentation von 2010 geht, dann ist inclusive langsamer als exclusive:

https://www.researchgate.net/publication/221005399_Achieving_Non-Inclusive_Cache_Performance_with_Inclusive_Caches_Temporal_Locality_Aware_TLA_Ca che_Management_Policies

Gipsel

2019-11-21, 16:52:13

Ich hab ja schonmal geschrieben dass ein 8 Slice L3 in dieser Form aber geometrisch nicht ideal ist für die Latenzen und es generell einfach an Flexibilität fehlt. Die feste Aufteilung der Adressen bedeutet es muss immer der gesamte L3 aktiv sein. Das ist weder der Effizienz noch den Yields zuträglich. Bei 32 MB müsste man dann unverhältnismäßig viel Redundanz einbauen damit nicht ein einziger Fehler in diesem Cache 8 funktionierende Kerne nutzlos macht.Auch jetzt kann AMD schon einen Teil des L3-Caches deaktivieren, falls da ein unkorrigierbarer Defekt vorliegt (was dann eher im Cache-Controller sein dürfte, da das SRAM-Array selber eigentlich mit sehr überschaubarer Redundanz sehr nahe an 100% Yield zu bekommen ist). Der zuständige Teil des L3 wird ja über einfaches Interleaving festgelegt (low order Adress-Bits [gleich oberhalb der 64Byte Cacheline-Größe] bestimmen das). Bisher sind das genau 2 Bits, die die 4 Möglichkeiten enkodieren. Das Mapping im Cache-Controller ist aber konfigurierbar (vermutlich ist das schlicht eine 2Bit=>2Bit LUT), wodurch man Teile ungenutzt lassen kann (für entsprechendes Balancing sollte man die Hälfte [75% wären wohl auch möglich, das reduziert die Bandbreite aber schon empfindlich] deaktivieren, selbst wenn man theoretisch wohl auch nur 25% deaktivieren könnte [dann wäre aber ein Drittel des verbleibenden L3 für die Hälfte der Adressen zuständig, was vermutlich nicht so optimal wäre]). AMD verkauft ja auch ein paar Ryzen-CPUs, bei denen nur die Hälfte des L3 aktiv ist (weil die vermutlich sonst nicht korrekt laufen würden). Und genau das gleiche wäre natürlich auch bei einem 8C-CCX möglich (wo 3 Bits das zuständige Stückchen vom L3 festlegen würden, wenn es genau so wie bisher funktionieren würde).

BoMbY

2019-11-21, 17:14:58

Dann müsste sich AMD vom MOESI-Protokoll verabschieden.

Haben sie schon lange - es ist ja jetzt MDOEFSI:

https://i.imgur.com/kNI4qft.jpg

Setsul

2019-11-21, 17:29:53

@Gipsel:
Quelle dafür dass das frei konfigurierbar ist?

Halbieren geht natürlich, ist aber nicht ideal. 25 oder 75% sind ja ungünstig. Also was macht man wenn es passiert? Intel hat die Möglichkeit 25% jeder Slice zu deaktivieren, AMD müsste sich bei einem Die mit 8 funktionierenden Kernen dazwischen entscheiden 8 Kerne mit halbem Cache und halber Bandbreite zu verkaufen oder eben nur 4 Kerne.

Gipsel

2019-11-21, 17:37:06

@Gipsel:
Quelle dafür dass das frei konfigurierbar ist?War in irgendeiner Präsentation zur Zen-Architektur drin. Müßte ich suchen.
Und Halbieren ist besser, als ganz wegschmeißen (was bei Dir als Alternative zur Wahl stand). ;)

Setsul

2019-11-21, 18:35:15

Ja, hätte ich anders ausdrücken sollen. Auf jeden Fall wird aus dem 8 Kerner dann entweder ein sehr gehandicappter 8 Kerner oder ein 4 Kerner oder meinetwegen auch ein leicht gehandicappter 6 Kerner. Alles nicht so berauschend.

Complicated

2019-11-21, 19:08:31

Haben sie schon lange - es ist ja jetzt MDOEFSI:Danke für die Ergänzung der Weiterentwicklung. Bleibt ja dennoch die Notwendigkeit des Victim Caches. Dresdenboy hatte das damals schön zusammengefasst:
https://www.planet3dnow.de/cms/26077-details-und-analyse-der-zen-architektur-nach-der-hot-chips-konferenz/4/
Entgegen anderslautender Gerüchte setzt AMD beim Cache-Aufbau weiterhin auf exklusive L3-Caches nach der “Victim Strategy”. Das heißt, dass Daten in der Regel entweder direkt in den L1- oder in den L2-Cache geladen werden: Fallen Daten aus dem L2 heraus, landen diese “Opfer” (victims) im L3. Bei Intel-Designs liegen L2-Daten dagegen automatisch immer als Kopie auch im L3, was einerseits die effektive L3-Cachegröße und damit indirekt auch die L2-Größe begrenzt, andererseits die Kern-zu-Kern-Kommunikation vereinfacht.

Cache-Organisation und ‑Aufbau gehen somit Hand in Hand. Weil AMD kein inklusives Cachedesign wählte, ein Datenaustausch über den L3 also ohehin fast unmöglich ist, benötigt man auch keinen einzelnen gemeinsamen L3-Cache, sondern kann sich mit simplen 8‑MiB-Modulen begnügen. Insbesondere bei Serverchips mit vielen Kernen und noch mehr Cache, wird die Cacheorganisation zum Problem. AMD setzt bei den Serverchips aber auch auf einen bewährten MCM-Ansatz, mit dem von vorne herein keine gemeinsamen L3-Caches möglich wären. Somit ist die Designentscheidung insgesamt nachvollziehbar und schlüssig. Als Speichermodell findet die bewährte und schon von K8/K10 bekannte MOESI-Strategie Anwendung.

w0mbat

2019-11-24, 16:58:51

https://twitter.com/BitsAndChipsEng/status/1198543242989637632
According to latest rumor, Zen3 L1 cache will be about 40% faster than Zen2 L1 Cache: over 2000 GB/s. No data about L2/L3.

robbitop

2019-11-24, 17:29:56

Wobei Bandbreite ja selten in der Praxis der Flaschenhals ist. Hitrate und Latenz schon eher.

Der_Korken

2019-11-24, 18:13:53

basix

2019-11-24, 20:46:00

+40% benötigt man, um auf +40% Performance zu kommen. So einfach ist das :D

Iscaran

2019-11-26, 08:58:26

AIDA v6.20 hat bereits einen preliminary support für Ryzen 4th Generation:

https://www.planet3dnow.de/cms/53009-aida64-version-6-20/
"Preliminary support for 4th generation AMD Ryzen desktop CPUs"

Scheint also das Tape Out von Ryzen 4xxx Desktop inkl. erster Prototypen schon in Umlauf sind. Release wohl sicher "bald" (Q2/2020 ?)

robbitop

2019-11-26, 09:27:28

Könnte Renoir sein.

w0mbat

2019-11-26, 09:41:25

Ja, wie robbitop schon schrieb werden das wohl eher die Zen2 APUs sein, die als Ryzen 4k auf den Markt kommen.

Unabhängig davon hatte Zen3 ziemlich sicher schon sein tape-out, er soll ja im 2H20 kommen und sowas passiert meist ein Jahr früher.

SKYNET

2019-11-26, 11:14:38

Könnte Renoir sein.

denke ich auch, sollte uns in den ersten 2-3 monaten des neuen jahres vor die füsse geworfen werden.

Gipsel

2019-11-26, 11:31:25

Unabhängig davon hatte Zen3 ziemlich sicher schon sein tape-out, er soll ja im 2H20 kommen und sowas passiert meist ein Jahr früher.Gab es im Umfeld der Vorstellung von Rome nicht eine Folie in einer Präsentation, daß das Zen3 Tapeout bereits erfolgt sei (in Q3/2019)?

Edit:
War sogar schon Q2/19.

https://www.hardwareluxx.de/images/cdn01/3AFD6BE07EB946648E1BFEC79DEB9388/img/8BEF9C1CFC32475098D22F12E001F5F9/AMD-EPYC-Milan-Konferenz-Roadmap-1_8BEF9C1CFC32475098D22F12E001F5F9.jpg

S940

2019-11-26, 11:42:27

Wie kommt man denn auf einen so "krummen" Wert wie 40%? 2000GB/s lesen schafft bereits der 3700X mit 4Ghz (64Byte*8*4*10^9) im Aida-Test. Die Busbreite zum L1 wird ja wohl kaum um 40% ansteigen (auf 89Bytes/s) und der Takt erst Recht nicht.
Mal abgesehen vom konkreten Wert, der ja von der Taktfrequenz abhängig ist, würde ich auf ne Optimierung für FMA-Instruktionen tippen.

Die aktuellen L1-Caches sind für Rechnungen wie A+B=Z ausgelegt, 2x Laden (A+B) und einmal Speichern (Z). Mit FMA kommt aber noch ne Multiplikation dazu also A+B x C = Z, ergo muss man eine Variable mehr pro Kalkulation laden, wenns in einem Rutsch gehen soll. Natürlich liegen ein paar Variablen schon in den Registern vor und die OoO Exec. samt Prefetchern versuchen die Ladevorgänge günstig zu verschachteln und zu verstecken, aber trotzdem bleibt es dabei, dass man die 3 Variablen irgendwann laden muss. Je mehr FMA-Code man hat, desto wichtiger wirds.

Spannend wird es, wenn man dann die Leistung mit Intels 2x512bit Loads vergleicht. Unterm Strich könnte die AMD-Cache-Lösung die eigenen 256bit-Rechenwerke besser auslasten und den Abstand zu Intels 512bit verringern. Dürfte aber wirklich nur mit viel AVX-Code eine Rolle spielen, also eher was für die HPC-Gemeinde. SMT dürfte natürlich auch profitieren, solange der 1 Store-Port nicht der Flaschenhals ist.

Kurz: Ein Load-Port mehr -> +50% Bandbreite theoretisch.

+40% praktisch gemessen sollte hinkommen.

w0mbat

2019-11-26, 12:00:08

@S940: Könnte das also ein Hinweis auf zB AVX512 sein?

S940

2019-11-26, 12:30:36

@S940: Könnte das also ein Hinweis auf zB AVX512 sein?Nein, das genau nicht. Für AVX512 sind +40% viel zu wenig, dazu bräuchte man ne Verdopplung also +100%.

Das hat AMD aber gerade erst hinter sich gebraucht, da sie mit Zen2 erst 256bit Rechenwerke samt 256bit Loads+Stores eingeführt haben. Von daher kann man davon ausgehen, dass die FPU nicht schon wieder überarbeitet werden wird.

Ein 3. L1-Port wird die FPU-Leistung aber trotzdem verbessern und auch dem SMT-Betrieb zu Gute kommen, unterm Strich dürfte sich das damit rentieren.
Man dürfte erwarten, dass AMD bei AVX256-Code Vorteile haben wird, Intel braucht für mehr Leistung extra 512bit Code, wird aufgrund der Load-Limitierung aber nicht doppelt so schnell sein (Wenn wirklich nur FMA gerechnet wird).
Unterm Strich ne gute Idee, denke ich, Intel verbrät für die 512bit viel Die-Fläche und Datenleitungen. Pro Takt 3x256 anstatt 2x512bit einzulesen, dürfte die elegantere Lösung in Sachen Perf/Watt sein.

robbitop

2019-11-26, 12:47:56

AVX512 sollte man besser double cycle unterstützen. Es gibt nicht so viele Anwendungen, die deutlich davon profitieren.

HOT

2019-11-26, 13:34:27

Stimmt schon, der Aufwand würd sich eh kaum lohnen. Ist sogar die Frage, ob die Nachteile nicht generell die Vorteile überwiegen bei 512Bit breite, da profitiert ja sonst gar nichts von. Ich würd das generell in 2 Cycles erledigen, was anderes ergibt gar keinen Sinn. Man muss da jetzt auch nicht Intels AVX512-Leistung hinterherrennen, das ist völlig sinnlos. Wär nur schön, wenn der Befehlssatz überhaupt drin ist, das reicht aber auch.

genervt

2019-11-26, 14:19:21

Nach den bisherigen Aussagen AMDs glaube ich nicht an eine Unterstützung von AVX512, auch nicht per 2 Cycle. Der Anwendungsfall ist zu speziell und AMD selbst verweist auf OpenCL bzw GPGPU.

][immy

2019-11-26, 15:42:59

Nein, das genau nicht. Für AVX512 sind +40% viel zu wenig, dazu bräuchte man ne Verdopplung also +100%.

Das hat AMD aber gerade erst hinter sich gebraucht, da sie mit Zen2 erst 256bit Rechenwerke samt 256bit Loads+Stores eingeführt haben. Von daher kann man davon ausgehen, dass die FPU nicht schon wieder überarbeitet werden wird.

Ein 3. L1-Port wird die FPU-Leistung aber trotzdem verbessern und auch dem SMT-Betrieb zu Gute kommen, unterm Strich dürfte sich das damit rentieren.
Man dürfte erwarten, dass AMD bei AVX256-Code Vorteile haben wird, Intel braucht für mehr Leistung extra 512bit Code, wird aufgrund der Load-Limitierung aber nicht doppelt so schnell sein (Wenn wirklich nur FMA gerechnet wird).
Unterm Strich ne gute Idee, denke ich, Intel verbrät für die 512bit viel Die-Fläche und Datenleitungen. Pro Takt 3x256 anstatt 2x512bit einzulesen, dürfte die elegantere Lösung in Sachen Perf/Watt sein.
zumal die Taktrate mit AVX512 auch noch weit, weit zurück geht und der Verbrauch gleichzeitig stark ansteigt. Ist zwar beschleunigt immer noch schneller als unbeschleunigt bei vollem Takt, aber das Zeigt auch schon gut, das es hier nicht so wahnsinnig viel zu holen gibt. Dann lieber AVX256 Beschleunigung verbessern und halt mehrere Takte für die Ausnahmefälle benötigen. Zumindest zum aktuellen Zeitpunkt sehe ich keinen Sinn darin dieses Randthema zu beschleunigen. Im schlimmsten Fall erschlägt man das Thema derzeit auch ganz gut einfach mit mehr Cores.

Complicated

2019-11-26, 17:18:30

Wenn man dann noch bedenkt, dass Intel mit AVX512 auch nur den GPGPU Lösungen hinterher rennt und es dennoch nicht etablieren kann.
Gut möglich, dass AVX512 mit erscheinen der Intel GPUs auch einen Abschied erhält aus der CPU.

Berniyh

2019-11-26, 18:03:33

Intel pusht das doch auch nur, da sie hier einen exklusiven Vorteil haben.
Wenn AMD in Sachen AVX512 aufschließen würde, dann wäre das vermutlich plötzlich wieder uninteressant.

Da sich die Anzahl derartiger Anwendungen eh in Grenzen hält lässt man die Implementierung vermutlich lieber gleich sein.
Zumindest solange bis sich abzeichnet, dass es breitflächiger eingesetzt werden wird.

gravitationsfeld

2019-11-26, 18:55:22

Felixxz2

2019-11-26, 21:18:58

Tatsächlich gab es jetzt mit Massive X die erste Audio Software die AVX zwingend erfordert. In dem Bereich dürften aber auch wenige Pentiums unterwegs sein.

gravitationsfeld

2019-11-27, 04:33:20

Klar, aber schau dir mal den Shitstorm an den Ubisoft wegen AC Odyssey gefangen hat. Das lief am Anfang nur mit AVX.

So langsam kann man wahrscheinlich SSE 4.2 verlangen, dann laufen halt Phenoms nicht mehr.

S940

2019-11-27, 07:48:54

AVX ist ohnehin praktisch nicht verwendbar, weil sich Intel seit Jahren weigert es in ihren Pentiums zu aktivieren.

Die meiste Software verwendet einen Befehlssatz wenn 95+% der CPUs damit zurecht kommen. Das ist bei AVX anscheinend Jahrzehnte in der Zukunft.Ja, wobei durch Zen jetzt auch mehr Konkurrenz im Billigsegment aufkommt. Dort schaltet AMD bei den Athlons alles frei, selbst AVX2. Vielleicht übt das ja etwas Druck auf Intel aus, auch wenn Leistung oder Befehlssätze in dem Segment eigentlich total egal sind.

Benutzername

2019-11-27, 08:28:11

Ja, wobei durch Zen jetzt auch mehr Konkurrenz im Billigsegment aufkommt. Dort schaltet AMD bei den Athlons alles frei, selbst AVX2. Vielleicht übt das ja etwas Druck auf Intel aus, auch wenn Leistung oder Befehlssätze in dem Segment eigentlich total egal sind.

Das würde Ich nciht so sagen. Selbst so ein bescheidener Athlon 3000G kann davon profitieren AVX Befehle zu verarbeiten und so zum Beispiel Mathe schneller zu machen. Oder andere Fließkomma lastige Sachen. Halt alles wo SIMD hilft.

S940

2019-11-27, 08:55:32

Das würde Ich nciht so sagen. Selbst so ein bescheidener Athlon 3000G kann davon profitieren AVX Befehle zu verarbeiten und so zum Beispiel Mathe schneller zu machen. Oder andere Fließkomma lastige Sachen. Halt alles wo SIMD hilft.
Na klar, aber wer sich ne 50 Euro CPU kauft, wird solche Sachen damit kaum einsetzen wollen. Das sind dann zu 99% nur Bürokisten für Internet und Office.

Screemer

2019-11-27, 09:03:35

Gipsel

2019-11-27, 09:44:17

Gibt halt genug laborkisten oder studilaptops auf denen z.b. mathlab läuft. Das könnte sicherlich auch profitieren.Könnte, wenn Matlab nicht den AVX-Support nur auf intel-CPUs nutzen würde (liegt an der benutzten MKL-Bibliothek, die standardmäßig nur bei intel CPUs die erweiterten Befehlssätze nutzt). :rolleyes:

Edit:
https://www.computerbase.de/2019-11/mkl-workaround-erhoeht-leistung-auf-amd-ryzen/

S940

2019-11-27, 10:04:50

Gibt halt genug laborkisten oder studilaptops auf denen z.b. matlab läuft. Das könnte sicherlich auch profitieren. Dem durchschnittliche Nutzer wäre aber nicht einmal klar, dass seine CPU das nicht nutzt geschweige denn was es ist.
Ja, aber wer solche Spezialsoftware einsetzt, sollte sich halbwegs auskennen. Laptops oder Desktops mit i3 sind jetzt auch nicht gerade sündhaft teurer. Man muss halt wissen, was man braucht und das Wissen sollte bei Mathlab-Anwendern und anderen Professionals ausgeprägter sein, als bei nem kaufmännischen Angestellten.

Felixxz2

2019-11-27, 12:11:57

][immy

2019-11-27, 12:20:01

Verstehe auch ehrlich gesagt nicht wo da bei Spielen wie Assassins die Entrüstung herkommt. AVX gibts seit Sandy....
Bei uns im Audiosektor juckt das zb keinen, da setzen aber eh viele Macs ein was Gammel-CPUs schonmal ausschließt.
Naja, die erste Core i Generation ist nicht zu verachten. Trifft man noch häufig drauf und ist noch ziemlich flott (und bekommt man sehr günstig).
Dann gibt es noch die ganzen Pentium-System die auch von Casual Spielern gern gekauft werden. Von Celeron & Atom CPUs möchte ich gar nicht erst anfangen.

Bei No Man's Sky (und ich mein auch Elex) gab es einen Aufschrei von Phenom Nutzern. Auch diese wurden dann später bedient. Meist ist es ja nur eine kleine Compiler-Einstellung ohne das sich wirklich relevantes tut. Klar würde man als Entwickler gern so viele alte CPUs loswerden wie möglich (weniger Testaufwand) aber letztlich will man halt die Kundschaft nicht ausschließen. Und es hat sich in den letzten 10 Jahren erstaunlich wenig getan in Sachen CPU-Geschwindigkeit. Klar gibt es unterschiede, ist aber nichts im Vergleich zu den 10 Jahren davor (oder davor). Beispielsweise hat mein Sohn auch noch nen Core 2 quad. Reicht für alles mögliche, außer vielleicht für neuere Spiele. Der größte Unterschied entsteht halt durch die SSD, aber sonst kann er daran alles machen, außer eventuell die neusten Spiele spielen.
Im Mac Bereich wird gern mal "alte" (aber an sich noch ausreichende) Hardware vergessen. Einer der Gründe warum Apple relativ wenig Wartungsaufwand (im vergleich zu MS) hat.

mboeller

2019-11-27, 13:11:24

Ja, wobei durch Zen jetzt auch mehr Konkurrenz im Billigsegment aufkommt. Dort schaltet AMD bei den Athlons alles frei, selbst AVX2. Vielleicht übt das ja etwas Druck auf Intel aus, auch wenn Leistung oder Befehlssätze in dem Segment eigentlich total egal sind.

Intels neue Microarchitekture "Tremont" hast du aber schon mitbekommen, oder?

https://semiaccurate.com/2019/10/24/intel-outs-the-tremont-atom-core/

Tremont doesn’t have AVX at all, not in vanilla, AVX2, or AVX-512 formats

S940

2019-11-27, 15:43:19

Intels neue Microarchitekture "Tremont" hast du aber schon mitbekommen, oder?
Klar, ändert aber nichts an der Tatsache, dass AMD im Billigsegment AVX bietet. Selbst als AMD noch ne eigene Billig-Architektur hatten, wurde das angeboten.

Wobei man auch darüber streiten kann, ob Atom und Nachfolger noch Billigsegment sind, oder nicht schon Ultra-Billigstsegment. Die Dinger richten sich mMn eher gegen ARM-Kerne.

Opprobrium

2019-11-27, 16:05:46

Wobei man auch darüber streiten kann, ob Atom und Nachfolger noch Billigsegment sind, oder nicht schon Ultra-Billigstsegment. Die Dinger richten sich mMn eher gegen ARM-Kerne.
Richten sich nicht viel mehr die ARM-Kerne mittlerweile gegen Atom & Co?

Berniyh

2019-11-27, 16:22:46

Das würde Ich nciht so sagen. Selbst so ein bescheidener Athlon 3000G kann davon profitieren AVX Befehle zu verarbeiten und so zum Beispiel Mathe schneller zu machen. Oder andere Fließkomma lastige Sachen. Halt alles wo SIMD hilft.
Das stimmt, aber wenn es die CPU am Ende signifikant verteuert (z.B. wg größerer Chipfläche), dann ist es ggf. auch wieder keine Option, da gerade in dem Segment Kosteneffizienz über alles geht (bzw. gehen muss), sonst lohnt sich das einfach nicht.

robbitop

2019-11-27, 16:45:55

Ach iwo. Man schaue mal wie winzig heutige Big Cores sind. Die kleinen Kerne ja noch mehr. Und wie groß ist daran der Anteil von AVX/2? Der Anteil am Gesamt SoC ist sicherlich unter 1 sqmm heutzutage.

Das sind Eigenschaften zur Produktdifferenzierung. AMD ändert hier gerade die Spielregeln. Volles Instructionset, SMT, freier Multiplikator für 50€.
Sowas wie K CPUs gibt es bei AMD praktisch nicht. Einschränkung von PCIe Lanes im HEDT auch nicht.
Das wird bei Intel sicherlich auch kommen. Genau AVX2. In der nächsten großen uArch wird das sicher kommen. Deren P/L ist ja seit Zen auch deitlich besser geworden. Ein Hoch auf den Wettbewerb!

KarlKastor

2019-11-27, 16:51:50

Intels neue Microarchitekture "Tremont" hast du aber schon mitbekommen, oder?

https://semiaccurate.com/2019/10/24/intel-outs-the-tremont-atom-core/

Das sind doch zwei paar Schuhe, ob ich bei der schlanken Architektur ein paar Transistoren spare und auf AVX pfeife, oder ob ich die bei Core basierten Einsteigerprodukten künstlich beschneide.
Letzteres macht mittlerweile wenig Sinn, da man die Produkte über die Kerne auch so schön gut genug differenziert hat. Bei der nächsten Gen, können sie dann AVX512 als Feature für die Core i lassen.

Gipsel

2019-11-27, 17:12:57

Das sind doch zwei paar Schuhe, ob ich bei der schlanken Architektur ein paar Transistoren spare und auf AVX pfeife, oder ob ich die bei Core basierten Einsteigerprodukten künstlich beschneide.
Letzteres macht mittlerweile wenig SinnEs macht beides wenig Sinn, wie z.B. robbitop gerade erklärt hat. Auch AMDs Jaguar konnte (und kann) das und da maß ein Kern auch schon nur noch 3,1mm². In 28nm wohlgemerkt. In 7nm wäre der komplette Kern wohl unter 1mm². Und auf das Konto der AVX-Unterstützung würde davon vermutlich eine Handvoll Quadrat-Mikrometer entfallen. :freak:

Setsul

2019-11-27, 17:26:27

Also bei SKL-SP sind es etwas über 2 mm² für die FPU. Bei 8 mm² für den ganzen Kern ist das schon einiges. LSU und Cache brauchen bei vierfacher Bandbreite auch mehr Platz und Strom und die kann man im Gegensatz zu den FUs nicht powergaten. Also bei Atom mit 3 mm² für den gesamten Kern ist es schon verständlich auf 256/512 bit FPUs zu verzichten.

Cat cores waren weniger eine Billigarchitektur als eine Notlösung weil Bulldozer so verdammt ineffizient war. Damit gabs 25W APUs während jetzt Zen alles bis runter auf 12W abdeckt. Atom ist eine Stufe tiefer.
Erst Jaguar hat eine 128 bit FPU und AVX bekommen (Xbox/PS mit half-speed SSE wäre nicht so toll gewesen) und schon Bobcat hatte das AMD MOps-Format mit dem das aufteilen in 2 half-width uops geht. Für Intel wäre es teurer gewesen das zu implementieren und ergibt natürlich keinen Sinn wenn man schon bei Pentium/Celeron AVX ausschaltet für die Marktsegmentierung.

AVX für Atom bleibt unwahrscheinlich, extra Aufwand und Kosten und geringere Effizienz für was?
Aber die Marktsegmentierung bei Pentium/Celeron wackelt. SMT gibts mittlerweile weil Cores/Threads eben nach oben gehen dank Konkurrenz, Multiplikator hat sich gehalten und wird wohl auch so bleiben, in welche Gruppe AVX fällt wird man sehen.

Es hängt auch davon ab ob in dem Segment AVX für die Leistung nötig ist oder nur damit das Programm überhaupt läuft. Wenns um Leistung geht würde Intel sicherlich gerne etwas schnelleres, teureres verkaufen. Unter 100$ hält sich der Preiskampf mit AMD auch in Grenzen. Aber wenn die Leistung so oder so ausreicht und die Wahl ist zwischen 50$ Intel CPU auf der die Hälfte der Programme die man braucht nicht läuft, 100$ Intel CPU die schneller ist als nötig aber auf der alles läuft und 50$ AMD CPU auf der auch alles läuft...

Gipsel

2019-11-27, 17:32:36

Tremont hat z.B. 128bit L/S-Pipes und (wie die komplette Atom-Reihe schon seit einiger Zeit) auch 128Bit Vektoreinheiten, genau wie Jaguar. Die prinzipielle Unterstützung von AVX ist damit im Prinzip mit ein paar minimalen Erweiterungen in den Decodern machbar. Niemand redet ja davon, daß man damit neue Performancerekorde aufstellen will. Aber der Support aus Kompatibilitätsgründen ist schon ein gewichtiges Argument (genau der, der hier aus Entwicklersicht dargelegt wurde). Und die Kosten der Implementation sind beinahe Null und gehen im Rauschen unter.

gravitationsfeld

2019-11-27, 18:05:34

Berniyh

2019-11-27, 18:42:20

Das sind Eigenschaften zur Produktdifferenzierung. AMD ändert hier gerade die Spielregeln. Volles Instructionset, SMT, freier Multiplikator für 50€.
Sowas wie K CPUs gibt es bei AMD praktisch nicht. Einschränkung von PCIe Lanes im HEDT auch nicht.
Das wird bei Intel sicherlich auch kommen. Genau AVX2. In der nächsten großen uArch wird das sicher kommen. Deren P/L ist ja seit Zen auch deitlich besser geworden. Ein Hoch auf den Wettbewerb!
Das bleibt abzuwarten, so richtig glaube ich noch nicht dran.

Die Sache ist, dass bei AMD in Relation zum Umsatz ein neues Design einen größeren finanziellen Aufwand bedeutet, entsprechend mehr wird dann recycled.
Davon profitieren natürlich dann auch die Endanwender, da man Features aus den großen Prozessoren ebenfalls bekommt.

Bei Intel sieht das aber eben anders aus, eben weil der Absatz derartiger Produkte schon sehr hoch ist.

Wo ich zustimme ist dein Absatz zu HEDT (auch wenn hier AMD ja auch Produkte im Portfolio hat bei welchen die Zahl der PCI Express Lanes beschränkt ist).
Aber hier kann AMD im Grunde eh machen was sie wollen, Intel hat ja nichts ernsthaft entgegen zu setzen.

S940

2019-11-27, 19:41:50

Tremont hat z.B. 128bit L/S-Pipes und (wie die komplette Atom-Reihe schon seit einiger Zeit) auch 128Bit Vektoreinheiten, genau wie Jaguar. Die prinzipielle Unterstützung von AVX ist damit im Prinzip mit ein paar minimalen Erweiterungen in den Decodern machbar. Niemand redet ja davon, daß man damit neue Performancerekorde aufstellen will.
So siehts aus. Eigentlich sollte AMD mal nem Praktikantenteam Jaguar auf 7nm shrinken lassen und Intel den vor den Latz knallen. So was wär im Low-End/Low-Powerformat vermutlich immer noch bestens konkurrenzfähig.

Wenn man etwas mehr Aufwand treiben möchte, könnte man noch nen µCode-cache einschleussen. Es spart ja auch gut Strom, wenn sich wiederholende Befehle nicht jedesmal neu dekodiert werden müssen.

robbitop

2019-11-27, 19:48:31

Naja Tremont sollte taktnormiert schon ein gutes Stück schneller sein als Jaguar.

Außerdem sind Zen Kerne auch nicht gerade groß. Cache, I/O etc scheint relativ gesehen wesentlich mehr Fläche und damit Fertigungskosten zu fressen.
Außerdem könnte man mit Zen ggü Jaguar/Tremont im Gegenzug auf die Hälfte der Kerne sparen und trotdem in den meisten Anwendungen schneller sein.
IMO gibt es eigentlich keinen richtigen Grund mehr eine kleine extra uArch. Es sei denn man möchte in der TDP nochmal deutlich unter 10W skalieren bei anständiger Perf/W. Der Markt dafür ist bei x86 aber auch stark begrenzt.
Die meisten Atom Cores werden eher in Billiggeräten verkauft.

BoMbY

2019-11-27, 19:53:47

Naja Tremont sollte taktnormiert schon ein gutes Stück schneller sein als Jaguar.

Ja, nur der 10nm Prozess sollte auch schon seit Jahren funktionieren. Bleibt abzuwarten ob das Ding was kann, oder nicht.

robbitop

2019-11-27, 19:55:15

Tremont? Im Rahmen seiner Lowcost Möglichkeiten. Nicht unwerfend aber dafür billig.

Setsul

2019-11-27, 20:31:20

@Gipsel:
Ich glaube nicht, dass das was AMD so gerne macht mit dem uop-Format bei Intel funktioniert. Die Kosten werden schon mehr als Null sein. Leisten könnten sie sich das natürlich trotzdem locker.

@S940:
Es ist aber wahrscheinlich der unwichtigste Markt. Alles andere an dem AMD Leute arbeiten lassen kann bringt mehr als Intel Marktanteil bei den 30$ Tablet-SoCs zu klauen.

Complicated

2019-11-27, 21:00:52

Kein ECC-Support für Desktop-Prozessoren ist angesichts von Rowhammer die größte Frechheit.
ECC bringt bei Rowhammer nicht viel.

Rowhammer-Angriff funktioniert auch mit ECC (https://www.golem.de/news/eccploit-rowhammer-angriff-funktioniert-auch-mit-ecc-1811-137863.html)

BoMbY

2019-11-27, 21:16:35

S940

2019-11-27, 21:19:51

Naja Tremont sollte taktnormiert schon ein gutes Stück schneller sein als Jaguar.
Mag sein, aber wie viel? Richtig interessieren tuts in dem Segment auch keinen, Batterielaufzeit ist wichtiger.
Außerdem sind Zen Kerne auch nicht gerade groß. Cache, I/O etc scheint relativ gesehen wesentlich mehr Fläche und damit Fertigungskosten zu fressen.

Jein. Bis Zen1 wäre ich dem Argument noch gefolgt, aber Zen2 mit der 256bit FPU ist jetzt ein Stückchen zu groß. Zen3 soll nochmal nachlegen, das wird dann sicherlich noch komplexer.

Wobei Zen2s L1I-Cache kleiner wurde ... naja ist am Ende die Frage, welches Design man als Ausgangspunkt hernimmt. Tunt man Jaguar, oder speckt man Zen ab?

Aufgrund der immer höheren Leakage-Raten muss man bei Low-Powerarchitekturen halt einfach weniger Transistoren verbauen. Die Spar-FPU von Jaguar fand ich deshalb schon ganz gut.

Die meisten Atom Cores werden eher in Billiggeräten verkauftSi claro, aber wieso sollte man Intel diesen Markt lassen? In dem Bereich macht es die Masse und ein Low-Power-Design braucht nocht viel Know-How.

Complicated

2019-11-27, 21:45:45

Müsste nicht eigentlich schon transparente Speicherverschlüsselung wie bei Zen Rowhammer Einhalt gebieten? Man kann zwar immer noch Bits kippen, aber eigentlich nicht mehr sinnvoll lesen und/oder ändern.Teilweise...SME alleine nicht.

https://arstechnica.com/gadgets/2019/08/a-detailed-look-at-amds-new-epyc-rome-7nm-server-cpus/2/

Rome hat hier scheinbar eine Weiterentwicklung:
Secure Encrypted Virtualization (SEV) takes the SME concept a step further by allowing individual AES-128 keys to be allocated to virtual machines running underneath an Epyc processor. The first-generation Epyc only supported 15 separate keys; Rome extends this to support for 509 total keys. Rome also adds a completely new feature, Secure Encrypted Virtualization—Encrypted State (SEV-ES). With SEV-ES, a virtual machine's entire CPU state (primarily, the contents of hardware registers) can also be encrypted, with keys inaccessible either to other guests or to the host VM itself.

robbitop

2019-11-27, 22:16:41

Mag sein, aber wie viel? Richtig interessieren tuts in dem Segment auch keinen, Batterielaufzeit ist wichtiger.

Jein. Bis Zen1 wäre ich dem Argument noch gefolgt, aber Zen2 mit der 256bit FPU ist jetzt ein Stückchen zu groß. Zen3 soll nochmal nachlegen, das wird dann sicherlich noch komplexer.

Wobei Zen2s L1I-Cache kleiner wurde ... naja ist am Ende die Frage, welches Design man als Ausgangspunkt hernimmt. Tunt man Jaguar, oder speckt man Zen ab?

Aufgrund der immer höheren Leakage-Raten muss man bei Low-Powerarchitekturen halt einfach weniger Transistoren verbauen. Die Spar-FPU von Jaguar fand ich deshalb schon ganz gut.

Si claro, aber wieso sollte man Intel diesen Markt lassen? In dem Bereich macht es die Masse und ein Low-Power-Design braucht nocht viel Know-How.

Ein Zen 2 Chiplet ist winzig. Und da sind 2x CCX und fettig Cache drauf.
Für Low Cost kann man auch 2c/4t machen und eine kleine Vega mit 2-3 CUs. Das sollte klein genug werden. Insbesondere mit 7nm+.
Oder man verkauft einen solchen Prozessor immer von der Vorgänger uArch. Dann ist es noch kleiner. Oder Vorgänger uArch und alter Prozess. Ist dann zwar etwas größer - aber kann dennoch billiger sein da die Waferkosten alter Prozesse deutlich billiger sind.

IMO braucht AMD keine extra uArch. Das kann man IMO alles mit einer beliebigen Zen Iteration abdecken. Halt mit weniger Kernen/GPU-/IO-Ressourcen.

gravitationsfeld

2019-11-27, 22:42:02

ECC bringt bei Rowhammer nicht viel.

Rowhammer-Angriff funktioniert auch mit ECC (https://www.golem.de/news/eccploit-rowhammer-angriff-funktioniert-auch-mit-ecc-1811-137863.html)
Der Angriff dauert wesentlich laenger und ist wesentlich unpraktikabler. Das steht da auch.

Complicated

2019-11-27, 23:26:36

Nur dass ECC diesen Seitenkanal-Angriff überhaupt erst möglich macht durch die Latenz bei der Fehlerkorrektur.
Ändert ja nichts daran, dass es dadurch nicht geschloßen wird. SME und SEV sind da schon deutlich hilfreicher als ECC.

Eldoran

2019-11-28, 20:21:33

Ja gegen das Ausspionieren über Rowhammer hilft am besten Verschlüsselung, was derzeit am Desktop glaube ich nur Ryzen Pro bietet. ECC hilft primär dagegen, dass Rowhammer den Rest zum Absturz bringt, sowie allgemein gegen Abstürze/Datenfehler durch Lesefehler oder defektes RAM.
Wie SME/SEV bezüglich Spectre wirkt ist eine gute Frage, ich habe dazu eigentlich nichts explizites gefunden.

Zossel

2019-11-29, 17:58:10

Aufgrund der immer höheren Leakage-Raten muss man bei Low-Powerarchitekturen halt einfach weniger Transistoren verbauen. Die Spar-FPU von Jaguar fand ich deshalb schon ganz gut.

Für Wireguard zieht das Ding passiv gekühlt gut was weg: https://www.pcengines.ch/apu4c4.htm

Semmel

2019-11-29, 20:36:50

Mal eine ganz andere Frage: Meint ihr, es wird für den Zen 3 neue AM4-Chipsätze geben?
Also z.B. einen X670?
Oder könnte der X570 der letzte AM4-Chipsatz gewesen sein?

BoMbY

2019-11-30, 09:51:33

Es wird sicher neue geben, vermutlich dann mit USB4. Außerdem könnte es auch bald mal einen neuen Sockel geben, mit ein paar mehr PCIe Lanes. AMD muss auch die MB-Hersteller befriedigen.

Sweepi

2019-11-30, 11:26:28

Screemer

2019-11-30, 11:34:17

ot: mach mal ein außen rum. da kannst du dir einen haufen zeichen sparen.

KarlKastor

2019-11-30, 12:08:57

Es wird sicher neue geben, vermutlich dann mit USB4. Außerdem könnte es auch bald mal einen neuen Sockel geben, mit ein paar mehr PCIe Lanes. AMD muss auch die MB-Hersteller befriedigen.
Glaube ich nicht. Außer dem x570 gibt's in drei Generationen bisher nur die Ursprungs Southbridge ein paar mal umbenannt und refreshed.

Berniyh

2019-11-30, 12:16:14

OffTopic:
Will eigentlich auf Zen3 / Ryzen 4000 umsteigen, scheint aber potenziell ein ungünstiges "Zwischen-" Jahr zu werden, mit wenig Verbesserungen bei Zen3, keine Konkurrenz von Intel (10 nm / 7 nm Desktop CPUs erst 2021), und dann ein toter AM4 Sockel, 2021 dann neuer AM5(?) Sockel mit DDR5 und maybe PCIe 5 Support.
AM5 wird vermutlich erst 2022 kommen, wenn es gut läuft evtl. Ende 2021.
Sind also eher noch 2 Jahre bis dahin.
Abgesehen davon ist AM4 jetzt bewährt, DDR4 Speicher ist günstig und so viel wird der Sprung auf PCIe 5.0 real betrachtet auch wieder nicht bringen.
PCIe 4.0 auszulasten ist jetzt schon relativ schwer. Die Grafikkarten brauchen es nicht und die SSDs sind mit PCIe 4.0 schon schnell genug.
Da von PCIe 5.0 zu profitieren (ohne dass die SSDs anfangen zu kochen) wird sportlich.
DDR5 wird natürlich schon ein Vorteil sein aber zu Beginn bestimmt noch ziemlich teuer.
Insofern denke ich, dass Zen2 und Zen3 schon eine gute Basis sind.
Auf AM5 lieber dann 2023 oder 2024 wechseln mit Zen5(?) und günstigerem DDR5 Speicher.

Und die Sache mit der Anzahl der PCIe Lanes ist eine nette Idee, aber eigentlich genügen die jetzigen PCIe Lanes vollkommen, wenn als 4.0 ausgeführt.

HOT

2019-11-30, 14:40:05

OffTopic:
Will eigentlich auf Zen3 / Ryzen 4000 umsteigen, scheint aber potenziell ein ungünstiges "Zwischen-" Jahr zu werden, mit wenig Verbesserungen bei Zen3, keine Konkurrenz von Intel (10 nm / 7 nm Desktop CPUs erst 2021), und dann ein toter AM4 Sockel, 2021 dann neuer AM5(?) Sockel mit DDR5 und maybe PCIe 5 Support.

OnTopic:
Gibt es Hinweise auf einen AM4+ Sockel?
Beim Wechsel von AM2 auf AM3 lief es ja folgendermassen:
Sockel | Supported CPUs
AM2 | AM2, AM2+
AM2+ | AM2, AM2+, AM3 (AM3 mit leichten Einschränkungen)
AM3 | AM2+, AM3

Edit: dem Forum fehlt ein ASCII-(Art-)Modus.
Edit2: Danke @Screemer
AM3 unterstützt keine AM2+-CPUs. Zudem unterstützt AM2 auch AM3 CPUs, aber eben ohne separate I/O-Spannung und AM2+ untersützt AM3-CPUs vollumfänglich, aber keine von denen unterstützt AM3+.
Außerdem fehlt AM3+ zu AM3

Also ganz korrekt:
AM2 Sockel -> AM2, AM2+ und AM3-CPUs (AM3 und AM2+ ohne separate I/O-Spannung, fast immer aber kein Thuban-Support)
AM2+ Sockel -> AM2, AM2+ und AM3-CPUs (seltener kein Thuban-Support)
AM3 Sockel -> AM3 (und AM3+ bei manchen Mobos)
AM3+ Sockel -> AM3 und AM3+

AM5 kommt mMn sehr sicher mit einem Zen3-Refresh in 2021. Dann gibts einfach ein neues I/O-Die, das mit Zen3-Chiplets gepaart wird. Zen4 ist einfach noch zu weit weg. Überlappenden Support wird auch auch nicht mehr geben, AM4 nur mit dem alten I/O und alle bis 2021 erscheinenden APUs und alles ab dem neuen I/O-Chip wird AM5 sein und APUs ab 2022.

Sweepi

2019-11-30, 15:41:17

@Hot: Hast Recht. Fuer die Interessierten:

https://en.wikipedia.org/wiki/Socket_AM2
https://en.wikipedia.org/wiki/Socket_AM2%2B
https://en.wikipedia.org/wiki/Socket_AM3
https://en.wikipedia.org/wiki/Socket_AM3%2B

Ganz vergessen das FX (Bulldozer etc) AM3+ war...

Tesseract

2019-11-30, 16:26:15

Gibt es Hinweise auf einen AM4+ Sockel?

wird ziemlich sicher nicht kommen. laut david mcafee von AMD wären die gründe von AM4 weg zu gehen grundlegende änderungen an der funktionsweise von PCIe oder DDR.
heißt im klartext: AM5 kommt ab ~2021 mit DDR5 und bis dahin gibt es scheinbar keinen grund was zu ändern.

Screemer

2019-11-30, 16:30:46

Das heißt aber nicht, dass das pinout der zen3 CPUs mit aktuellen Boards kompatibel sein muss. Trx4 ist für mich auch ein tr4+ bzw. sind es ja SP3r2 und SP3r3. Physikalisch würde da auch naples und rome passen. Laufen aber halt nicht.

Tesseract

2019-11-30, 16:48:19

es gab von AMD keine aussage bzgl. TR4 soweit ich weiß. außerdem haben sie gesagt AM4 bleibt abwärtskompatibel bis inkl. 2020.
ich sehe echt nicht wo da ein AM4+ reinpassen sollte.

Screemer

2019-11-30, 16:54:00

sie haben gesagt, dass sie am4 weiterhin nutzen werden. eine zusage für cpus gab es imho nie. physisch kann das ja am4 sein. tr4 hat auch das gleiche physische layout wie strx4.

ich will damit nicht sagen, dass es so kommen wird. es soll sich nur keiner beschweren, wenn dem so ist. um so mehr kann man sich freuen wenn ryzen 4xxx auf einem alten b350/x370 board läuft. ob sie das allerdings in den 16mb chips der alten 3xx-chipsatz-biose unterbringen ohne support für alte cpu zu streichen ist dann die nächste frage.

Tesseract

2019-11-30, 16:59:26

"AMD says it plans to keep offering that kind of backward compatibility through 2020 and for the foreseeable future, instead of making you buy a new board alongside your next CPU upgrade. “It will really take a major inflection point in the platform technology for us to move off of socket AM4,” says AMD’s David McAfee, adding that it would probably take a major change in how memory or PCI expansion slots work before AMD needs to move to a new socket." (https://www.theverge.com/2019/6/10/18660213/amd-ryzen-9-3950x-16-core-gaming-cpu-processor-e3-2019)

Nightspider

2019-11-30, 18:29:17

Ich glaub in einem 300-400 Euro Netbook hätte ich auch lieber einen einzelnen vollwertigen Zen 2 Kern mit 4,2 Ghz Boost und SMT als irgendwelche Atom QuadCores oder Octacores.

Und für die meisten Ultrabooks bzw. extrem portablen Notebooks reichen imo auch 2 normale Kerne mit SMT und hohem Boost.

Diese Pseudoarchitekturen für dazwischen erschließen sich mir nicht.

Atom war vielleicht verbreitet aber nicht sehr beliebt und eher gehasst.

Dann lieber noch den L3 Cache halbieren der dicken Kerne und gut ist. Das spart genug Platz.

Mir stellt sich höchstens noch die Frage ob der große L3 nicht sogar wichtiger ist wenn in Laptops nur so schnarchlangsamer Arbeitsspeicher verbaut wird, im schlimmsten Fall im Single Channel.

Bezüglich AM4:
Worauf wäre denn zu achten wenn ich ein B450 oder X470 Mainboard kaufen will und plane Zen 3 drauf zu schnallen?
Da brauch ich doch wahrscheinlich nur die 32 MB-BIOS-Bausteine drauf oder?

Glaube PCI Gen 4 wird auch nächstes Jahr noch relativ unwichtig bleiben.

Laufen Intels Optane SSDs (PCIe) eigentlich auch auf der AMD Plattform? Oder müsste man dann auf die Micron X100 SSD warten?
Wobei man für Letztere auch einen vollen PCIe 3.0 16x Slot bräuchte. :uponder: