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

Wenns auf deinem Konto so knapp aussieht, denk lieber an was kleineres.
Sonst bleibt dir demnächst noch viel Monat am Ende vom Geld über ;)

Naja wenn am Freitag noch für dem Preis in Laden dann ich kaufen tu, nur derzeit reicht das (Rest)Geld ohne Lohn noch nicht weil andere Anschaffungen für Pentadings gerade laufen
 
Ryzen schwache Performance bei Rise of Tomb Raider genauer betrachtet:
Ab Minute 10 wird es interessant...


Daraus kann man schließen:
- Ryzen wird von Vega stark profitieren.
- Ein Blick auf MutliGPU lohnt. (Wird leider zu wenig getestet).
 
Zuletzt bearbeitet:
Es sieht einfach so aus als würde der Geforce Treiber Beim Ryzen mit SMT zumindest bei DX12 eine falsche Kernzuordnung nutzen und 2 Threads auf einen Kern bappen. Das dies leistungstechnisch voll nach hinten los geht ist nun wirklich nichts neues.
 
Es sieht einfach so aus als würde der Geforce Treiber Beim Ryzen mit SMT zumindest bei DX12 eine falsche Kernzuordnung nutzen und 2 Threads auf einen Kern bappen. Das dies leistungstechnisch voll nach hinten los geht ist nun wirklich nichts neues.
Evt. sollten wir unterscheiden zwischen Software, OS und Hardware Threads.
Durch die "low level" Programmierung ist man inzwischen als Entwickler relativ unabhängig.
Sprich, wenn die Engine schon auf mehr Threads ausgelegt ist, wirkt es sich auch über all dort aus, wo genug Hardware vorhanden ist.
Was das OS dann macht, dient eher dem Turbo.

Worauf ich hinaus möchte, wenn ein Software Entwickler alle Ressourcen nutzen will, dann soll sie/er das doch "dürfen" !?
 
Bei der Problematik hilft aber "mehr threads" alleine nicht weiter denn wenn die beiden virtuellen Kerne auf einem Kern laufen ist das im Vergleich zu 2 getrennten Kernen ein massiver Leistungseinbruch und genau danach sieht es für mich aus. AMD wurde ja in der Vergangenheit dafür kritisiert das sie SMT bei ihren Treibern nicht verwenden, gut möglich das ausgerechnet dieser Umstand jetzt für die deutliche Mehrleistung bei DX12 mit verantwortlich ist.
Es kann aber auch sein das nvidia ihren Treiber recht starr auf die HTT Kernverteilung ausgerichtet hat, was bei einer anderen Verteilung bei AMDs SMT Umsatzung zwangsläufig in die Hose gehen würde.
 
Es sieht einfach so aus als würde der Geforce Treiber Beim Ryzen mit SMT zumindest bei DX12 eine falsche Kernzuordnung nutzen und 2 Threads auf einen Kern bappen. Das dies leistungstechnisch voll nach hinten los geht ist nun wirklich nichts neues.

SMT allein erklärt es nicht. Da muss noch mehr ungeschickt ablaufen. nVidia scheint auch keine große Eile zu haben, das Problem zu lösen.

Meine persönliche Meinung ist, dass nVidia keine große Lust auf DX12 hat. Es passt nicht zu den strategischen Zielen der Company, man kann da schon fast von Boykott reden. Über nVidas rudimentäre und lustlose Implementierung haben sich schon etliche Entwickler beschwert. Manche auch öffentlich. Bisher geht die Strategie aber auf: statt nVidias Treiberarbeit in Frage zu stellen, wird die Schnittstelle an sich als wenig gewinnbringend angesehen.
 
Zuletzt bearbeitet:
DX ist halt auch nur "eine" Schnittstelle von einer Firma. Was eben nur 20% des Softwarmarktes sind. Dann kommt noch hinzu ob AMD die ganze Dokumentation für Ryzen schon veröffentlicht hat und für Nvidia zugänglich ist.

Wenn man nur auf die Youtube Videos geht mit ein bischen Benchmarkgedöns um Klicks zu erhaschen.......
 
Wenn man nur auf die Youtube Videos geht mit ein bischen Benchmarkgedöns um Klicks zu erhaschen.......

*lach* das ist die Motivation, das zu 90% das Internet mit Inhalten füllt: Klicks zu erhaschen. Die ganze PC-Branche besteht nur aus Benchmarkgedöns... Deswegen jemanden zu diskreditieren ist doch ziemlich daneben.
 
@ grauenvoll
Lasse SMT durch den zweiten virtuellen Kern auf einem physischen Kern im Schnitt 30% Zusatzleistung bringen und wir sind bei ca. 130% bei den beiden virtuellen Kernen. Im Vergleich zu den möglichen 200% auf 2 physischen Kernen mit je einem virtuellen Kern ist das mickrig und ein Einbruch von grob geschätzt 40% und das nur weil die falschen Kerne genutzt werden. Da die Spiele die Kerne idR. ohnehin nicht voll auslasten können und die CPU deshalb Teillast nutzen dürfte dieses Szenario warscheinlicher sein als so manchen lieb ist. Windows mag ja noch mitbekommen was welcher Kern ist, weshalb das Problem bei DX11 Spielen eher selten anzutreffen ist. Müssen die DX12 Spiele große Teile des Shedulings allerdings selbst übernehmen dann kann das schon recht schnell in die hose gehen, zumal es vor dewm Ryzen nur ein Kernverteilungsschema für SMT gab. Richte das Sheduling fest darauf aus und es geht bei einem anderen Schema voll in die Hose.
 
Müssen die DX12 Spiele große Teile des Shedulings allerdings selbst übernehmen dann kann das schon recht schnell in die hose gehen, zumal es vor dewm Ryzen nur ein Kernverteilungsschema für SMT gab. Richte das Sheduling fest darauf aus und es geht bei einem anderen Schema voll in die Hose.

Es hat ja einige Tests mit SMT ON/OFF gegeben. Die Effekte lagen meist im einstelligen Prozentbereich. Ausserdem wurde in dem Video untersucht, wie sich die Situation verhält, wenn man nVidas 1070 durch 2x RX480(DX12/MultiGPU) ersetzt.

1070vs480.PNG

Wenn ich deiner Logik folge, hätte der Wechsel der Grafikkarten keinen großen Einfluss haben dürfen, denn Raise of Tomb Raider hätte das gleiche SMT Problem bei 2x RX480 haben müssen wie bei einer GTX1070. Dem ist aber nicht so!
Lag Ryzen bei einer GTX1070 und DX12 fast abgeschlagen zurück, ändert sich das Bild bei 2x RX480 komplett.
Zu was Ryzen in der Lage ist, werden wir erst sehen wenn Vega verfügbar ist!
 
Zuletzt bearbeitet:
DX ist halt auch nur "eine" Schnittstelle von einer Firma. Was eben nur 20% des Softwarmarktes sind. Dann kommt noch hinzu ob AMD die ganze Dokumentation für Ryzen schon veröffentlicht hat und für Nvidia zugänglich ist.
Wer weiß, vielleicht hat Nvidia im Vorfeld keine Ryzen-Samples zum Anpassen ihrer Treiber bekommen :-)
 
Nvidia legt so gut wie nichts offen, was ihre Chips angeht. Das Entwicklungstool von AMD für Linux hat noch keinen Ryzen support. ;D Als ich das letzte mal nachgesehen haben.
 
@ grauenvoll
Wenn du meiner Logik folgen würdest dann wäre dir der Aspekt der SMT/CPU Nutzung durch den Treiber in den Sinn gekommen. ;)
Bei den DX11 Treibern wurde AMD stets wegen der schlechteren Leistung kritisiert, welche meiner Erfahrung nach vor allem durch eine schlechtere CPU Auslastung/Kern Nutzung zu stande kam. Diesbezüglich kam ja auch Kritik aus dem Entwickler Lager udn wenn ich mich recht entsinne spielte da auch SMT eine Rolle das vom AMD Treiber nicht genutzt wurde.

Übertrage das mal auf ein fehlerhaftes SMT Ansprechverhalten bei DX12. Wo kein SMT genutzt wird tritt das Problem nicht auf.
Zu den SMT on/off tests, bei wievielen wurde auf die API geachtet?

Es ließe sich ja auch recht einfach nachprüfen indem ein Geforce Besitzer mit einem Ryzen den Test mit und ohne SMT nachstellt.
Steigt sie ohne SMT in normale Regionen ist klar wo der Hund begraben ist.
 
Zuletzt bearbeitet:
@ grauenvoll
Wenn du meiner Logik folgen würdest dann wäre dir der Aspekt der SMT/CPU Nutzung durch den Treiber in den Sinn gekommen. ;)
Bei den DX11 Treibern wurde AMD stets wegen der schlechteren Leistung kritisiert, welche meiner Erfahrung nach vor allem durch eine schlechtere CPU Auslastung/Kern Nutzung zu stande kam. Diesbezüglich kam ja auch Kritik aus dem Entwickler Lager udn wenn ich mich recht entsinne spielte da auch SMT eine Rolle das vom AMD Treiber nicht genutzt wurde.

Übertrage das mal auf ein fehlerhaftes SMT Ansprechverhalten bei DX12. Wo kein SMT genutzt wird tritt das Problem nicht auf.
Zu den SMT on/off tests, bei wievielen wurde auf die API geachtet?

Hast du da eine Quelle für? Höre ich so zum ersten mal. Wäre aber aus Sicht AMD`s auch bescheuert, wenn es so wäre nichts dagegen zu tun. Meine Halbwissen meint zu "wissen" dass NV die Drawcalls unter DX11 besser im Griff hat... Wobei eines darf man auch nicht vergessen - NV-Spiele sollte man aus der Betrachtung aussen vor lassen oder zumindest nur Benches anschauen wo NV Effekte aussen vor sind...
 
Nvidia legt so gut wie nichts offen, was ihre Chips angeht.
Leider ist AMD in der Hinsicht nur unwesentlich besser als nVidia. Entweder ist sie nicht öffentlich oder bruchstückhaft.

Kommt es einem auf gute Dokumentation an, muss man gezwungenermaßen zum Monopolisten mit dem blauen Logo greifen.
 

Der Abstand zwischen den 6- und 8-Kernern dürfte zu groß gewesen sein. All mein Umfeld will sich einen 6-Kerner kaufen; fast allen ist der 8-Kerner zu teuer. Auch ich hole mir den "einfachen" Ryzen-5-1600. Man kann ja dann später auf einen Zen-+ mit 8 Kernen upgraden.

Nachdem die 6- und 8-Kerner auf dem gleichen Die basieren und AMD den Preisabstand reduziert, gehe ich davon aus, dass entweder das Yield der 8-Kerner besser ist als die Nachfrage-Verteilung oder dass der 8-Kerner bisher etwas zu teuer war und man einfach erreichen will, dass mehr Kunden zum teurern Produkt greifen.
 
@ Novasun
Ich hatte mal meine eigene kleine Testreihe mit einer 290x und einer GTX970 auf einem FX-8350 gemacht, welcher aufgrund der relativ geringen Einzelkern leistung eine recht gute Basis für solche Spielchen war.
http://www.planet3dnow.de/vbulletin/threads/425119-R9-290x-vs-GTX970-im-CPU-Last-Vergleich

Die Ergebnisse waren natürlich zum Teil durchwachsen aber beim Star Swarm Stress Test war es doch recht eindeutig erkennbar wo hohe Leistung der Geforce bei DX11 her kam. Das die Radeon voll im CPU Limit hing sieht man ja anhand der deutlich besseren Ergebnisse beim Mantle Test, bei welchem die CPU durch die bessere Lastverteilung auch stärker ausgelastet wurde. Bei der Geforce sieht man ebenfalls eine deutlich bessere Lastverteilung auf den Kernen und damit auch eine höhere Auslastung der CPU. Da ist es auch nicht wirklich verwunderlich das die Geforce dann besser mit Daten versorgt wird und dsie eine höhere Framerate erreicht. Mit der damals umjubelten besseren Effizienz der Treiber hatte das herzlich wenig zu tuen, die vorhandene Hardware wurde nur effektiver genutzt und damit stärker ausgelastet.
 
Was auch noch hinzukommt ist, was für Berechnungen die GPU selber erledigt und was auf die CPU ausgelagert wird. Kann mir durchaus vorstellen das es da gewisse Unterschiede zwischen AMD und Nvidia gibt.

Der Nvidia-Treiber gräbt sich auch tiefer ins System ein. Ich denke mal das sich die Nvidia-Karte mit der CPU "kurzschließt". AMD nutzt wahrscheinlich eine Schnittstelle die eins darüber ist. Also nicht so effizient.
 
Zuletzt bearbeitet:
Es wurde ja später bekannt das bei nvidia inzwischen viele Sheduling Aufgaben des Grafik Chips, welche bei AMD in Hardware gegossen sind, bei nvidia vom Treiber erledigt werden. Ich weiss aber licht mehr ab welcher Generation das war. War das ab dem Kepler oder erst ab der Maxwell Generation?
Ich gehe mal davon aus das ihr Treiber deshalb diverse Unzulänglichkeiten von DX11 untergraben kann, letztendlich aber auch für die oben angesprochenen Probleme anfällig sein kann.

Ich gucke nochmal nach ob ich was zu der GPU Sheduling Geschichte finde.

--- Update ---

Ich glaube ich hatte die Info von dem Youtube Video hier: https://www.youtube.com/watch?v=nIoZB-cnjc0
 
Zuletzt bearbeitet:
Hi naja nicht ganz ;) da der 3200 Speicher nur mit 2933 lief aber gut zu sehen das Dual Rank auch übertatet werden kann, viele haben ja schon mit den XMP Frequenzen Probleme diese zum laufen zu bekommen.
Daher wurden die Samsung B site so gepusht weil die doch gemessen an den anderen die besten Ergebnisse hatten, wenn ich das nur bei mir anschaue die starten sogar mit 3600 CL16.

lg
 
Hi naja nicht ganz ;) da der 3200 Speicher nur mit 2933 lief aber gut zu sehen das Dual Rank auch übertatet werden kann, viele haben ja schon mit den XMP Frequenzen Probleme diese zum laufen zu bekommen.

Als ich den Link gepostet habe, hatte ich das Video noch nicht zu Ende geschaut, habe mich dann sehr gewundert, dass der Crucial DR 2933 OC so schlecht performt,
Golem hatte Dual Ranked DDR4-2667 CL16-16-16-36-1T ziemlich gleich auf mit Single Ranked DDR4-3200 CL14-14-14-34-1T getestet.
Vermutlich leidet Dual Rank stärker unter schlechten Timings als Single Rank Speicher (Rawiioli hat mit CL20 getestet), mit DR 2933 MHz sollte eigentlich noch ein Leistungsplus zu SR 3200 MHz drin sein.

Daher wurden die Samsung B site so gepusht weil die doch gemessen an den anderen die besten Ergebnisse hatten, wenn ich das nur bei mir anschaue die starten sogar mit 3600 CL16.

Jo, dachte ich auch, Pustekuchen, die G.Skill TridentZ F4-3600C17D-16GTZKW wollten bei mir auffem C6H nicht stabil über 3200 MHz @CL14-14-14-34 hinaus, reichte mir aber auch erstmal so, bis die neuen Teiler kommen... :)
 
Zuletzt bearbeitet:

Na ja, der gute Rawiioli ...:]
Ein Hort verlässlicher Informationen ist er für mich nun aber nicht gerade, nachdem er es in diesem Video ->
nicht hinbekommen hat eine QVL ordentlich gelesen zu bekommen.
Ich mein, klar taucht der RAM da doppelt auf, nämlich einmal unter RyZen und dann nochmal unter APU (also Bristol Ridge) und BR hat nun mal einen anderen Speicherkontroller als RyZen. Da kann der gleiche Speicher eben nur noch mit DDR4-2133 betrieben werden.
Deswegen den Board-Hersteller, oder den RAM-Hersteller zu dissen kommt mir etwas komisch vor.
Aber na ja, YouTuber eben ...

Das man generell Crucial RAM recht gut übertakten kann ist nun auch nichts Neues.

Auch der Preis ist jetzt nichts Sensationelles, gab den Trident-Z vor kurzem im Angebot zum selben Kurs, aber eben auf 3200 cl14 spezifiziert.

Überhaupt ... wie kann man denn Trident-Z RAM mit ungeraden Timings kaufen und für RyZen verwenden wollen?
Bzw. ist nur bei cl14 sicher, das es Samsung B-Dies sind, bei anderen Timings (höheren) eben nicht, können also genauso gut Hynix gewesen sein, welche dann natürlich
bekanntermassen nicht auf 3200 laufen.

Da soll er erstmal recherchieren, der gute ... bevor er mit seinem Halbwissen um sich wirft.
 
Hat hier gerade noch jemand die Kosten für eine Maske in 14nm/28nm/32nm im Kopf?
Ich meine mal eine schöne Gegenüberstellung bzgl. Ryzen hier oder anderswo gelesen zu haben, leider lässt ich dies spontan nicht mehr ergoogeln. :(
 
Zuletzt bearbeitet:
Zurück
Oben Unten