AMD Zen: Erste Benchmarks aus Ashes of the Singularity
- Ersteller PCGH-Redaktion
- Erstellt am
Diablokiller999
Freizeitschrauber(in)
Wir wissen ja weder, wie gut ein AotS auf so viele Threads skaliert, noch kann man darüber Aussagen treffen wie sehr die Leistung dann ein bricht.
Zudem geht AMD eben nicht den alten Weg mit vielen Integer-Kernen und einer FPU sondern zurück auf die alten Pfade, aber jetzt mit SMT.
Viele Kerne bieten den Vorteil, dass diese eigenständig arbeiten und für die geteilte Last nicht hoch takten müssen, was Energie spart. Ein hoch gezüchteter Kern mit 4GHz kann weitaus mehr verbrauchen als 4 Kerne mit 1GHz, um eine Parallelisierung des Workloads kommen wir seit Jahren eh nicht drum rum und das wird sich auch nicht mehr ändern.
Man muss auch bedenken, dass irgendwann eine Pipeline einfach voll ist und noch mehr Stufen diese irgendwann ausbremsen. Da sind zusätzliche Kerne der Geschwindigkeit einfach zuträglicher statt den Kern immer weiter aufzublasen. In dieses Bottleneck rennt Apple momentan rein, weil ihr iOS nicht von vorn herein auf Multicore ausgelegt war und ihr ganzes Ökosystem ein kleiner Flickenteppich ist. Android war von vorn herein vollständig auf Multicore ausgelegt, darum haben die Handys auch mehrere kleine Kerne statt 1-2 große wie beim iPhone
Um die Sache anschaulicher zu machen, stell dir einfach n fetten Strongman vor, den du mit Steroiden ans Limit bringst um einen LKW zu ziehen. 10 durchschnittlich trainierte Menschen können den mit Leichtigkeit ziehen während der Strongman ans Limit muss und für 10 Leute frisst
Man sollte aber auch bedenken, dass es Architekturverbesserungen sind und die 40% sich wohl darauf beziehen. Wir wissen alle nicht, wie schnell Excavator mit L3-Cache wäre, denn eine solche CPU gab es nie. Bulldozer scheint diesen aber sehr nötig zu haben, also lief Excavator immer mit angezogener Handbremse. Heißt also 40% IPC-Vorteil + L3-Cache. Das scheint also eine relativ knappe Kiste mit Haswell/Skylake zu werden, aber mit 4 zusätzlichen Kernen weiß ich jedenfalls wer in meinen PC wandert ^^
Zuletzt bearbeitet:
OField
Software-Overclocker(in)
Das halte ich für zu optimistisch. AMD sagt ungefähr Haswell? Ich vermute mal die landen im Endeffekt bei minus 5% Haswell Leistung. Aber mal sehen was dann die Tests im neuen Jahr sagen.
manimani89
Volt-Modder(in)
bei dem bench ist der 6700k über 300% schneller?
manimani89
Volt-Modder(in)
sry falsch gesehen sind nur ca 60% unterschied^^
L
Laggy.NET
Guest
Stimmt, das hatte ich nicht bedacht.
Wir wissen ja weder, wie gut ein AotS auf so viele Threads skaliert, noch kann man darüber Aussagen treffen wie sehr die Leistung dann ein bricht.
Zudem geht AMD eben nicht den alten Weg mit vielen Integer-Kernen und einer FPU sondern zurück auf die alten Pfade, aber jetzt mit SMT.
Viele Kerne bieten den Vorteil, dass diese eigenständig arbeiten und für die geteilte Last nicht hoch takten müssen, was Energie spart. Ein hoch gezüchteter Kern mit 4GHz kann weitaus mehr verbrauchen als 4 Kerne mit 1GHz, um eine Parallelisierung des Workloads kommen wir seit Jahren eh nicht drum rum und das wird sich auch nicht mehr ändern.
Man muss auch bedenken, dass irgendwann eine Pipeline einfach voll ist und noch mehr Stufen diese irgendwann ausbremsen. Da sind zusätzliche Kerne der Geschwindigkeit einfach zuträglicher statt den Kern immer weiter aufzublasen. In dieses Bottleneck rennt Apple momentan rein, weil ihr iOS nicht von vorn herein auf Multicore ausgelegt war und ihr ganzes Ökosystem ein kleiner Flickenteppich ist. Android war von vorn herein vollständig auf Multicore ausgelegt, darum haben die Handys auch mehrere kleine Kerne statt 1-2 große wie beim iPhone
Um die Sache anschaulicher zu machen, stell dir einfach n fetten Strongman vor, den du mit Steroiden ans Limit bringst um einen LKW zu ziehen. 10 durchschnittlich trainierte Menschen können den mit Leichtigkeit ziehen während der Strongman ans Limit muss und für 10 Leute frisst
Man sollte aber auch bedenken, dass es Architekturverbesserungen sind und die 40% sich wohl darauf beziehen. Wir wissen alle nicht, wie schnell Excavator mit L3-Cache wäre, denn eine solche CPU gab es nie. Bulldozer scheint diesen aber sehr nötig zu haben, also lief Excavator immer mit angezogener Handbremse. Heißt also 40% IPC-Vorteil + L3-Cache. Das scheint also eine relativ knappe Kiste mit Haswell/Skylake zu werden, aber mit 4 zusätzlichen Kernen weiß ich jedenfalls wer in meinen PC wandert ^^
Mir sind die Vorteile von MultiCore durchaus bewusst und daran führt auch kein Weg vorbei.
Trotzdem ändert das doch nichts daran, dass extrem viele Anwendungen nur wenige Threads nutzen. Je mehr Kerne, desto größer ist der Leistungsabfall in diesen Anwendungen.
Ich bin halt der Meinung, solange man die Pro Kern Leistung steigern kann, sollte man das auch tun. IMHO sollte das das Primäre ziel sein, sonst wird der Kompromiss immer größer und ein Auslasten der CPU immer schwieriger.
Vielleicht kann man eine Anwendung auf 8 oder 16 Threads aufteilen, aber was, wenn man irgendwann 64 Threads und mehr ansprechen muss? Das zahlt sich bei entsprechenden Workloads aus, aber sicherlich nicht z.B. im Windows Alltag, wo mal 1-2 Threads die CPU kurzzeitig Auslasten. Die CPU soll ja schließlich auch schnell sein, wenn nicht 100% der CPU zeit aller Kerne beansprucht wird und man sich als Programmierer mal darüber gedanken machen kann, das ordentlich zu parallelisieren....Ich denke mir, es wird schon seinen Grund haben, warum Intel die 6 und 8 Kerner mit geringerem Takt nicht direkt als Consumerprodukte vermarktet. Für uns sind sie nunmal Kompromisse und kein Fortschritt in jeglicher Hinsicht.
Na ja, einen perfekten Weg scheint es nicht zu geben, sonst würden Intel und AMD diesbezüglich sehr ähnliche Ansätze verfolgen.
iGameKudan
Volt-Modder(in)
Ich kann dazu nur sagen...
iGameKudan schrieb:
DKK007
PCGH-Community-Veteran(in)
Locuza
Lötkolbengott/-göttin
Da ist ja auch schon die einfache Antwort.
AMD muss Module entwickeln die über eine große Bandbreite skalieren was Leistung, Stromverbrauch, Größe und Design-Komplexität angeht und das alles abhängig von ihrem Budget bezüglich Zeit, Männer und natürlich Geld.
Man kann es Intel einfach nicht völlig gleich tun und es ist auch nicht unbedingt schlecht, wenn sich AMD durch etwas andere Design-Entscheidungen versucht zu differenzieren.
Der Ansatz ist jetzt aber deutlich ähnlicher bei beiden, als noch beim Bulldozer.
Sehr gut. Aber tatsächlich haben wir das nicht im Forum gesehen. Kann passieren. Auf jeden Fall kein böser Wille.
Diablokiller999
Freizeitschrauber(in)
Das Problem ist nur, wir sind architektonisch an einem gewissen Limit angekommen. Das sieht man auch schön an der Leistungssteigerung bei Intel, deren Core-Architektur ist ebenfalls am Ende der Fahnenstange. Die Steigerungen der letzten Jahre waren vornehmlich durch neue Funktionseinheiten im Silizium, bessere Fertigung und daraus resultierend höhere Taktraten. Da kommen wir um eine Parallelisierung also nicht drum herum, weil wir da kaum noch was verbessern können. Die Fehlerquote der Sprungvorhersagen liegt schon im unteren Promillebereich und bevor wir nicht durch neue Materialien wie Kohlenstoff den Takt extrem steigern können, hängen wir in einer Sackgasse. Ich hatte ja für ZEN gehofft, AMD nutzt HBM als L4-Cache um den Flaschenhals DDR-RAM so gut es geht zu umgehen. Intel hat mit dem eDRAM für die CPUs mit Iris Pro gezeigt, dass auch die CPU davon stark profitieren kann. Aber wie es scheint, ist es wohl noch zu aufwändig für jeden Prozessor Interposer+HBM zu fertigen :-/
AMD selbst sagt nichts dazu, das sind nur Spekulationen aus Foren
Ich denke, es wird viel mit GlobalFoundries stehen und (wohl wahrscheinlicher) fallen. Wenn die ihre Fertigung nicht langsam in den Griff bekommen, hat AMD ernste Probleme. Es gibt Gerüchte, dass sie auch am Stromdebakel von Polaris schuld sind, weil die Fertigung nicht hält was versprochen wurde und schon der Bulldozer wurde mit deren Unfähigkeit gekillt, weil sie nicht in der Lage waren die erforderlichen Verbesserungen u.A. beim Stromverbrauch ins Silizium zu bringen.
Locuza
Lötkolbengott/-göttin
Ich weiß nicht woher die Vorstellung kommt immer HBM als Cache verwenden zu wollen, dass wäre für die meisten Anwendungsfälle heftig unsinnig.
Das ganze wäre auch nicht mit Intels eDRAM-Lösung zu vergleichen, wenn man so etwas haben möchte, dann löst man das auch besser ebenso.
Das ganze wäre auch nicht mit Intels eDRAM-Lösung zu vergleichen, wenn man so etwas haben möchte, dann löst man das auch besser ebenso.
Diablokiller999
Freizeitschrauber(in)
Soweit ich mich erinnere, liegen die internen Caches bei ~20-30ns, normaler DRAM bei 60-80ns und HBM irgendwo zwischen 40-60ns. Zudem hat man die Möglichkeit über einen viel breiteren Datenbus schneller die Daten zu schieben, was gerade bei Inhalten die hintereinander im Speicher liegen ziemliche Vorteile bringen kann.
Naja schon, aber wenn erhöhter IPC sich nicht in einen gewissen %-Satz Leistung niederschlägt, kann ich mir als Endverbraucher mit der Info den Hintern abwischen
Eigentlich wollte ich damit auch keine Diskussion über Begrifflichkeiten lostreten, da gibt es ja immer jemanden der es besser weiß - mir ging es in erster Linie darum, dass das mit dem Versprechen gepaart war, wieder "an INTEL ran" zu kommen.
AMD selbst hat nie einen Vergleich zu Intel gezogen, sondern nur zur eigenen Vorgängergeneration. Wie bereits angemerkt wurde, war aber auch dieses Vergleich uneindeutig, da es in der herangezogenen Generation überhaupt kein gleichartiges Produkt gibt. Daraus resultieren stark voneinander abweichende Hochrechnungen, wie schnell Zen denn nun laut AMD werden soll.
Es wurde ein Zen-Octacore mit einem Haswell-Quadcore verglichen. Trotz vergleichbarem SMT-Einsatz dürfte letzterer, gemäß der geringeren Kernzahl, in schlecht multithread-optimierbaren Szenarien weniger an Leistung verlieren. Alten Leaks zu Folge soll AMD selbst Summit Ridge dagegen für Multithread-Szenarien gedacht haben – für Endanwender ist vermutlich eher die 2017 erscheinende Quadcore-APU Raven Ridge gedacht.
Interne Caches sind deutlich schneller, AIDA64 zeigt mit spotan 10 ns für den L3 einer Ivy Bridge CPU an, der L4 von Broadwell dürfte bei unter 45 ns liegen. DDR-Hauptspeicher ist mit 70-80 ns schon deutlich abgeschlagen. Konkrete Zahlen für HBM liegen mir aber nicht vor. Aufgrund der anderen Optimierungsschwerpunkte bei Grafikkarten dürften diese auch nur schwer vergleichbar sein.
Ein weiterer großer Nachteil von HBM beim Einsatz als CPU-Cache wäre auf alle Fälle die Granularität. Pro Takt werden 256 Byte ausgelesen, die kleinste Zugriffseinheit müsste 32 Byte betragen. Zum Vergleich: Der Wechsel von 4 auf 8 Byte Prefetch (für ein ganzes Modul) zwischen DDR2 und DDR3/4 hat bereits für messbare Performance-Einbußen bei gleichem Takt und gleichen Latenzen gesorgt – und das war beim Einsatz als Hauptspeicher, wo vergleichsweise große Datenblöcke transferiert werden.
Locuza
Lötkolbengott/-göttin
@ Diablokiller999
@ 3-4 Ghz beträgt die Cache-Latenz (L1-3) eher 1-20ns:
AMD Athlon X 845 mit Excavator-Kern im Test: Messlatte fur Zen
http://www.legitreviews.com/wp-content/uploads/2015/08/ddr4-3866.jpg
i7-5775C L4 cache performance - Benchmarking, system performance - AIDA64 Discussion Forum
Bei HBM sieht es nach den praktisch gleichen Grundlatenzen wie für den anderen Speicher aus, dabei liegt die Taktrate unter dem DDR4 Standard, ich würde deswegen eine eher schlechtere Latenz am Ende erwarten.
Abseits von "Big-Data" sehe ich keinen Anwendungsfall wo man HBM als zusätzliche Cache-Stufe konfigurieren würde.
Rein vom Angebot macht HBM für den normalen Konsumenten nur in der Form Sinn, in der er auch gedacht ist, als einfacher Datenspeicher mit erhöhtem Durchsatz.
@ 3-4 Ghz beträgt die Cache-Latenz (L1-3) eher 1-20ns:
AMD Athlon X 845 mit Excavator-Kern im Test: Messlatte fur Zen
http://www.legitreviews.com/wp-content/uploads/2015/08/ddr4-3866.jpg
i7-5775C L4 cache performance - Benchmarking, system performance - AIDA64 Discussion Forum
Bei HBM sieht es nach den praktisch gleichen Grundlatenzen wie für den anderen Speicher aus, dabei liegt die Taktrate unter dem DDR4 Standard, ich würde deswegen eine eher schlechtere Latenz am Ende erwarten.
Abseits von "Big-Data" sehe ich keinen Anwendungsfall wo man HBM als zusätzliche Cache-Stufe konfigurieren würde.
Rein vom Angebot macht HBM für den normalen Konsumenten nur in der Form Sinn, in der er auch gedacht ist, als einfacher Datenspeicher mit erhöhtem Durchsatz.
Diablokiller999
Freizeitschrauber(in)
Hmm, da muss ich wohl meine Daten etwas erneuern. Meine Latenzzeiten sind nicht mehr ganz aktuell wie mir scheint 
DKK007
PCGH-Community-Veteran(in)
Ich würde den HBM auch eher als reinen Cache für die IGPU verwenden, da dort die Bandbreite derzeit bremst. Und bei einer GPU taugt HBM ganz gut.
Eventuell mit optionalem Zugriff für die CPU wegen HSA, der sollte dann aber etwas geringere Priorität haben.
wuselsurfer
Kokü-Junkie (m/w)
Nö, wieso?
Ähnliche Themen
