Diskussion zu: Hardware- und Nachrichten-Links des 6./7. März 2017

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-67-maerz-2017

[Doppeldrop]

Und wenn man sich die Rohdaten ohne Diagramm ansieht merkt man das ein Großteil der Gamingtests ins GPU Limit rennt und damit nen Verzehrtes Bild liefern.

[Gast]

genauso auch, wie die (relative) Spieleschwäche von Ryzen im Verhältnis zu Bulldozer eigentlich eher einen Witz-Status innehat: Die Differenz ist im großen Maßstab betrachtet eher klein und vor allem kein Vergleich zum Rückstand von Bulldozer.

Verstehe diesen Satz nicht. Sollte es heißen "im Verhältnis zu Intel"?

[maximus_hertus]

Stichwort Bristol Ridge - offizielle AMD Aussage:


[–]AMD_jamesProduct Manager

AMD did not ask for any delays on mini-ITX, rather the partners are free to release when their product line is ready.
We will introduce 7th Gen A-series APUs for socket AM4 in the channel later this year.


[–]Minkipunk 66 Punkte vor 5 Tagen
The 7th Gen A-series APUs series is Bristol Ridge, not Raven Ridge, right? Can we still expect Raven Ridge to be released in H2 2017?


[–]AMD_RobertTechnical Marketing[S] 109 Punkte vor 5 Tagen
Correct.


[–]Bravest_Sir_Robin 24 Punkte vor 5 Tagen
Why will they coexist? Does the 14nm Raven Ridge not make 28nm Bristol Ridge obsolete?


[–]peasncarrots20 21 Punkte vor 5 Tagen
Could be cost. The 28nm tech might be cheaper, enabling Bristol Ridge to cover the most cost-sensitive part of the APU market.


[–]AMD_jamesProduct Manager 53 Punkte vor 5 Tagen
Yes to both.


Ergo wird Bristol Ridge wohl doch noch kommen und sei es nur für den <100 USD/EUR Markt.

Z.B. könnte BR die APUs für 50 - 120 Euro / USD abdecken und RR 150 - 250 Euro / USD. Es hängt natürlich viel davon ab, wie performant RR am Ende sein wird.

[MadManniMan]

Und wenn man sich die Rohdaten ohne Diagramm ansieht merkt man das ein Großteil der Gamingtests ins GPU Limit rennt und damit nen Verzehrtes Bild liefern.

Jupp, das hatte ich im Review-Thread schon ausführlich dargestellt. Generell ist die Diagrammform fein, aber massiv bias-anfällig.

[G3cko]

Was für eine Designschwäche bei Spielen? Wenn es unter win7 läuft aber unter win10 (noch) Probleme macht ist das keine designschwäche sonder schlicht ein Software Problem. Genauso DX11 VS DX12. Wenn die schlechtere API besser läuft ein Software Problem. Mal den Kopf einschalten und nicht immer alles nacherzählen...

[Gast]

Und wenn man sich die Rohdaten ohne Diagramm ansieht merkt man das ein Großteil der Gamingtests ins GPU Limit rennt und damit nen Verzehrtes Bild liefern.

Sieht man schon daran dass selbst Bulldozer nicht allzu weit hinten ist.

[Gast]

Z.B. könnte BR die APUs für 50 - 120 Euro / USD abdecken und RR 150 - 250 Euro / USD. Es hängt natürlich viel davon ab, wie performant RR am Ende sein wird.

RR wird so grob die doppelte CPU-Rechenleistung liefern wie BR (siehe auch Vergleich 8350 vs. 1800x) und die Grafikleistung dürfte auch mind. um 50
% steigen (wegen der speichereffizienten Vega Architektur).
Im Mobilbereich könnten die besten RR somit auch teurer als 250 Euro.- werden, da CPU und GPU zusätzlich extrem energieeffizient sind.

[Gast]

Was für eine Designschwäche bei Spielen? Wenn es unter win7 läuft aber unter win10 (noch) Probleme macht ist das keine designschwäche sonder schlicht ein Software Problem. Genauso DX11 VS DX12. Wenn die schlechtere API besser läuft ein Software Problem. Mal den Kopf einschalten und nicht immer alles nacherzählen...

Naja, wenn das Problem wirklich der Scheduler von Win10 ist, so wie das heute auf Wccftech erklärt wird, dann sollte mit dem Fix von Microsoft jegliche Schwäche behoben sein.
Schliesslich sind beim Gaming sehr viele unterschiedliche Thread-Typen am laufen, bei Anwendersoftware kommt son ein Bug nicht wirklich zum tragen, weil die Operationen über alle parallelen Threads überlicherweise meist die gleichen sind, das ist im Gaming ganz anders.

Design-Schwäche ist da wahrscheinlich eine falsche weil einseitige Einschätzung, mir kommt es auch in erster Linie als Schwäche bei den ganz gewichtigen Softwarepartnern (Microsoft/Adobe&Co.) und nicht so bedeutenden Partnern (kleinere Spielestudios) vor.

[Gast]

mal wieder auf w10 einzuschlagen ist so schön einfach. mal dran gedacht das w7 die kerne so wie w10 gar nicht anspricht. dort wird nicht zwischen den kernen geswitcht um ressourcen zu verteilen oder freizusetzen? amd hat ja das problem der zuordnung, c1-4 sind physische kerne, c5-8 logische, 9-12 physische, 13-16 logische. w10 kommt dann mit dem w7 sheduler damit für amd nur die ersten vier physischen und ersten vier logischen kerne angesprochen werden; und wozu sollte ms dann w10 für bessere multicoreunterstützung bringen? ein ihv der so grundlegend an softwarevorgaben vorbeientwickelt sollte sich mal fragen was er da macht.

die amd kernverteilung in cpu0 und cpu1 ist das problem, da ja der l3 cache auch genauso angesprochen werden muss. das ist ein architekturproblem und keins der software. den meisten anwendungen ist das egal. warum sollte ein gameentwickler jetzt seine komplette engine umbauen und dazu noch einen eigenen sheduler für amd entwickeln.

amd pusht hier mit ihren ryzen bestimmte engines und andere bleiben auf der strecke. ehrlich was soll sowas? man baut sich ein eigenes ökosystem und damit ein eigenes monopol. das hilft niemanden.

[OBrian]

Stichwort Bristol Ridge - offizielle AMD AussageQuelle? ist das von Reddit oder wo?

[Redirion]

amd hat ja das problem der zuordnung, c1-4 sind physische kerne, c5-8 logische, 9-12 physische, 13-16 logische.

Quelle dafür? Ich hatte das so verstanden, dass die ungeraden (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-6#post-38774321) Kerne die SMT-Kerne seien.

Quelle? ist das von Reddit oder wo?
Ja, das ist vom AMA auf Reddit

[Gast]

... ein ihv der so grundlegend an softwarevorgaben vorbeientwickelt sollte sich mal fragen was er da macht.

die amd kernverteilung in cpu0 und cpu1 ist das problem, da ja der l3 cache auch genauso angesprochen werden muss. das ist ein architekturproblem und keins der software. den meisten anwendungen ist das egal. warum sollte ein gameentwickler jetzt seine komplette engine umbauen und dazu noch einen eigenen sheduler für amd entwickeln.
....
hier kann man nicht von Softwarevorgaben ausgehen, das macht überhaupt keinen Sinn. Eine CPU-Architektur sieht viele MS-OS Versionen kommen und gehen. Die ganze Branche sucht nach dem Weg für optimales Multithreading, da muss auch die Software für unterschiedliche Lösungsansätze angepasst werden. Ein Gameentwickler ersetzt auch nicht die Scheduler im OS. Er muss nur auf die Eigenheiten eingehen wenn Bottlenecks produziert werden und bei jeder Funktion überlegen ob SMT oder nicht. Da Memory Access oft ein Bottleneck ist kann das schon Sinn machen. http://www.agner.org/optimize/blog/read.php?i=6
Windows bringt als OS einfach grosse Probleme für die Gameentwicklung mitsich, weil die Ressourcen z.B. beim SMT nicht vorhersehbar genutzt werden können, weil das OS scheinbar beliebig Threads zuteilt. Wohl auch deshalb wird es den Gaming-Mode künftig geben, damit dieser Mist endlich nur noch sehr begrenzt auf Cores und SMT auswirkt.
Windows war noch nie! ein für Echtzeit geeignetes OS (Medienproduktion, Prozesssteuerung, VR, Gaming) man muss dort immer mit Überprovisionierung der Ressourcen extrem gegensteuern statt genaue Leistungsanforderungen zu planen. Im Embedded bekommt Microsoft auch keinen Fuss in die Tür... aber selbst bei Linux gab/gibt es spezielle Derivate...

[MrSpadge]

Welche software-Kern-Nummer welcher physikalischen Recheneinheit entspricht ist doch nur ne dumme Zuordnungstabelle. Diese nicht genauso wie Intel es schon seit Jahren handhabt zu machen und sich dann hinzustellen "Die Software ist Schuld und muss jetzt aber auch für uns optimiert werden!" ist doch total dämlich. Und noch stümpferhafter ist es, - wenn es denn sein "muss" - dies nicht vor Markteinführung kommuniziert und wenigstens OS-Updates angestoßen zu haben.

MrS

[Gast]

Welche software-Kern-Nummer welcher physikalischen Recheneinheit entspricht ist doch nur ne dumme Zuordnungstabelle. Diese nicht genauso wie Intel es schon seit Jahren handhabt zu machen und sich dann hinzustellen "Die Software ist Schuld und muss jetzt aber auch für uns optimiert werden!" ist doch total dämlich. Und noch stümpferhafter ist es, - wenn es denn sein "muss" - dies nicht vor Markteinführung kommuniziert und wenigstens OS-Updates angestoßen zu haben.

MrS
jaja, als ob die Ingenieure die CPU-Architekturen entwerfen nicht wüssten wie man simple Tabellen pflegt. Nein, so einfach ist es nicht. Bei dem Blog von Agner könnte man sich da ein wenig einlesen in die Problematik bei jemand der wirklich Ahnung hat, aber nunja...

Wahrscheinlich wollte Intel unbedingt, dass die Hypberthreads im OS sichtbar werden - der Murgs war ja Anfangs nie wirklich sinnvoll einzusetzten und ist heute noch recht schwer mit umzugehen. Also sollte das OS die HTs auslasten statt dass man diese exclusiv dem jeweiligen echten Thread als reservierte Ressource zuzuordnen. Der Konsument sollte ja glaube er hat super viele Kerne. Dabei macht es bei 8+ Kernen mit SMT ohnehin keinen Sinn mehr beliebigste Threads auf einem Kern zu mischen. Sogesehen Epic Fail von Intel und MS um damals Hyperthreading "zu retten", oje habe ich EPIC gesagt? ;D

[MrSpadge]

jaja, als ob die Ingenieure die CPU-Architekturen entwerfen nicht wüssten wie man simple Tabellen pflegt.
Eben - die Erklärung ergibt so überhaupt keinen Sinn.

Und zu Teil 2: jaja, MS und Intel sind Schuld, dass AMD sich nicht eher darum gekümmert hat. Und bei CPUs, die stark mit mäßig anspruchsvollen Threads ausgelastet werden, ist es übrigens überhaupt nicht schwer, einen Vorteil durch HT zu bekommen: lass das OS einfach machen und gut is. Da gibt es genug Wartezeiten auf Speicherzugriff etc., so dass sich der netto-Durchsatz erhöht. Das heißt, gerade bei den dicken CPUs lohnt es sich - denn man darf davon ausgehen, dass jemand der 500+ € für ne CPU ausgibt diese nicht nur für Minesweeper einsetzt.

MrS

[Gast]

... ist es übrigens überhaupt nicht schwer, einen Vorteil durch HT zu bekommen: lass das OS einfach machen und gut is. Da gibt es genug Wartezeiten auf Speicherzugriff etc., so dass sich der netto-Durchsatz erhöht. ..
;D neee nicht wirklich. Schonmal was von Kontext Switch gehört? Egal, ...
http://forums.guru3d.com/showthread.php?t=402869
In Games nutzt HT garnix wenn der Progger das nicht explizit optimiert, das OS stört da allenfalls mit Unsinn durch low priority tasks, Büroclient und Server-OS ohne zeitkritische Sachen auch kaum problematisch wie in Echtzeitanwendungen. Deshalb werden wir ja einen Gaming-Mode für Windows10 bekommen. Aber ab hier drehen wir uns im Kreis, das ist sinnlos...
(vielleicht hülft es wenigstems dem einen oder anderen aufgeschlossenen Mitleser :) )

[MrSpadge]

Kontext Switch - sicher, passiert unter Win regulär (also ohne interrupts) alle 1 ms. Ne moderne CPU hat also 4 Millionen Takte zwischen den context switches.

Und was soll mir dein Link zeigen? Dass HT in Spielen nichts bringt? Klar, ist ja auch schon lange bekannt. Siehst du nen Widerspruch zu irgend einer Aussage hier? Wird in irgendeinem dieser Spiele mit mehr als 4 Threads gearbeitet?

Und weißt du was ich dort sehe? "es ist für Spiele wurscht egal, ob mit oder ohne HT". Und das ist ein klarer Widerspruch zu: "Murgs" "nie wirklich sinnvoll einzusetzten" "schwer mit umzugehen" "Epic Fail"

Der Link von Agner ist ne gute Einführung, aber bei weitem nicht so negativ wie du es vielleicht gelesen hast. Da steht "kann in einigen Anwendungen mit HT langsamer werden" (stimmt immer noch, auch wenn die Fälle von Nehalem zu Skylake weniger geworden sind) und "es ist nicht trivial, es optimal auszunutzen". Ja, und? Dann hab ich lieber 0-20% ohne Anstrengung mehr als direkt darauf zu verzichten weil ich nicht die mit Handoptimierung vielleicht möglichen 5 - 25% bekomme. Auch einige der Flaschenhälse, die er aufzählt, haben sich inzwischen geweitet: breiterer Decoder, mehr Ausführungseinheiten, mehr Ports zu eben diesen Einheiten.

In einem geb ich dir aber Recht: die Diskussion hier wird uns vermutlich nicht weiter bringen. Außer vielleicht du hättest deine allgemeinen Aussagen nur auf Spiele bezogen (ich nicht).

MrS

[Gast]

Und was soll mir dein Link zeigen? Dass HT in Spielen nichts bringt? Klar, ist ja auch schon lange bekannt. Siehst du nen Widerspruch zu irgend einer Aussage hier? Wird in irgendeinem dieser Spiele mit mehr als 4 Threads gearbeitet?
Auf was ist "dieser" bezogen? Ich war überrascht, dass laut PCGH alle vier getesteten Spiele auf mehr als 4 Ryzen-Kerne positiv reagieren. Jetzt weit entfernt von 1:1 aber immerhin mit Steigerung. Kann imho nicht am L3 gelegen haben. Ob SMT aktiviert war, kann ich dem Text nicht entnehmen.

[MrSpadge]

War auf diesen link (http://forums.guru3d.com/showthread.php?t=402869) des Gastes über dir bezogen, i7 3770 mit und ohne HT in Spielen des Jahres 2015.

MrS

[Gast]

War auf diesen link (http://forums.guru3d.com/showthread.php?t=402869) des Gastes über dir bezogen, i7 3770 mit und ohne HT in Spielen des Jahres 2015.Oha.
GTX760 mit 3770. Damit disqualifiziert sich der Test schon vor Beginn.
Zum einen hängt man dann wohl öfter am GPU- denn CPU-Limit und testet damit schlicht das falsche.
Hinzu kommt, dass man bei 4/4 vs 4/8 voraussetzt, dass die Engines mit 8 auch was anfangen können. Das dürfte 2015 noch viel weniger der Fall gewesen sein.
Man hätte 2/2 vs. 2/4 testen müssen. Und vielleicht noch zum Vergleich 4/4. Mit mind. 780Ti, um GPU-Limit auszuschließen.
Wie andere Tests nachweisen, wäre selbst ein i5 für eine 760 schon grenzwertig zu Overkill (mit oben genannten Ausnahmen). Man gewinnt im Vergleich zum Mehrpreis in den meisten Fällen nichts bis zu wenig.

Oder auch "wer misst misst mist" :-) denn im Hintergrund läuft immer noch Windows.

[Gast]

Wie sehen denn die Verkaufszahlen bei Ryzen aus?
Also sowohl absolut, als auch relativ und Verlauf über die Zeit seit Erstverkaufstag+1 (1. Tag zählt nicht, weil Vorbestellungen). Das Ganze natürlich im Vergleich zu i7 und i5.
Gibt ja Händler wie Mindfactory, die "X verkauft" bei schreiben. Aber eben ohne Verlauf oder identischem Zeitraum.
Ja, Komplettsysteme sind dann unberücksichtigt, was AMD zu Gute kommt.
Ja, es gibt scheinbar beim 1700 Lieferprobleme.
Ja, ist nur begrenzt aussagefähig, weil vorher keine Konkurrenz und viele womöglich mit Entscheidung bis Ryzen-Release gewartet haben.