Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Hardware- und Nachrichten-Links des 8./9./10. März 2017
Leonidas
2017-03-11, 09:09:00
Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-8910-maerz-2017
Spike2
2017-03-11, 09:53:55
Nur aus Interesse gefragt: Wie kommt es, daß nicht alle Ryzen 1800X die 4,0 GHz packen? Die 4 GHz sind doch der offizielle Turbotakt dieses Modells (sogar noch zzgl. 100 MHz XFR), müssten dann nicht alle 8 Cores auf 4 oder gar 4,1 GHz validiert sein?
maximus_hertus
2017-03-11, 10:11:26
4 GHz Singlecore Turbo, nicht Allcore. Allcore sind die auf 3,7 GHz spezifiziert.
Spike2
2017-03-11, 10:27:01
Ist klar, daß die 4 GHz SingleCore-Turbo sind und die 4,1 GHz XFR nur unter gewissen Bedingungen.
Wenn einem aber Stromverbrauch und Abwärme egal sind (was man bei den zitierten OC-Versuchen wohl annehmen darf), dann sollten doch aber alle Kerne grundsätzlich in der Lage sein, diese Taktraten von 4,0 bzw. 4,1 GHz zu erreichen?
Die CPU kann ja schließlich nicht ab Werk "wissen", welcher der 8 Kerne für den SingleCore-Turbo gebraucht wird und dann immer nur den exakt selben Kern dafür verwenden (zumal da ja auch der ThreadScheduler noch ein Wörtchen mitzureden hat)?
Von daher verstehe ich das nicht oder anders gesagt: Wo liegt mein Denkfehler?
Botcruscher
2017-03-11, 10:30:21
Eher unverständlich ist es, wieso AMD bei Microsoft nicht auf den vorherigen Release eines solchen Patches gedrungen bzw. warum man mit dem Ryzen-Launch nicht besser auf jenen Windows-Patch gewartet hat.
Die Frage ist eher warum der nicht lange fertig ist obwohl AMD mit den ES quasi unendlich Zeit hatte und das aufgefallen sein _MUSS_.
Immer nur bei der Kühlung zu verkacken ist eben langweilig und da hat sich AMD echt mal was neues ausgedacht. Tradition wird eben groß geschrieben. Kein Start eines eigentlich guten Produktes ohne irgendwelchen vermeidbaren Bockmist.
Markus
2017-03-11, 11:51:07
Die Frage ist eher warum der nicht lange fertig ist obwohl AMD mit den ES quasi unendlich Zeit hatte und das aufgefallen sein _MUSS_.
Immer nur bei der Kühlung zu verkacken ist eben langweilig und da hat sich AMD echt mal was neues ausgedacht. Tradition wird eben groß geschrieben. Kein Start eines eigentlich guten Produktes ohne irgendwelchen vermeidbaren Bockmist.
Naja, der Februar Patchday ist ja ausgefallen. Vielleicht wären da ja die Fixes für Ryzen mit dabei gewesen.
Digidi
2017-03-11, 12:18:38
@3dcenter
Bitte im Artikel ergänzen. Hier heißt es der scheduler funktioniert korrekt.
https://www.pcper.com/reviews/Processors/AMD-Ryzen-and-Windows-10-Scheduler-No-Silver-Bullet
Ist klar, daß die 4 GHz SingleCore-Turbo sind und die 4,1 GHz XFR nur unter gewissen Bedingungen.
Die Turbotaktraten sind nicht unter allen Umständen garantiert auch nicht immer wenn nur 1/2Kerne aktiv sind.
Wenn einem aber Stromverbrauch und Abwärme egal sind (was man bei den zitierten OC-Versuchen wohl annehmen darf), dann sollten doch aber alle Kerne grundsätzlich in der Lage sein, diese Taktraten von 4,0 bzw. 4,1 GHz zu erreichen?
Die CPU kann ja schließlich nicht ab Werk "wissen", welcher der 8 Kerne für den SingleCore-Turbo gebraucht wird und dann immer nur den exakt selben Kern dafür verwenden (zumal da ja auch der ThreadScheduler noch ein Wörtchen mitzureden hat)?
Könnte die CPU schon wissen. Erstmal werden die CPUs ja auch getestet, um zu sortieren welches DIE als welches Modell verkauft werden kann.
Da kann man natürlich die Kerne individuell testen. Es wäre auch denkbar dass die CPU bei nur 2 aktiven Kernen immer die physikalisch besten Kerne auf dem DIE nimmt, unabhängig davon welche logischen Kerne gerade vom OS die Aufgaben zugeteilt bekommen.
Zusätzlich ist ja im Standardbetrieb (allerdings nicht im OC-Betrieb) das SenseMI aktiv.
Dieses überwacht Spannungen/Temperaturen etc. über das gesamte DIE verteilt und im Normalbetrieb senkt es die real anliegenden Spannungen unter die nominelle Spannung so weit dass gerade noch ein stabiler Betrieb erreicht wird.
Damit spart man natürlich Strom, da man bei der Dimensionierung der Versorgungsspannung nicht immer den schlimmstmöglichen Fall einrechnen muss.
Umgekehrt kann die Technik natürlich auch dazu benutzt werden die Taktraten vor Instabilitäten zu senken wenn die anderen Parameter (max. nominelle Spannung, Temperatur, max. Leistungsaufnahme) keine Stabilisierung zulassen.
Es kann also durchaus auch sein, dass ein DIE bei "normaler" Last zwar die 4 bzw. 4,1GHz ohne Probleme schafft, bei Prime aber beispielsweise nicht.
In dem Fall wird dann die reale Taktrate gesenkt.
OC geht aktuell nur mit deaktiviertem SenseMi, weshalb die Stromaufnahme selbst ohne Takt und Spannung über die nominellen Werte zu erhöhen ansteigt. Zusätzlich ist aktuell soweit ich weiß das Übertakten einzelner Kerne auch nicht möglich, es müssen also immer Alle den max. eingestellten Takt erreichen.
Abseits vom 1700 scheint momentan das Übertakten nicht wirklich sinnvoll zu sein, weil man alleine durch das Deaktivieren von SenseMi schon soviel mehr Strom braucht, dass es sich bei dem geringen Taktgewinn einfach nicht auszahlt.
Naja, der Februar Patchday ist ja ausgefallen. Vielleicht wären da ja die Fixes für Ryzen mit dabei gewesen.
Unwahrscheinlich, da hätte man normalerweise schon was bei den Insider Builds gesehen.
WCCF Tech und die PC Games Hardware bringen weitere Informationen zum Thema, wie der Threadscheduler von Windows die Ryzen-Performance negativ beeinflußt. So geht es offenbar weit über AMDs Designentscheidung zugunsten von zwei CCX-Modulen für den Achtkern-Ryzen hinaus, was Windows derzeit noch nicht versteht – vielmehr soll der Threadscheduler selbst das Simultaneous Multithreading (SMT) von Ryzen derzeit nicht korrekt erkennen können. Eine (vollständig) korrekte Erkennung würde bedeuten, das physikalische CPU-Kerne und nur logisch vorhandene CPU-"Kerne" erkannt und richtig eingeordnet werden können – etwas, was bei Intels HyperThreading funktioniert, bei Ryzens SMT derzeit aber noch nicht. Problematischerweise forciert eine Fehlerkennung von SMT, daß ein nur logisch vorhandener CPU-Kern mit einer zu hohen Last belegt wird – was in jedem Fall nicht gut kommt, im Fall von Ryzen beispielsweise die bessere Spiele-Performance unter Deaktivierung von SMT erklärt. Dabei könnte sich AMD unter Umständen selber geschlagen haben, denn aus unserem Forum kommt hierzu die Erklärung, wonach Windows 10 über einen Bulldozer-Patch verfügt, welcher bewußt alle Kerne gleichartig ansteuert – weil Bulldozer eben kein SMT hat.
Sehr unwahrscheinlich.
Bulldozer-Module und SMT sollten im wesentlichen sehr ähnlich angesteuert werden, dh. wenn Win10 im Bulldozer-Modus laufen sollte, müsste die Performance schon relativ gut sein.
Bulldozers CMT und SMT ist jetzt gar nicht so unterschiedlich.
Der größte Unterschied ist, dass CMT zwingend 2 Threads pro Modul braucht um alle Ressourcen auslasten zu können, während es mit SMT zumindest theoretisch auch mit lediglich einem Thread möglich ist, die Ressourcen eines Cores auszulasten, falls die OOOE genügend unabhängige Befehle findet.
Bei beiden sollte man allerdings zuerst jeden 2. Kern mit Threads belegen und erst wenn diese voll sind die weiteren Kerne füttern.
Das Penalty wenn das nicht geschieht ist logischerweise bei SMT größer, da bei CMT die eine Hälfte des Moduls eh nicht auf die Ressourcen der anderen Hälfte zugreifen kann.
Wahrscheinlicher erscheint da dass Windows das SMT von Ryzen gar nicht erkennt, wenn das der Fall ist, ist es aber ziemlich dämlich dass diese Baustelle erst nach dem Release von Ryzen angegangen wird, und seltsam auch dass man weder von MS noch von AMD irgendwas dergleichen gehört hat.
Ich vermute mal eher dass der L3-Cache von Ryzen ineffizient ist.
Erstmal handelt es sich um einen Victim-Cache, der von haus aus ineffizienter ist, und Ryzen hat keinen echten Last-Level-Cache. Jedes CCX kann nämlich lediglich auf "seinen" L3-Cache zugreifen, nicht auf jenen des anderen CCX.
Möglich dass man auch hier mit Änderungen beim Scheduler noch Verbesserungen erzielen kann, allerdings wesentlich weniger Trivial als einfach SMT korrekt berücksichtigen.
Redirion
2017-03-11, 15:44:45
@3dcenter
Bitte im Artikel ergänzen. Hier heißt es der scheduler funktioniert korrekt.
https://www.pcper.com/reviews/Processors/AMD-Ryzen-and-Windows-10-Scheduler-No-Silver-Bullet
Danke für den Link! Dieses Bild (https://www.pcper.com/files/review/2017-03-10/smton8workers.png).
Und dazu diese Aussage (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-6#post-38774321):
Odd cores are SMT in Windows.
Ist jetzt nur die Frage, ob der Task-Manager ab 1 zu zählen beginnt oder ab index 0.
okay, Antwort gefunden (https://www.pcper.com/files/review/2017-03-10/app01_0.png).
ok, also ab Index 0. Dann passt SMT ja.
Dieses Bild:
https://www.pcper.com/files/review/2017-03-10/smton8workers.png
Und dazu diese Aussage (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-6#post-38774321):
Ist jetzt nur die Frage, ob der Task-Manager ab 1 zu zählen beginnt oder ab index 0.
1. ist die Aussage auf die Programmierung bezogen, welche beispielsweise in C++ bei 0 beginnt. Wie man die Zählung in irgendeiner graphischen Darstellung macht ist egal.
2. ist das sowieso irrelevant. Wichtig ist dass nicht beide SMT-Threads einer CPU arbeiten so lange noch physische Kerne vorhanden sind. Welchen der beiden logischen Kerne eines physischen Kerns man jetzt den Thread bearbeiten lässt ist egal. So lange es abwechselnd ein ausgelasteter und ein nicht ausgelasteter Kern sind passt das.
Bulldozers CMT und SMT ist jetzt gar nicht so unterschiedlich.
Der größte Unterschied ist, dass CMT zwingend 2 Threads pro Modul braucht um alle Ressourcen auslasten zu können, während es mit SMT zumindest theoretisch auch mit lediglich einem Thread möglich ist, die Ressourcen eines Cores auszulasten, falls die OOOE genügend unabhängige Befehle findet.
Nein - ich denke das ist leider falsch. SMT ist ja kein separater Kern und auch bei den Modulen bei Bulldozer muss man hinsehen was da geshared wird. Beim BD gab es separaten L1 Caches je Core also zwei mal je Modul. Bei den anderen wird L1 und L2 geshared bzw. beim Hyperthreading mit benutzt, nur der Ques sind separat. Bei Intel und Ryzen SMT bzw. HT geht es darum dass die L1 und L2 Cache Daten möglichst die gleichen bleiben müssen sonst geht sehr viel Performance verloren.
Es müssen also gleichartige Threads zusammen gestellt werden sonst gewinnt man nichts. Das ist auch der Grund warum das schon immer im Gaming fast nichts bringt, erst mit den neuen APIs wo z.B. die GPU-DrawCalls über mehrere sehr ähnliche Threads parallel laufen können kann HT/SMT wirklich gut skalieren. Ansonsten war das eben bei typischem Rendering oder Komprimierung mit gleichen Operationen aus dem Cache bei unterschiedlichen Datenpaketen hilfreich.... Beim Mischen von z.B. Audio und AI und Grafik auf einem Core+HT geht das aber in die Hose....
Schon seltsam dass fast alle denken die Hyperthreads und SMT wären fast als separate Cores zu betrachten, gucken wohl alle zu viel auf die Windows Taskmanger Graphen und glauben das ist doch alles super unabhängig ;D
MrSpadge
2017-03-11, 22:56:48
@3dcenter
Bitte im Artikel ergänzen. Hier heißt es der scheduler funktioniert korrekt.
https://www.pcper.com/reviews/Processors/AMD-Ryzen-and-Windows-10-Scheduler-No-Silver-Bullet
Danke für den link, Digidi! In meinen Ohren das erste Vernünftige, was ich zu dem Thema gehört hab.
MrS
In folgendem CS:GO-Benchmark ist W7 teilweise 20% schneller und die 0%-Threads bleiben im Gegensatz zu W10 konstant.
https://www.youtube.com/watch?v=XAXS8rYwGzg&t=59
Danke für den link, Digidi! In meinen Ohren das erste Vernünftige, was ich zu dem Thema gehört hab.
MrS
vor tagen habe ich das schon geschrieben. der windows 10 sheduler funktioniert wie er soll, nur amd hats mal wieder verkackt. wie kann man so am markt vorbei entwickeln? entweder es geht ums eigene ökosystem oder man wollte wieder mehr als man konnte. alles für eins.
rip bulldozer - wellcome bulldozer.
mehr gibt es dazu nicht zu sagen. die software wirds schon richten. ein klares architekturproblem, nun soll microsoft ein grundlegendes feature an ihren multicore kernel ändern jeder entwickler seine engine anpassen, damit amd schneller wird? ja gewiss...weil ryzen halt die welt beherrscht. was amd da raushaut ist nichts weiter als eine schutzbehauptung und um die fallenden aktienkirse aufzuhalten, wie man sieht scheint das ja zu klappen. man wartet erstmal ab. das kann morgen aber schon wieder anders sein.
genau daher warten auch die mainboardpartner, denn das kann richtig nach hinten los gehen. dann bleiben sie auf dem krempel sitzen wie schon zu bulldozer zeiten.
Screemer
2017-03-12, 20:52:46
vor tagen habe ich das schon geschrieben. der windows 10 sheduler funktioniert wie er soll, nur amd hats mal wieder verkackt. wie kann man so am markt vorbei entwickeln? entweder es geht ums eigene ökosystem oder man wollte wieder mehr als man konnte. alles für eins.
rip bulldozer - wellcome bulldozer.
mehr gibt es dazu nicht zu sagen. die software wirds schon richten. ein klares architekturproblem, nun soll microsoft ein grundlegendes feature an ihren multicore kernel ändern jeder entwickler seine engine anpassen, damit amd schneller wird? ja gewiss...weil ryzen halt die welt beherrscht. was amd da raushaut ist nichts weiter als eine schutzbehauptung und um die fallenden aktienkirse aufzuhalten, wie man sieht scheint das ja zu klappen. man wartet erstmal ab. das kann morgen aber schon wieder anders sein.
genau daher warten auch die mainboardpartner, denn das kann richtig nach hinten los gehen. dann bleiben sie auf dem krempel sitzen wie schon zu bulldozer zeiten.
Bullshit
Schon seltsam dass fast alle denken die Hyperthreads und SMT wären fast als separate Cores zu betrachten, gucken wohl alle zu viel auf die Windows Taskmanger Graphen und glauben das ist doch alles super unabhängig ;D
Das habe ich nicht gesagt, vielmehr das umgekehrte, die einzelnen Hälften des Bulldozer-Moduls sind eben keine vollwertigen Kerne, genauso wenig wie bei SMT.
Bei Bulldozer ist einiges exklusiv für jede Hälfte des Moduls vorhanden klar, nur ist das eben kein Vorteil sondern ein Nachteil, da man zwingend auf 2 Threads angewiesen um das komplette Modul auszulasten. Der große Vorteil von SMT ist ja dass auch für nur einen Thread die kompletten Ressourcen zur Verfügung hat.
Jede Hälfte eines Bulldozer-Moduls ist nämlich wesentlich weniger mächtig als ein einzelner Kern der Core bzw. Zen Architektur.
Erst mit dem kompletten Modul kommt man auf einen vergleichbaren Durchsatz eines einzelnen Kern bei Core oder Zen, nur ist man eben auf 2 Threads angewiesen um das überhaupt nutzen zu können.
Es müssen also gleichartige Threads zusammen gestellt werden sonst gewinnt man nichts. Das ist auch der Grund warum das schon immer im Gaming fast nichts bringt, erst mit den neuen APIs wo z.B. die GPU-DrawCalls über mehrere sehr ähnliche Threads parallel laufen können kann HT/SMT wirklich gut skalieren.
Es ist genau umgekehrt. HT skaliert genau dann am besten wenn die 2 laufenden Threads unterschiedliche dinge machen und damit auch unterschiedliche ALUs im Backend belasten. Wenn beide genau das gleiche machen und auf den selben Einheiten laufen bringt HT praktisch nichts.
Denniss
2017-03-12, 22:19:59
Screemer - don't feed the Trolls
Redirion
2017-03-13, 09:58:01
Mittlerweile gibt es Hinweise darauf, dass pcper einige Fehler gemacht hat bei seinen Betrachtungen und auch nicht alle Möglichkeiten bedacht hatte. Das wird hier auf Anandtech diskutiert. Dieser Beitrag fässt die aktuell beobachteten Probleme mit dem Scheduler ganz gut zusammen (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-21#post-38789736).
Und hier räumt der Autor selbst auch ein, dass es offenbar Probleme beim Scheduler geben muss. (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-21#post-38790056)
Da die Performance-Unterschiede von Windows 7 zu Windows 10 teilweise erheblich sind, muss es ja ein Softwareproblem sein.
Da die Performance-Unterschiede von Windows 7 zu Windows 10 teilweise erheblich sind, muss es ja ein Softwareproblem sein.
Nein, AMD skaliert auf einigen Engines einfach weniger gut, selbst wenn der optimierte Scheduler da noch 3% drauflegt, was soll das bringen?(selbst wenn es 10% sind holt man Intel damit teilweise eben nicht ein, die das Problem ja anscheinend nicht haben). Das Gefasel ist Bullshit...man kann Ryzen nicht auf Intel Spielelevel hieven und genau das hat Lisa Su auch gemeint, man kann sich nicht immer mit Intel messen, dafür ist man halt billiger. Wann kapiert ihr das endlich mal? Waren ihre Aussagen so undeutlich oder was ist hier los.
Was sollen die Sche*** max. 10 % Softoptimierung bringen (und das ist ein theoretischer Wert der völlig verpufft), wenn Ryzen nur die Hälfte der FPS unter Speilen bring, weil das Arch-Design eben limitiert?
Es liegt ganz klar an AMD und das haben die vorher ganz genau gewusst. Ich kann den Schrott ehrlich nicht mehr lesen. Immer wieder irgnedwelche Ausreden mit denen die Leute hingehalten werden und ewig auf Leistungszuwächse warten die sich dann nach Jahren einstellen. Immer wieder die gleiche Leier, vllt. könnten sie nur ein einziges mal was ohne dieses Geseier hinkriegen.
Mittlerweile gibt es Hinweise darauf, dass pcper einige Fehler gemacht hat bei seinen Betrachtungen und auch nicht alle Möglichkeiten bedacht hatte. Das wird hier auf Anandtech diskutiert. Dieser Beitrag fässt die aktuell beobachteten Probleme mit dem Scheduler ganz gut zusammen (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-21#post-38789736).
Hier wird von keinem einzigen Hinweis auf einen Fehler gesprochen.
Klar ist, dass ein einzelner Test nicht alle Möglichkeiten durchspielen kann, das ist nicht möglich, wird aber auch nirgends behauptet.
Und hier räumt der Autor selbst auch ein, dass es offenbar Probleme beim Scheduler geben muss. (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-21#post-38790056)
Genau lesen. Der Autor schreibt hier dass Windows die einzelnen CCX nicht als NUMA-Nodes betrachtet. Das wäre aber auch nicht korrekt, weil bei NUMA geht es um weit mehr als nur um den Cache-Zugriff. Bei NUMA geht es vor allem darum dass nicht alle CPUs in auf jeden Bereich im RAM mit gleicher Geschwindigkeit zugreifen kann.
Das ist aber bei Ryzen nicht der Fall, beide CCX haben gleichberechtigten Zugriff auf den DRAM.
Einfach die einzelnen CCX als NUMA-Nodes zu interpretieren kann nicht die Lösung sein, abgesehen davon dass AMD dies auch einfach erreichen hätte können indem man sich gegenüber dem OS als 2 NUMA-Nodes ausgibt.
Das würde nämlich umgekehrt bedeuten, dass jede Software die nicht NUMA-Aware ist auf einen Quadcore beschränkt bleibt. Damit sind die Vorteile der vielen Kerne dahin.
Und selbst für NUMA-Aware Software wäre das nicht ideal, da diese ja davon ausgeht dass jeder Node nur auf seinen Speicherbereich schnell zugreifen kann und deshalb die Speicherallokation dementsprechend organisiert, was aber zu zusätzlichem Overhead führt der für Ryzen gar nicht notwendig wäre.
Da die Performance-Unterschiede von Windows 7 zu Windows 10 teilweise erheblich sind, muss es ja ein Softwareproblem sein.
Gut möglich, die Frage ist nur was das Problem ist.
PCPER zeigt zumindest dass es nicht "einfach" so ist, dass Windows SMT nicht richtig erkennt, und auch die CCX-Struktur scheint berücksichtigt zu werden. Ob das jetzt in jedem Fall ideal gemacht wird ist natürlich eine andere Frage, aber es ist sicher nicht einfach ein Schalter den MS umlegen kann und Ryzen ist plötzlich um Lichtjahre schneller.
Teilweise wird ja von recht deutlichen Performancegewinnen gesprochen wenn man Windows auf High-Performance stellt. Daher mein Verdacht eher dass Windows 7 nicht alle modernen Stromsparfeatures von Ryzen benutzt und deshalb die Performance so viel besser ist.
Die Frage ist halt ob man das vernünftig lösen, oder nur deaktivieren kann, weil in letzterem Fall sind die Tollen Stromverbrauchswerte aus den Launch-Reviews natürlich nichts mehr wert.
Wenn wirklich das Scheduling auf die verschiedenen CCX so viel kostet sieht es auch nicht gut aus weil dann gibt es nämlich keine allgemeine Lösung.
Bei <= 4 Threads ist diese noch Trivial, einfach alles auf 1 CCX. Bei >= 8 aufwändigen Threads auch, dann müssen 4 auf das eine und die anderen 4 auf das andere CCX.
Bei allem dazwischen ist es allerdings nicht wirklich klar was Ideal ist.
Bei 5 aktiven Threads könnte es dann vielleicht sein dass die schnellste Variante ist, alle 5 auf ein CCX zu schicken, obwohl 1 Thread dann nur einen virtuellen SMT-Core bekommt.
Es könnte aber auch 4 + 1 die schnellste Variante sein, aber eventuell auch nur wenn der 1 Thread ein ganz bestimmter aus den 5 ist. Oder aber 3 + 2 ist die schnellste Variante und auch hier gibt es wieder unterschiedliche Varianten was die 3 und 2 Threads auf den jeweiligen CCX sind.
Das OS kann hier unmöglich eine allgemein gültige Lösung finden, die immer automatisch die schnellste Variante findet.
Das könnte höchstens die jeweilige Software selbst, und das herauszufinden ist ein ziemlicher Albtraum für die Entwickler.
Wenn dieser tolle Infinity Fabric wirklich so lahm ist, wäre das wirklich ein ziemlicher Fail. Dann wird Ryzen nämlich bei Software die zwar mehr als 4 Threads auslasten kann aber nicht ständig zumindest 8 Threads gut auslastet kaum eine bessere Multicore-Skalierung als ein Intel 4-Kerner haben, und warum soll man dann einen 8-Kerner kaufen wenn es ein 4-Kerner von Intel selbst in den Multicore-Anwendungen auch tut und in Single-Thread sowieso deutlich überlegen ist?
Ich hoffe ja durchaus dass es was anderes ist und nicht die lahme Verbindung zwischen den 2 CCX, und zumindest hier geben die PCPER-Messungen ja auch eine leichte Entwarnung. Die Kommunikation zwischen den 2 CCX ist ja laut deren Messung zwar deutlich langsamer als bei Intel, allerdings "nur" um 75%, während man innerhalb eines CCX allerdings doppelt so schnell wie Intel ist. Selbst bei völlig willkürlichem Schedulling sollte sich das eigentlich einigermaßen ausgleichen.
@gast#21
danke - guter beitrag! in letzter zeit kann man solche beiträge auch nur noch anonym schreiben, ansonsten wird man irgendwann gelyncht.
für mich hat es amd verkackt (mal wieder). nachträgliche optimierungen ziehen eigentlich nur noch so eine art wellige linie glatt, sie katapultieren sie niemals steil aufwärts heißt, die bringen niemals massive performamcegewinne wenn die grundperformance in bestimmten fällen eben nicht stimmt. optimieren kann man immer, man wird aber auch dann nicht massiv schneller.
hier und in diesem fall sind weder microsoft noch die spieleentwickler schuld und das wird auch alsbald die erkenntnis sein. amd hat sich eben so entschieden. dann haben sie das ergebnis eben auch zu tragen. wer damit klarkommt solls nutzen, wer nicht findet auch andere möglichkeiten.
eine super spiele cpu wird zen damit nicht, man hätte ja auch auf bulldozer optimieren können, dann wäre auch der schnell gewesen. hat man aber nicht gemacht. das liegt auch nicht immer an intels marktmacht, sondern ist bei zu unterschiedlichen architekturen einfach zu kostenaufwendig. gpu und cpu optimierungen im größerem umfang, das können die kleinen studios einfach nicht stemmen. amd spaltet den markt weiter, und das wurde schon vor jahren prognostiziert.
zuletzt geht es auch um den kampf der engines und welche dem jeweiligen ihv am meisten bringt. der spieler hat von diesen gerangel und dem alles nichts...
Redirion
2017-03-14, 09:29:46
@Gast #20: Keine Ahnung, warum du dich so proviziert fühlst. Ich habe nirgends geschrieben, dass ich erwarte, AMD müsse in der Gaming-Performance mit Intels aktueller Generation gleichziehen oder sie überflügeln können. Mir geht es um die offensichtlichen Probleme unter Windows 10.
Hier ist Windows 7 17.8% schneller als WIndows 10 (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-5#post-38773988)
Auch hier sehr deutliche Unterschiede zwischen Windows 7 und Windows 10 (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-8#post-38775732).
Gleiche Software, gleiche Engine, sind doch auch die gleichen binären Dateien. Also ergibt sich nur ein deutlicher Unterschied allein durch Windows.
@Gast #21: Danke für den differenzierten Beitrag!
Es gibt nun ein offizielles Statement von AMD (https://community.amd.com/community/gaming/blog/2017/03/13/amd-ryzen-community-update?sf62107357=1).
Darin heißt es, es gäbe keine Probleme mit dem Scheduler. Sie gehen aber auf die Problematik beim Energiesparmodus mit Windows 10 ein in Bezug auf High Performance und Balanced. Es wird wohl im April ein Update geben, dass die Probleme behebt. Das klingt doch schonmal gut.
Hier ist Windows 7 17.8% schneller als WIndows 10 (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-5#post-38773988)
Auch hier sehr deutliche Unterschiede zwischen Windows 7 und Windows 10 (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-8#post-38775732).
Naja, deutlich ist was anderes. Ohne SMT praktisch gleich auf, mit SMT ist Win7 immerhin 8% schneller.
Die 18% sind aber schon eine Hausnummer.
@Gast #21: Danke für den differenzierten Beitrag!
Dankeschön.
Wie es aussieht scheint allerdings das einzige wirkliche Problem das Energieprofil zu sein:
https://www.computerbase.de/2017-03/ryzen-windows-7-benchmark-core-parking/
Im Durchschnitt ist nichtmal Windows 7 sondern 10 schneller, bis auf vereinzelte Ausnahmen.
Mit High Performance bekommt man heute offenbar schon weitestgehend die Win10-Performance.
Kann Ryzen eigentlich sowas wie Speedshift bei Intel?
Sie gehen aber auf die Problematik beim Energiesparmodus mit Windows 10 ein in Bezug auf High Performance und Balanced. Es wird wohl im April ein Update geben, dass die Probleme behebt. Das klingt doch schonmal gut.
Da geht es einfach nur um Coreparking, wenn AMD das nicht richtig unterstützt müssen sie einen vernünftigen Treiber schreiben. Ist ja nicht das erste mal das sie net.framework boykottieren. Was soll Microsoft da machen? Nix...für AMD eine Extrawurst entwickeln damit die Kohle sparen? Werden die jedenfalls nicht machen, da kannst du dir ganz sicher sein. Und da gab es schon früher Probleme mit CPU Befehlszyklen...
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.