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

[Casi030]

Najam BD versagt schon gegen Sandy Bridge und die waren auch noch 32nm.

So ist das,Konkurrenz Ruiniert das Geschäft......
Kannst es ja besser machen,Intel empfängt dich als Konkurrent 100% mit Kuss Hand.

 

[w0mbat]

Versagt wobei? Bei der Erektion? Dass sich heutzutage noch jemand an solchen Fanboy Beiträgen versucht...seltsam.

Fanboy? Ich bin der größte AMD/ATI Fan, hatte immer nur AMD in meinem PC. Aber manche scheinen der Wahrheit nichts ins Gesicht schauen zu können...

 

[Complicated]

Ich sagte nicht du seist ein Fanboy, sondern fragte mich warum jemand solche Fanboy-Beiträge verfasst. Wie kann denn eine Architektur versagen? Versagen können nur Menschen. Ich meine also lediglich deine unpassende und polarisierende Wortwahl.

Aber manche scheinen nicht lesen zu können? ^^

 

[w0mbat]

Du weißt ganz genau wie das gemeint war. Hoffen wir, dass Zen AMD etwas mehr konkurrezfähig wird.

 

[Complicated]

Ja und du weisst genau was ich gemeint habe. Hoffen wir, dass wir hier im Forum etwas objektiver werden.

 

[Helle53]

O.T. LWP @Opteron: Sorry, etwas spät, aber ich wollte unbedingt noch einen Test mit Windows 8.1 machen. LWP gehört(e) ja zu den Features, die vom Betriebssystem freigeschaltet werden müssen (wie XMM/YMM). Aber wie bei Windows 7 ist auch bei 8.1 das LWP-Bit im XFEATURE_ENABLED_MASK-Register nicht gesetzt (ausgelesen mit XGETBV); LWP also nicht nutzbar. Ich habe auch keinerlei Berichte o.ä. über eine Nutzung gefunden. Eigentlich Schade, denn ein CPU-/Prozess-Monitoring auf CPL3 wäre schon interessant gewesen...

 

[Opteron]

O.T. LWP @Opteron: Sorry, etwas spät, aber ich wollte unbedingt noch einen Test mit Windows 8.1 machen. LWP gehört(e) ja zu den Features, die vom Betriebssystem freigeschaltet werden müssen (wie XMM/YMM). Aber wie bei Windows 7 ist auch bei 8.1 das LWP-Bit im XFEATURE_ENABLED_MASK-Register nicht gesetzt (ausgelesen mit XGETBV); LWP also nicht nutzbar. Ich habe auch keinerlei Berichte o.ä. über eine Nutzung gefunden. Eigentlich Schade, denn ein CPU-/Prozess-Monitoring auf CPL3 wäre schon interessant gewesen...

Ach passt schon, die paar Tage mehr sind doch nicht wichtig.
Wenn nichtmal Windows die Befehle freigeschalten hat sieht man aber recht deutlich, dass sich LWP nicht durchsetzen konnte. Finde es auch schade, aber tja ... eine abermalige Unterstützung durch ne neue Architektur macht dann echt keinen Sinn mehr.

 

[WindHund]

Du weißt ganz genau wie das gemeint war. Hoffen wir, dass Zen AMD etwas mehr konkurrezfähig wird.

Dazu muss Zen zuerst mal zeigen was er kann, ich meine das wird keine leichte Aufgabe: http://abload.de/img/screenshotwin32_0001_gwkxv.png
Wie viel FPS sind 1ms Frametimes nochmal? Das ist kein 720p sondern 1080p mit Ultra Preset!
Ohne Framelimiter würden alle heulen, vor allem die GPUs!

 

[pipip]

Ich glaube eher, dass der Fokus sich da etwas verändert hat. Anstatt das Geld in SIMD zu investieren, die vllt von paar wenige User unterstützt werden, werden sie das Geld lieber in HSA-Features stecken.
Besonders bleibt hier die Hoffnung, dass HSA früher oder später im mobilen Markt, vllt angefangen mit MediaTek etablieren könnte und dann auf den Desktop umschwappt.

 

[miriquidi]

Anstatt das Geld in SIMD zu investieren, die vllt von paar wenige User unterstützt werden, werden sie das Geld lieber in HSA-Features stecken.

Schwierig. Die SIMD-Befehle müssen eh irgendwann implementiert sein. Oft geht das im Prinzip über eine Zerlegung in mehrere vorhandene Micocode Instruktionen (wie SSE3 beim K8 oder Bobcat). Das sollte eigentlich nicht so teuer sein.

 

[WindHund]

Ich glaube eher, dass der Fokus sich da etwas verändert hat. Anstatt das Geld in SIMD zu investieren, die vllt von paar wenige User unterstützt werden, werden sie das Geld lieber in HSA-Features stecken.
Besonders bleibt hier die Hoffnung, dass HSA früher oder später im mobilen Markt, vllt angefangen mit MediaTek etablieren könnte und dann auf den Desktop umschwappt.

HSA ist am Aufrüsten, und inzwischen in allen Teilbereichen angekommen.
Wer nicht mitzieht, darf gerne das kürzere Streichholz ziehen.

Schwierig. Die SIMD-Befehle müssen eh irgendwann implementiert sein. Oft geht das im Prinzip über eine Zerlegung in mehrere vorhandene Micocode Instruktionen (wie SSE3 beim K8 oder Bobcat). Das sollte eigentlich nicht so teuer sein.

Good luck, Jim Keller!

 

[Duplex]

Najam BD versagt schon gegen Sandy Bridge und die waren auch noch 32nm.

Selbst ein 45nm Nehalem 4C/8T @3,5 Ghz ist in Spielen noch schneller als ein aktueller FX8xxx.

 

[gruffi]

Lass es einfach bleiben. Keinen interessieren nur Spiele. Und dafür wurde Bulldozer auch nicht entwickelt. Complicated hat schon Recht. Keiner braucht hier solche Polemik. Bulldozer hat genauso seine Vor- und Nachteile wie andere Architekturen auch. Nehalem sieht nicht viel Land gegen einen FX-8350, wenn mal ein bisschen Durchsatz gefragt ist. Unter 64-bit noch signifikanter als unter 32-bit.

 

[Gast11062015]

Den Preis kann man sich ausmalen
.

Xone SoC ca. 140euro


BD ist doch gar nicht so schlecht,
Bei diversen Anwendungen ist so ein 130euro 8320 auf dem Niveau eines früheren 300euro 3770K,
wenn man Firmen mit dem *I... Arschkriechsyndrom z.b. "Maxon" * mal auslässt.

 

[Opteron]

Schwierig. Die SIMD-Befehle müssen eh irgendwann implementiert sein. Oft geht das im Prinzip über eine Zerlegung in mehrere vorhandene Micocode Instruktionen (wie SSE3 beim K8 oder Bobcat). Das sollte eigentlich nicht so teuer sein.

Microcode ist grottenlahm, oder meinst Du Double MacroOps?
Selbst dann wird man das bei Zen aber vermutlich nicht brauchen. In 14nm mit den HD-Libs und SMT-Betrieb kann man sich locker zwei 256bit FMACs pro Kern leisten.

Doubles bräuchte man dann erst wieder bei 512bit AVX3-Instruktionen

 

[hoschi_tux]

Wo kommt denn die SMT Geschichte her? Lese ich ständig, dass ZEN das nutzen soll, aber nirgendwo was greifbares dazu.

 

[PuckPoltergeist]

Die Frage ist, wozu muss man SIMD auf der CPU optimieren, wenn man das Ganze auch per HSA auf die GPU schieben kann? Insofern ist für AMD die Konzentration darauf schon sinnvoller. Bei SIMD auf der CPU nimmt man mit, was von der Konkurrenz vorgegeben wird, optimiert wird auf die GPU und HSA.

 

[Opteron]

Wo kommt denn die SMT Geschichte her? Lese ich ständig, dass ZEN das nutzen soll, aber nirgendwo was greifbares dazu.

Klar, über ZEN weiss man bis auf den Namen nichts, das ist reine Kaffeesatzleserei.
Aber die Entwicklung muss zwangsläufig wg. der Herstellungsprozesse in Richtung IPC gehen, das schließt hohe Takte und CMT dann eher aus.
Nachdem die FPU aber schon unter SMT lief, wär es für AMD kein Neuland, womit man es dann auch erwarten kann, der Durchsatz soll schließlich auch stimmen, es soll ja ne Opteronversion kommen.

Die Frage ist, wozu muss man SIMD auf der CPU optimieren, wenn man das Ganze auch per HSA auf die GPU schieben kann? Insofern ist für AMD die Konzentration darauf schon sinnvoller. Bei SIMD auf der CPU nimmt man mit, was von der Konkurrenz vorgegeben wird, optimiert wird auf die GPU und HSA.

Kommt drauf an wie stark parallelisierbar das Ganze ist. Wenns nur schnöde Rechnerei ala HPC ist, hast Du schon recht.
Ist dann wohl ne Art Intel-Kompatibilität, seh ich auch so. Immerhin stehen mit der ARM-Allianz aber die Chancen größer, dass sich HSA irgendwie durchsetzt, insbesondere auch deswegen, weil die ARM FPUs ja nur 128bit Vektoren verarbeiten.

 

[PuckPoltergeist]

Kommt drauf an wie stark parallelisierbar das Ganze ist. Wenns nur schnöde Rechnerei ala HPC ist, hast Du schon recht.

Wenn es nicht parallelisierbar ist, nützt SIMD nix, weder auf CPU noch auf GPU.

 

[gruffi]

Wo kommt denn die SMT Geschichte her? Lese ich ständig, dass ZEN das nutzen soll, aber nirgendwo was greifbares dazu.

Das hat WCCFTech verbreitet/spekuliert und alle anderen wiederholen es einfach nur. Zuverlässige Infos gibt es dazu keine. Und selbst wenn Zen SMT nutzen sollte, dann wäre das nichts neues. Auch Bulldozer nutzt SMT. Offenbar glauben einige, dass AMD Intels HTT kopiert. Ich glaube ehrlich gesagt aber nicht daran. Am sinnvollsten wäre mMn, auf kompakte singlethreaded Kerne zu setzen, Stichwort HDL, oder CMT weiterzuentwickeln.

Die Frage ist, wozu muss man SIMD auf der CPU optimieren, wenn man das Ganze auch per HSA auf die GPU schieben kann?

Das Problem ist, nicht für jedes Stückchen Code lohnt es sich, dieses auf die GPU auszulagern. GPUs brauchen einfach einen gewissen Grad an Parallelität. Ansonsten wird der Overhead grösser als ein möglicher Geschwindigkeitsgewinn. Insofern braucht man schon noch SIMD Einheiten in der CPU. Sowas wie 512-bit AVX3.x ist mMn aber unnötig. Eine 256-bit SIMD Pipeline ist eigentlich optimal für eine Client CPU und oft schon überdimensioniert.

 

[Opteron]

@Puck:
Ja klar, schlecht ausgedrückt, meine den Codeanteil. HSA wird immer nen Overhead haben und eher ne höhere Latenz aufweisen. Wenn man die Daten schneller braucht und/oder der SIMD-Codeanteil nicht so groß ist, wird man auf der FPU bleiben.

Edit: Gruffi hat mehr oder minder das gleiche geschrieben, hat sich überschnitten.

--- Update ---

Damits hier auch noch steht, David Kanter kennt schon die neuen Architekturen (oder zumindest deren Unterschiede):

> The ISA advantage will be greatly reduced in the top-end side of the performance spectrum, but will not vanish.
> Keller mentioned during Core Day conference that his K12 core will have a "bigger engine" than its x86 sister
> thanks to the advantages of ARMv8 over x86-64, which allows to spend more transistors on compute.

I happen to know the differences between those two designs. I'm not really sure it's going to translate into a significant performance delta. My guess is maybe 10%.

http://www.realworldtech.com/forum/?threadid=142175&curpostid=142759

 

[miriquidi]

Microcode ist grottenlahm, oder meinst Du Double MacroOps?

Ich meinte Double MacroOps. Damit ging das in der Vergangenheit ja eigentlich immer recht problemlos.

 

[Gast11062015]

Mal zu den "Neuen" Apu´s DDR4 wird ihnen auch nichts bringen.

Da geht ja so gut wie Garnichts weiter bei dem Speicherdurchsatz,
genauso bei den Timings DDR3 3000 hat bessere Timings als DDR4 3000.

Gut durch die Niedrigere Spannung verbraucht der PC 1-2W weniger ist ja auch schon ein Erfolg,
aber z.b. ein neues DvD-Laufwerk kost weniger und bringt mehr Einsparung

 

[Opteron]

Ich meinte Double MacroOps. Damit ging das in der Vergangenheit ja eigentlich immer recht problemlos.

Oki, alles klar dann.

Mal zu den "Neuen" Apu´s DDR4 wird ihnen auch nichts bringen.

Da geht ja so gut wie Garnichts weiter bei dem Speicherdurchsatz,
genauso bei den Timings DDR3 3000 hat bessere Timings als DDR4 3000.

Also wenn Du explizit ne APU ansprichst, dann bringt DDR4 da sehr wohl was, nämlich für den GPU-Teil. Dem ist die Latenz ziemlich egal, da gehts hauptsächlich um Durchsatz.

Der wird je nach Threadzahl auch für den CPU-Teil wichtig. Wenn Zen ein 8-Kerner mit 2fach SMT werden sollte, müsste man schon 16 Threads versorgen ... wenn die alle unter Vollast laufen qualmt der Speicherkontroller. Intel verbaut bei Ihren Dickschiff-Xeons auch ein Quad-DDR3-Interface (und neuerdings sogar Quad-DDR4), das gibts nicht nur aus Jux und Tollerei.

Mit DDR4 könnte mans sich mit dual oder Triple-Channel begnügen halten. Nachdem bei DDR4 nur ein DIMM-Slot pro Kanal erlaubt ist, hätt ich persönlich gerne wenigstens 3 Kanäle, das Mainboardlayout sollte mit DDR4 ja auch einfacher werden, sodass es bei billigen 4 Lagen möglich sein sollte (wenn ich mich recht erinnere, dann hatte Asrock das sogar noch bei Sockel 1366 mit DDR3 fertig gebracht). Aber naja ... wohl trotzdem eher unwahrscheinlich.

 

[Gast11062015]

Falsch, bei der Gpu spielt die Latenz eine Große Rolle