AMD AMD Ryzen 3900X und 3700X im Test | igor´sLAB

Domme

Domme

Mitglied
Mitglied seit
Jan 17, 2019
Beiträge
43
Bewertungspunkte
17
Punkte
8
Ryzen-2-cover-893x502.jpg


Domme submitted a new blog post

Continue reading the Original Blog Post.
 
Sortiere nach Datum Sortiere nach Stimmen
DHAmoKK hat gesagt. :
Aber wenn man SMT abschaltet, ist das für mich ein Zeichen, dass zumindest der Scheduler noch nicht vernünftig mit der CPU klar kommt und Prozesse auf einem virtuellen Kern ausführt, die eigentlich auf einen realen gehören.
Zum Vergrößern anklicken....
Bei einer CPU mit SMT gibt es aus Sicht des Betriebssystems zur Ausführung nur (logische) Kerne.
2-way SMT heißt ja, dass parallel 2 Ausführungsstränge auf eigentlich einem physischen Kern ausgeführt werden, weil zB FPU, ALU, Register.. alle verdoppelt wurden. Der direkte Haupteffekt davon ist übrigens nicht höhere Performance sondern Effizienz.
Performance kann leiden. Sogar signifikant. Warum? Weil es nicht zwei unabhängige Kerne sind sondern immer noch Ressourcen* geteilt werden.

Immer dann, wenn solche geteilte Ressourcen von mehreren Ausführungssträngen gleichzeitig benötigt werden dann wird MT zu ST .. sprich es wird gebremst. :p

Bezüglich Scheduler: der kann eigentlich nichts dafür.
Das Betriebssystem weiß nicht wie sich Anwendungen in der Zukunft verhalten werden, wie sehr sie sich um geteilte Ressourcen innerhalb der CPU ringen, etc. Das kann sich schlagartig von einer Sekunde auf die andere ändern und ist auch bei jeder Anwendung anders.

Die Verantwortung entsprechend zu optimieren liegt somit eigentlich in den Händen der Softwareentwickler, aber die machen sich selten die Mühe in diesem Aspekt händisch auf mehrere unterschiedliche CPU-Architekturen zu optimieren (SMT bei CPU A ist nicht gleich SMT bei CPU B). Soweit mir bekannt ist wird deswegen Scheduling normalerweise einfach dem Betriebssystem überlassen ... obwohl es trivial wäre in den Engines Threads bestimmten logischen Kernen zuzuweisen.

Wo der Scheduler tatsächlich verbesserungswürdig war, war in Situationen, in denen er Threads/Prozesse von einem CCX zum anderen verschoben hat. Deswegen wurde das ja auch mit Windows 1903 gepatched, sodass der Scheduler jetzt die CCX Architektur versteht und unnötiges hin- und herschieben vermeiden kann.

*) auf der CPU
 
Zuletzt bearbeitet :
Upvote 0 Downvote
xnor hat gesagt. :
Bei einer CPU mit SMT gibt es aus Sicht des Betriebssystems zur Ausführung nur (logische) Kerne. [...]
Zum Vergrößern anklicken....

In der Theorie ist das richtig, in der Praxis geht der Windows-Scheduler in b1903 jedoch deutlich weiter und unterscheidet sehrwohl zwischen den einzelnen Cores. AMD hat sich hier in Zusammenarbeit mit Microsoft für ein sogenanntes Thread Grouping entschieden, d. h. ein CCX (max. 4 Kerne und 16 MiB L3) wird zuerst "aufgefüllt", bevor Threads auf einen neuen CCX gelegt werden. *) Hintergrund ist hierbei eine höhere Gewichtung der Interprozesskommunikation zwischen den Threads, die bei der Kommunikation über CCX-Grenzen hinweg bereits zusätzliche Latenzen innerhalb eines CCDs hinnnehmen müssen und bei der Kommunikation über den IOD hinweg noch einmal. Wie viel am Ende unter dem Strich dabei rausfällt, wird man wohl erst mit einem stabilen BIOS/AGESA sehen.

Die Alternative wäre eine Thread Expansion, also Threads so weit wie möglich weg anzusiedeln, sodass man eine thermisch optimale Verteilung erreicht und die CPU möglicherweise höhere Takte fahren kann. Beide Ansätze haben durchaus ihre Vorteile und sind Abhängig vom konkreten Szenario. Für ein Thread Grouping spricht laut AMD aktuell die Arbeitsweise aktueller Games.
Beispielsweise fürs Rendering, bei dem die Interprozesskommunikation auf ein Minimum reduziert ist, wäre wahrscheinlich eine Thread Expansion vorteilhafter.

*) Interessant wäre noch die Frage, wie Microsoft das handhabt bzgl. Threads von unterschiedlichen Prozessen/Programmen. Hier würde ich durchaus eine Bündelung auf unterschiedliche CCXe erwarten, jedoch findet man so tiefe Details nicht in den allgemeinen (Presse-)Quellen und müsste sich hierzu in den Microsoft-Dev-Docs umsehen.
 
Upvote 0 Downvote
Ja, das mit dem Scheduler Update bzgl. CCXs habe ich eh kurz erwähnt.
Was ich da schrieb, war bezüglich der Aussage mit "scheduling auf logischen statt physischen Kernen". Aber mit SMT gibt es quasi eh nur logische Kerne auf denen das Betriebssystem Threads/Prozesse ausführen kann.

Wie du richtig sagst, ist weder das Bündeln noch das Verteilen von Threads auf logische Kerne (die sich wiederum z. B. in physische Kerne, CCXs, CCDs, CPUs gruppieren lassen) die optimale Strategie für alle Fälle.
Hängt wie gesagt stark von der Anwendung ab. Deswegen müssten das eigentlich auch die Entwickler der jeweiligen Software selbst für jede CPU-Architektur optimieren....

Ich würde es nicht IPC nennen, wenn es sich um mehrere Threads desselben Prozesses handelt. Schließlich werden die ja alle im selben Adressraum ausgeführt, aber ich weiß was du meinst: Synchronisation beim Zugriff auf gemeinsame Ressourcen (z. B. Speicher).
Genau das kann bei SMT ja zu einem Flaschenhals werden wie wir es in Benchmarks eigentlich schon seit der Einführung von Hyper-Threading sehen konnten. Abhängig von der CPU-Architektur und Anwendung halt mal mehr und mal weniger.

Na ja, ich bin auf 4-way SMT gespannt... ;)
 
Zuletzt bearbeitet :
Upvote 0 Downvote
Upvote 0 Downvote
My-konos hat gesagt. :
Hat das hier einer mal ausprobiert?

Ob es nun wirklich die Mehrleistung bringt, sei mal dahingestellt, aber grundsätzlich wäre es ja dann wieder ein Fehler in der Programmierung seitens AMD, wenn deren eigener Code suboptimale Verteilung produziert.
Zum Vergrößern anklicken....

Nein, der Windowsscheduler ist einfach Müll - dafür kann kein CPU Hersteller etwas.

Spätestens seit Level1Techs/Wendells Investigation bzgl. dem Epyc/Threadripperverhalten ist der suboptimale Zustand des Windowsschedulers bekannt.
 
Upvote 0 Downvote
So ist es,nur weil Intel die Software Hersteller diktiert trifft das leider nicht für AMD zu sonst hätten wir die Probleme seit Jahrzehnten nicht.
 
Upvote 0 Downvote
Och jetzt lasst doch mal die Kirche im Dorf. Um einen wirklich guten Scheduler zu bauen, muss man intimste Kenntnisse der CPU haben - das machste nicht mal eben so, auch nicht als Microsoft. Da muss man als Hersteller schon selbst etwas hinterher sein, wenn man was neues bringt und eine möglichst optimale Unterstützung von den Software-Kollegen sicherstellen will. Das hat nix mit Diktat der Hersteller zu tun, sondern das ist ZWINGEND erforderlich.

Genauso wie die Chiphersteller inzwischen schon bei dem Design ihrer CPUs mit den Fab-Betreibern (TSMC & Co.) bis hin zu den Herstellern der Scanner (ASML & Co.) zusammenarbeiten bzw. zusammenarbeiten MÜSSEN, damit das am Ende vernünftig lüppt. Auch da wird nix diktiert, sondern es ist ein Optimierungsniveau bzw. eine technische Komplexität erreicht, die man alleine einfach nicht mehr sinnvoll stemmen oder beherrschen kann.

Genauso ist's doch an der Schnittstelle zwischen Software & Hardware: z.B. kann man natürlich Compiler am besten optimieren, wenn man das Chipdesign intim kennt. Das macht Intel einfach für diverse Compiler für die eigenen CPUs. Ist nix verwerflich dran, sondern nutzt enorm. Sonst muss man über öffentlich bekannte Infos bzw. verfügbare Docu hinaus den steinigen Weg von trial & error gehen. Spaß macht das jedenfalls nicht. ;)
Mit einem bloßen "optimierten" Treiber ist's heutzutage jedenfalls schon lange nicht mehr getan. Das sehen wir bei GPUs schon länger, wo's mit DirectX12, Vulcan usw. eben schon Einfallstore wieder für die Hardware-Hersteller gibt, um das letzte Quentchen aus den Pixelschleudern herauszuholen. Bei CPUs ist's halt ähnlich, gab nur bis vor kurzem wenig Innovation und jetzt gibt's entsprechend Nachholbedarf.

M.E. bleibt als einziger "Vorwurf", dass Intel im Zweifel einfach mehr Ressourcen als AMD hat, um bei grundlegenden Neuerungen vor dem Launch entsprechend parallel in die Softwareentwicklung zu investieren. Wer weiß schon, wie viel Code in Windows nicht tatsächlich woanders als bei Microsoft geschrieben wurde? Was bei Linux geht, geht bei Windows prinzipiell sicherlich auch. Aber nochmal: das ist meines Erachtens GUT so, wenn es passiert.
 
Upvote 0 Downvote
Moeppel hat gesagt. :
Nein, der Windowsscheduler ist einfach Müll - dafür kann kein CPU Hersteller etwas.

Spätestens seit Level1Techs/Wendells Investigation bzgl. dem Epyc/Threadripperverhalten ist der suboptimale Zustand des Windowsschedulers bekannt.
Zum Vergrößern anklicken....
Sorry, aber das lasse ich nicht gelten. Wie der User im verlinkten Beitrag zeigt, ist das Verhalten erstens erkennbar und reproduzierbar und zweitens mittels Softwareoptimierung abstellbar.

Ja, der Scheduler von Windows taugt nicht für die entsprechende Architektur. Aber durch die Optimierung zeigt es eindeutig, dass AMD hier hätte gegensteuern müssen, gerade _weil_ schon seit den ersten Ryzen das Problem bekannt ist. Es hätte schon bei AMD auffallen müssen, dass die Last schlecht bzw falsch verteilt und zu häufig wechselt.
 
Upvote 0 Downvote
Nun, letztlich bleibt der Fakt bestehen, dass der Linux Kernel nicht ansatzweise auseinanderbricht, wenn er ein paar Kerne mehr bekommt. Man kann seine Zeit dazu nutzen, seine Arbeit von A nach B zu schedulen, oder die Workloads einfach abarbeiten. Warum MS schiebt, werden nur sie wissen.

Zwischen den Chips und dem Scheduler liegt darüber hinaus noch das Board, die Boardpartner und das BIOS.

Ich sage nicht, dass AMD die Launches der Produktpalette seit Gen 1 besseren hätte handlen sollen (und ggbf. sogar müssen), aber auch MS hatte nun 3 Jahre Zeit seinen Scheduler in den Griff zu kriegen und was ASUS mir regelmäßig als BIOS vorwirft ist ebenfalls an Lachnummern in keinsterweise zu überbieten.

Glaub mein C6H hat bisweilen mindestens 3 verschiedene Optionen Precision Boost einzustellen, zu aktivieren und zu deaktivieren. Alle laufen asynchron zueinander und wer weiß, welche der 3 die Option ist, die tatsächlich greift ????‍♂️

Schon alleine der Fakt, dass ein CPU Hersteller hinzukommen muss, um Custom OS Power Management zur Verfügung zu stellen wirft an allen Ecken Fragen auf.

Woran es tatsächlich scheitert kann ich nicht sagen. Was ich aber weiß, ist das zumindest ASUS und BIOS wie Wasser und Öl ist und das Windows Scheduler im Vergleich zu Linux hart absäuft. Ich selbst würde ich mich freuen wenn die out-of-box Erfahrung besser wäre - bevor ich es hier aber den/die CPU Herstellern ankreide, sehe ich erst noch andere in der Pflicht. Zweifellos sollte es im Eigeninteresse aller Beteiligten sein ;)

Ohne Leute die TheStilt oder auch 1usmus wäre die ganze Platform vermutlich noch 1-1.5 Jahre ihrem jetzigen Stand. Wenn ein paar helle Köpfe mehr leisten als 3 Konzerne bleibt einem nicht mehr viel übrig als Dinge gelassen - und vor allem mit Humor - hinzunehmen.
 
Zuletzt bearbeitet :
Upvote 0 Downvote
Ich steck' da nicht tief genug drin, um mir ein echtes Urteil erlauben zu können. :)

Kann's eh weder ändern noch ausweichen, und lamentieren macht mich auch nicht glücklicher.
 
Upvote 0 Downvote
Mich würde es auch brennend interressieren, wie dieser Scheduler arbeitet. Aber wahrscheinlich ist das ein paar Ebenen oberhalb meines Programmierwissens/Verständnisses.
 
Upvote 0 Downvote
unbegründete, pauschale Vorwürfe - die in dieser Form niemanden nützen sondern lediglich das Diskussionsniveau senken!
Besterino hat gesagt. :
Och jetzt lasst doch mal die Kirche im Dorf. Um einen wirklich guten Scheduler zu bauen, muss man intimste Kenntnisse der CPU haben - das machste nicht mal eben so, auch nicht als Microsoft. Da muss man als Hersteller schon selbst etwas hinterher sein, wenn man was neues bringt und eine möglichst optimale Unterstützung von den Software-Kollegen sicherstellen will. Das hat nix mit Diktat der Hersteller zu tun, sondern das ist ZWINGEND erforderlich.

Genauso wie die Chiphersteller inzwischen schon bei dem Design ihrer CPUs mit den Fab-Betreibern (TSMC & Co.) bis hin zu den Herstellern der Scanner (ASML & Co.) zusammenarbeiten bzw. zusammenarbeiten MÜSSEN, damit das am Ende vernünftig lüppt. Auch da wird nix diktiert, sondern es ist ein Optimierungsniveau bzw. eine technische Komplexität erreicht, die man alleine einfach nicht mehr sinnvoll stemmen oder beherrschen kann.

Genauso ist's doch an der Schnittstelle zwischen Software & Hardware: z.B. kann man natürlich Compiler am besten optimieren, wenn man das Chipdesign intim kennt. Das macht Intel einfach für diverse Compiler für die eigenen CPUs. Ist nix verwerflich dran, sondern nutzt enorm. Sonst muss man über öffentlich bekannte Infos bzw. verfügbare Docu hinaus den steinigen Weg von trial & error gehen. Spaß macht das jedenfalls nicht. ;)
Mit einem bloßen "optimierten" Treiber ist's heutzutage jedenfalls schon lange nicht mehr getan. Das sehen wir bei GPUs schon länger, wo's mit DirectX12, Vulcan usw. eben schon Einfallstore wieder für die Hardware-Hersteller gibt, um das letzte Quentchen aus den Pixelschleudern herauszuholen. Bei CPUs ist's halt ähnlich, gab nur bis vor kurzem wenig Innovation und jetzt gibt's entsprechend Nachholbedarf.

M.E. bleibt als einziger "Vorwurf", dass Intel im Zweifel einfach mehr Ressourcen als AMD hat, um bei grundlegenden Neuerungen vor dem Launch entsprechend parallel in die Softwareentwicklung zu investieren. Wer weiß schon, wie viel Code in Windows nicht tatsächlich woanders als bei Microsoft geschrieben wurde? Was bei Linux geht, geht bei Windows prinzipiell sicherlich auch. Aber nochmal: das ist meines Erachtens GUT so, wenn es passiert.
Zum Vergrößern anklicken....
Software Hersteller , Compiler , Firmen , Zu manipulieren ist gut???
Absichtliche Bremsen zu verbauen ist Gut damit die Konkurrenz Pleite geht???
Sicherheitslücken nicht zu schließen ist Gut nur damit man keine Leistung verliert und das Krönchen behält???
 
Upvote 0 Downvote
Nein, Puls senken, durchatmen und genauer lesen. Gemeinsam etwas zu entwickeln und zu verbessern ist gut. Gemeinsame Innovation ist notwendig und gut.
 
Upvote 0 Downvote
Casi030 hat gesagt. :
Das versucht AMD , nur wird von Intel daran gehindert , das ist das Traurige daran.
Zum Vergrößern anklicken....
Pack mal deinen Aluhut wieder ein. Intel hat, genauso wie Nvidia einfach deutlich mehr Ressourcen, um Partner oder OS Hersteller zu unterstützen. AMD kann dies so nicht leisten, daher ist die Optimierung für Intel bzw Nvidia Produkte einfach deutlich besser.

Nichtsdestotrotz müsste AMD von sich aus hier aktiv geworden sein, gerade nach dem Theater der ersten Ryzen. Windows kann es nicht sauber unterstützen und daher muss nicht erst ein Hobbyprogrammierer kommen, der AMD zeigt, dass da Potential verschenkt wird.
 
Upvote 0 Downvote
haltlose Unterstellung - woher weißt Du was die Leser wissen und was nicht? Du solltest dringend an Deinem Diskussionsverhalten arbeiten.
Dann frag ich mich warum es unter Linux funktioniert und unter Windows nicht....
Warum bestimme Codes,Befehlssätze......nicht von AMD genutzt werden dürfen......oder sagen wir mal Durften wenn ne AMD CPU von System erkannt wurde.....
Aber ich sehe schon,Fakten von vor 10-20 Jahren sind hier scheinbar gar nicht bekannt...
 
Upvote 0 Downvote
Leute, Leute, bleibt friedlich, Unterstellungen und Aluhüte helfen doch keinem weiter. Intels Core i-CPUs haben den Markt fast 10 Jahre dominiert, das aufzuholen dauert seine Zeit und selbstverständlich wehrt sich Intel mit allen - auch unfairen - Mitteln gegen den Konkurrenten. MW. wurde der Scheduler mit Win 1909 ordentlich verbessert, ich habe das Update noch nicht, man darf also gespannt sein.
 
Upvote 0 Downvote
An der Codebase von Linux schrauben zig Unternehmen und Entwickler mit ganz unterschiedlichen Schwerpunkten.

An der Windows Codebase schraubt ein Unternehmen mit - bei Windows 10 - dem Schwerpunkt als Massen- und Consumer-/Client-OS.

Bevor ich hier kriminelle Absprachen unterstelle wo für die Erklärung des Ist-Zustandes gesunder Menschenverstand reicht (wirtschaftliches Denken und Handeln bei Microsoft in Verbindung mit Prioritäten und normalen Entwicklungszyklen bei Software), halte jedenfalls ich persönlich mich haltlosen und nicht nachweisbaren Unterstellungen zurück, insbesondere wenn ich als Begründung Vorgänge aus einer Vergangenheit bemühen muss, die „18 Jahre“ zurückliegt.

Man darf Intel gerne aus diversen Gründen richtig Scheiße finden. Das ist dann aber eine Meinung und sollte man nicht mit Tatsachen verwechseln.

Vor allem gestaltet sich die Ursachen- und Lösungsfindung für tatsächliche Phänomene & Probleme nur mit Meinungen echt schwierig. Wird heute leider oft vergessen, denn Meinung haben ist halt viel leichter, hilft nur leider keinem.

Hab doch auch gar nichts gegen Dich persönlich, wünsche mir nur weniger Emotion und mehr Fachsimpelei. :D
 
Upvote 0 Downvote
Um antworten zu können musst du eingeloggt sein.
Oben Unten