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

We speak with Mike Clark, Chief Architect of Zen, and Sam Naffziger, Corporate Fellow, about the AMD Ryzen architecture.
https://www.youtube.com/watch?v=Jdi5JmRmez8

Auszüge aus dem Interview: http://www.gamersnexus.net/news-pc/...chief-architect-mike-clarke-and-sam-naffziger
x86 decode, the variable length instructions, are very complex -- requires a ton of logic. I mean, guys make their career doing this sort of thing. So you pump all these x86 instructions in there, burns a lot of power to decode them all, and in our prior designs every time you encounter that code loop you have to go do it again. You have this expensive logic block chunking away. Now we just stuff those micro-ops into the op-cache, all the decoding done, and the hit-rate there is really high [Clark: up to 90% on a lot of workloads], so that means we’re only doing that heavy-weight decode 10% of the time. It’s a big power saver, which is great. The other thing we did is the write-back L1 Cache. We aren’t consistently pushing the data through to the L2, there are some simplifications if you do that, but we added the complexity of a write-back so now we keep stuff way more local. We’re not moving data around, because that wastes power.

One of the things that I highlighted earlier today is the effort the team put in to squeeze down the overhead power. In a CPU core, these things running over 4GHz, very hard to get the clocks out to all those billions of transistors with picosecond accuracy. Takes a lot of wires, a lot of big drivers to do that. We invest a ton of engineering to optimize that down and cut 40% out of that clock network. We’d worked really hard cutting power out in prior generations, but we got 40% more this time. We also optimized the sequential elements that move the data in between the logic. They’re kind of like the glue that holds the logic together. We optimized the crap out of those things, made them really small and power efficient, and the net is that when you look at the power breakdown for the core -- most processors, you have clock power, sequential power, the little bit that’s the logic gates doing actual work.”
 
Zuletzt bearbeitet:
Hat jemand schon von einem Fix für https://community.amd.com/message/2796982 gehört? Klingt ziemlich übel.

Ist bestätigt, wird untersucht, AMD zuversichtlich, Fix wahrscheinlich.
Betrifft aber ohnehin nur Linux.

Ein AMD-Mitarbeiter hat einen Fehler bestätigt, wonach es beim Kompilieren von Linux-Anwendungen zu Abbrüchen aufgrund von Segmentation Faults kommen kann. Betroffen sind Ryzen-Prozessoren für AM4-Mainboards.

ThreadRipper und EPYC sind nicht betroffen.

Das Problem tritt dabei ausschließlich unter Linux und beim Verwenden eines Prozessors aus der Ryzen-Consumer-Reihe auf. Windows-Nutzer sind nicht betroffen. c't konnte die Segmentation Faults mit einem Ryzen 7 1800X auf der AM4-Plattform unter Linux nachstellen. Mit Server-Prozessoren mit Zen-Architektur (AMD Epyc) treten keine SegFaults auf, wie c't ebenfalls verifizieren konnte. Linux-Nutzer mit Ryzen-Prozessoren können mit dem Skript kill-ryzen.sh (GitHub) entsprechende Fehler nachstellen. Zum Ausführen des Skripts sollte das System aber mindestens 16 GByte Arbeitsspeicher haben.

AMD bestätigte gegenüber der Linux-Website Phoronix außerdem, dass auch Threadripper-Prozessoren nicht betroffen sein sollen. Die Probleme sollen außerdem unabhängig vom verwendeten AM4-Mainboard auftreten.
 
Wirklich alltäglich scheint das aber nicht zu sein, ich mach mir da keinen Stress. Ich werde mir nicht extra ein Skript herunterladen, damit ich den Fehler auch erleben darf.

WSL ist übrigens nicht das, was die Leute unter "Windows" verstehen. Sonst müsste man bei jedem Linux-Bug von einem Fehler in beiden Systemen sprechen.
 
Zuletzt bearbeitet:
Nein!
Wurde schon im April von DragonflyBSD an AMD gemeldet. Ist also nichts Neues. Das steht sogar im c't-Artikel! Für FreeBSD gibt es einen Workaround. WSL von Windows ist auch betroffen. Qualitätsjournalismus ...

Klar, der Fehler ist schon etwas älter, wird aber eben erst jetzt auch also solcher akzeptiert (von AMD bestätigt), da reproduzierbar.
Ich kompiliere täglich, und mir ist der noch nicht begegnet.

Das war ja auch nur eine Antwort von mir auf die Frage, ob es einen Fix geben wird, und das ist durch diesen Verlauf jetzt wahrscheinlicher geworden.
Das ist die News, nicht der "Fehler" an sich ...
 
sag das der c't ;)
Ich hab das nur so wiedergegeben.
 
pcper hat die Speicherlatenzen von TR gemessen:
https://www.pcper.com/reviews/Proce...0X-Review/NUMA-and-UMA-memory-locality-concer

Je weiter entfernt in der Hierarchie die kommunizierenden CCX sind, desto stärker sinken die Latenzen mit schnellerem RAM (=Interconnect).

Die Messung bestätigt aus meiner Sicht auch, dass bereits ein einzelner Ryzen-Chip NUMA-Eigenschaft hat, da die Latenzen zwischen 2 CCX auf dem Chip sich von denen zwischen 2 Chips und von denen innerhalb eines CCX deutlich unterscheiden.
 
Michael Larabel von Phoronix hat zufällig entdeckt, dass er noch ein System mit Athlon II X3 425 (3x 2.7 GHz) im Fundus hat. Bevor das rausgeflogen ist, hat er eine Reihe von Benchmarks gegen den Ryzen 3 1200 und 1300X gefahren. Darunter Sachen wie FFmpg (Videokonvertierung), SQLite (Firefox-Datenbank), JPEG-Dekodierung, die Bildbearbeitung GIMP ...

Zwar ist der Athlon mit seinerzeit 65 € nicht preisgleich, dennoch ist der Test nett zu lesen und vor allem für "Ich brauch nichts schnelleres"-Fans empfehlenswert. Benchmarks gegen die Vor-Vorgänger sind ja nicht so häufig. Zumal hier die Software-Versionen und die Hardware (so weit wie möglich) gleich sind:
http://www.phoronix.com/scan.php?page=article&item=amd-athlon-ryzen3&num=1

Über alle Benchmarks hat der Athlon im Schnitt 128 Watt gezogen, der kleine Ryzen 86 Watt. Wobei der Ryzen dahingehend ein Handicap hatte, dass die GPU nicht so ausgebremst wurde wie beim Athlon und deshalb mehr verbraucht hat.
 
Zuletzt bearbeitet:
Das ist spätestens seit dem Start von TR bekannt..
 
"AMD has to pick the best-performing dies out of a common bin. The top 5% dies go into powering the company's Ryzen Threadripper HEDT processors, ..."
Interessant.
Wenn se 2 Chips auf ein Package draufmachen und die beide die 4 Ghz schaffen sollen, muss selektiert werden.

Das interessante an der News ist allerdings die Einsparung durch MCM.
 
AMD ships revised Ryzen CPUs with a compile bug fix (Quelle):

A little while ago, the Linux-headed sleuths over at Phoronix came across an obscure bug in Ryzen CPUs that triggered segmentation faults ("segfaults," which cause application crashes) in a compiler-specific workload. The bug was confirmed by AMD's engineers, who described it as a "performance marginality problem" and indicated that owners of affected CPUs could reach out to AMD Customer Care. The engineers also noted that Ryzen Threadripper and Epyc processors are unaffected. Phoronix's Michael Larabel took AMD up on its replacement offer and recently received a revised CPU that's apparently clear of the bug.

Larabel performed his due diligence and got to torturing the revised Ryzen 7 1800X under the same conditions that triggered the compilation segfaults. He's happy to report that he came across no issues whatsoever, whether related to compilation or not. The system used for testing was the same for old and revised processors alike. That also seems to clear any suspicion that the bug could somehow also be related to the motherboard or another component.

In his article, Larabel goes on to note that judging from his observations, Ryzen CPUs manufactured before week 25 (mid-June) of 2017 appear to be the ones affected by the problem. The bug is reasonably difficult to trigger, but users that want to rest easy can reach out to AMD Customer Care and get a replacement part.
 
Wobei auch Michael (als Linux-Nutzer) schreibt, dass ein Austausch normalerweise nicht nötig ist. Es ist nur Linux betroffen und die Last beim Kompilieren muss schon extrem sein:

to certain workloads such as running many Linux compilation tasks in parallel. Compiling most software you should be fine unless really hammering the system hardware. Under select conditions, the compiler may then produce a segmentation fault. Under normal Linux desktop workloads, gaming, etc, all Ryzen processors should work just fine.
 
Zuletzt bearbeitet:
Wie soll man das deuten, hat es Änderungen am Package gegeben oder gar am Die?
 
Wie soll man das deuten, hat es Änderungen am Package gegeben oder gar am Die?

AMD hat nichts verlauten lassen und ich glaube da kommt auch nichts offizielles. Das Stepping ist noch dasselbe. Insofern wird vermutet, dass es ein Herstellungsproblem war und AMD den QA-Prozess dahingehend verbessert hat und diese Dies jetzt entweder anders binnt oder an GF "zurückgehen" lässt.

Die große Rückrufaktion wird's nicht geben - sehe ich auch ein, denn es ist - für einen Desktop-Prozessor - schon ein ziemlich ungewöhnlicher Workload. Und einige, die MCE-Fehler und Segfaults sehen, dürften ggf. auch einfach ein Problem mit ihrer Plattform haben (OC, DRAM-Inkompatibilitäten, Speicherfehler, etc.).

Insofern finde ich es korrekt, dass AMD das auf die Leute beschränkt, die das Problem tatsächlich haben und diese auf den 'normalen' Support- und RMA-Prozess verweist.

Unter Windows (99% der Anwender) konnte das Problem bislang nicht nachgestellt werden; außer man benutzt wieder Linux in Form des "Windows Subsystem for Linux", was aber noch weniger Leute in der Form nutzen (ist ja auch noch Beta).

Ich selbst dürfte einen ziemlich frühen Ryzen 1700 haben, betreibe den nur unter Windows und da hat das System mehrere Wochen 24h BOINC+Minen sowie den normalen Betrieb mit mehreren VMs, Blender, CAD usw. usf. ohne Probleme abgearbeitet.
 
Das leuchtet ein.
Insgesamt erfreulich, dass dieses Problem nun auch gelöst wurde.
 
Die große Rückrufaktion wird's nicht geben - sehe ich auch ein, denn es ist - für einen Desktop-Prozessor - schon ein ziemlich ungewöhnlicher Workload. Und einige, die MCE-Fehler und Segfaults sehen, dürften ggf. auch einfach ein Problem mit ihrer Plattform haben (OC, DRAM-Inkompatibilitäten, Speicherfehler, etc.).

Sehe ich genauso und kann verstehen, dass AMD aus der Mücke keinen Elefanten macht. Es gibt ja Leute, die sonst aus Prinzip einen Austausch machen würden (obwohl sie als Windows-Nutzer gar nicht betroffen sind) oder welche, die jeden Absturz (durch Treiber, BIOS, RAM-OC) auf dieses sehr spezielle Problem schieben würden.
 
Klingt gut. Darauf kann sich AMD aber sicher noch nicht ausruhen
 
Zurück
Oben Unten