AMD Ryzen 9 3950X im Test: Der Rolls-Royce unter den CPUs

[gastello]

Für Benchmarks stelle ich die Spiele exe per batch datei immer auf die höchste Priorität, das bringt teilweise einen Leistungsschub -jedenfalls sagen mir das meine Beobachtungen, weil man doch nebenbei noch Software mitlaufen hat, die dazwischenfunken kann.

Wenn Du nebenher umfangreiche Render-/Kompilierungs-/ oder Videoarbeiten ausführst - wird bei manueller Zuweisung sichergestellt - das ein Teil des Prozessors immer für diese Aufgabe reserviert bleibt. Allein unter Spielen macht dies keinen Sinn. Was Du in Benchmarks festgestellt haben willst - weiß ich nicht und kann es auch nicht nachvollziehen.

Die Affinität nutzt aus - das Reste eines Prozesses der auf einem Core ausgeführt wurde, im Speicherstatus des Prozessors verbleibt (Cache). Wenn ein Prozess so geplant wird - das er dann nachfolgend auf demselben Core ausgeführt wird - kann dies dann zu einer effizienteren Ausnutzung führen. Bei Cacheausfällen oder Löschung ist es genau andersherum. Das Ausführen mehrerer Instanzen auf einem Core ist nur bei multikernlosen Systemen von Vorteil, für eine Grafikengine die heutzutage zumeist auf leistungsfähigen Multicoresystemen (PC) mit gemeinsamem Cache ausgeführt wird - ist das nicht von Bedeutung. Apps braucht man auch unter Windows keine gesonderten oder manuellen Ressourcen mehr zuweisen. Eher hebelt man damit aus - was der Entwickler beabsichtigt.

Unter Windows 10 werden alle verfügbaren Cores dem gestarteten Prozess automatisch zugeordnet.

 

[Grestorn]

Unter Windows 10 werden alle verfügbaren Cores dem gestarteten Prozess automatisch zugeordnet.

Richtig. Was ungünstig sein kann, wenn SMT im Spiel ist. Oder wenn sich die Kerne auf zwei Chiplets verteilen. Deswegen ist es eine Optimierung, dem OS für jeden einzelnen Thread zu sagen, wo es ihn hin-schedulen können soll.

 

[gastello]

Richtig. Was ungünstig sein kann, wenn SMT im Spiel ist. Oder wenn sich die Kerne auf zwei Chiplets verteilen. Deswegen ist es eine Optimierung, dem OS für jeden einzelnen Thread zu sagen, wo es ihn hin-schedulen können soll.

Ich wüßte nicht das dort BMP hilfreich wäre. SMP bleibt fürs Gaming bisher mehr als ausreichend. CPU-Hopping und Cache-Thrashing kannst Du mittels einschalten des Gamemode mindern. BMP würde nur Sinn machen - wenn das Speicherinterface unter Spielelast zum Bootleneck wird - weil die Cores auf einen gemeinsamen Bereich zugreifen sollen (so viele nutzen Spiele aber bisher nicht aus). Dafür gäbe es dann bei Nichtausnutzung den Dynamic-Local-Mode. DLM ist unter Windows immer aktiv und verteilt je nach Auslastung automatisch - auf die Kerne - die direkten Zugriff auf den Speichercontroller haben. Das ist bei Consumer Varianten bisher nicht nötig.

 

[Grestorn]

Nun, was meinst Du ist der Grund, warum es bei manchen Spielen hilft, SMT abzuschalten, gastello? Wenn Du das beantworten kannst, OHNE dass die Erklärung ist, dass Threads auf dem selben physischen Core langsamer laufen, als auf zwei verschiedenen physischen Kernen, und dass das für bestimmte Threads zu Problemen führen kann, dann hättest Du recht.

Außerdem bedeutet BMP (Bound Multiprocessing), dass das OS so konfiguriert ist, bestimmte Prozesse fest auf bestimmte Kerne zu binden. Das meine ich aber nicht. Was ich meine, ist dass die Applikation SELBST entscheidet, welche kritischen Threads bitte NICHT auf dem selben physischen Kern laufen sollen (bei anderen mag es unkritisch sein). Das ist pure Optimierung der Applikation und hat nichts mit BMP oder SMP zu tun.

 

[BraveNeo]

@grestorn
Eine Engine bringt zuerst einmal eine eigene Core-API mit. Der Entwickler wird sich hüten Threads zu viele Systemressourcen fest zuzuweisen. Windows wird einen Task immer asynchron abarbeiten wollen und der Entwickler will das auch, weil sie zeitlich versetzt zurückgegeben werden müssen. Dabei ist wichtig das kein Thread ausführungsdediziert wird. Seit net.framework 4.x ist das sicher kein Problem mehr. Parallelen Code kann man so auch schreiben, ohne sich auf einen Threadpool beziehen zu müssen. Warum bei dir alle Threads nun auf einmal einer critical section angehören sollen musst du auch mal erläutern, dann hast du einfach keine Ahnung von Process Synchronisation. Genau dabei hilft das Sheduling, nämlich dann wenn man Prozesse nur unter Nutzung gemeinsamer Ressourcen ausgeführt werden können.

Für alles andere bietet jede Engine ein Multi-ThreadRunnable oder*Single-ThreadRunnable. Wen man SMT unter Zen deaktiviert, kann jeder Kern deutlich höher takten, weil seine Auslastung für CoreSenseMI also PurePower (Arbitrator) niedriger ausfällt. Dort liegt der Geschwindigkeitsvorteil. Dazu muss man keinem Core Threads zuweisen. Er ist trotzdem keineswegs allgemein, denn es gibt auch Spiele wo das Abschalten von SMT und oder Corezuweisung überhaupt nichts bringt. Das damalige versetzen einiger CCX ins Windows-Coreparking hat damit nichts und überhaupt nichts mit der IF zu tun.

Die Threading Klassen/Strukturen/Enumerationen/Delegaten kann man nachlesen. Threads können in Prioritäten von 0 bis 4 geplant werden, wobei die Priorität jederzeit dynamisch geändert werden kann. Darauf hast du zuweilen keinen Einfluss, weil dies je nach Fokus und Betriebssystemversion variiert. Gestartet werden sie immer im Normalmodus. Der CompletedWorkItemCount enthält alle Prioritätstypen und schließt auch die gesamte Anzahl ein. Das Threading ist dabei vom Betriebssystemhandle abhängig und an die Threadpoolklasse des Systems gebunden. Daher lässt man es auch dynamisch verwalten. Für die Mindestanzahl an async E/A und Arbeitsthreads gibt es Parameter, so dass eine zu hohe Anzahl nicht zu Leistungsproblemen führen könnte. Genau DAS versucht dir gastello seit mehreren Beiträgen unter die Nase zu halten. UMA to NUMA Mode braucht es auf Gamerprozessoren bisher nicht.

Die einzige Entwicklerbude die bisher ehrlich war, war IceFrog für Valve, denn unter Dota2/Source 2 konnte man nach Anpassung ihrer Core-API auf Zen sehen welche Zuwächse das bringen kann. Das war alles, einfach mal nicht stupide Intel in den Olymp heben. Wenn man aber so schreibt wie du ist offensichtlich was du hier bezwecken willst. Was ist im Gegensatz zu AMDs SMT an Intels HT denn besser?

Ziemlich billig was du hier ständig versuchst!

@gastello
DLM ist nicht perse unter W10 aktiv. Damals musstest du den Ryzenmaster installieren, heute den neusten Chipsatztreiber! Dann wird er automatisch ausgeführt. Gleiches gilt für die Einbindung der CCX.

 

[Grestorn]

@BraveNeo:

Erst mal Woah. Mir hier schon wieder Intel-Fanboyism zu unterstellen, ist schon ein starkes Stück. Du kannst bei allem, was ich geschrieben habe, gerne "SMT" auch durch "HT" ersetzen, zumal Hyperthreading ja nur ein Brandname für das allgemein SMT bezeichnete Feature ist. Dieser Vorwurf von Dir ist so absurd und sagt eigentlich schon alles. Außerdem zu Deiner Info gebe ich gerade mehrere 1000 Euro für einen komplett neu konzipierten Rechner auf Basis von x570 und 3950x aus. So viel zu meinem angeblichen AMD Hass.

Zweitens: Ich habe die ganze Zeit immer wieder betont, dass es mir nicht um Thread-Priorität ankommt. Man mag da optimieren können, aber das war nicht Teil meiner Aussage. Es waren immer andere, die die Prio reingebracht haben, nicht ich.

Und drittens: Auch von Thread-Synchronisation habe ich nicht gesprochen. Meine erste Multithreaded Programme habe ich übrigens Ende der 80er geschrieben, da musste man noch manuell mit Semaphoren und Signalen jonglieren. Heute ist das viel einfacher. Aber mir zu unterstellen, ich wisse davon nichts, ist mal wieder super typisch von Dir.

Und viertens: Du hast immer noch nicht verstanden, worum es mir geht. Ich weiß nicht, wie Du darauf kommst, ich wolle Windows daran hindern, Threads asynchron abzuarbeiten. Wenn ich einer Gruppe Thread die Affinity-Maske 01010101 gebe, dann werden diese Thread doch weiterhin asynchron bearbeitet und können, sollte es notwendig sein, ganz normal synchronisieren. Es wird nur verhindert, das zwei oder mehr dieser Threads auf dem selben physischen Kern landen. Ich denke, das hast Du offenbar IMMER noch nicht verstanden. Oder?

 

[gastello]

Es wird nur verhindert, das zwei oder mehr dieser Threads auf dem selben physischen Kern landen. Ich denke, das hast Du offenbar IMMER noch nicht verstanden. Oder?

Und wozu soll das gut sein? Ich verstehe den Sinn dahinter nicht - weil man damit die interne Arbitrierung aushebelt. Es ist ja bekannt das Entwickler oft ein internes Applikationssheduling bevorzugen - weil man es muß? AMD‘s SMT ist 1T Round-Robin inklusive Prioritätsüberschreibung avaible - was ja auch bedeutet - das man dynamisch erst Sibling‘s auf einen logischen Kern verteilt - wenn keine physischen Kerne mehr verfügbar sind. Verschenkt man sonst Leistung - wenn man mehr Thread‘s braucht als verfügbare physische Kerne vorhanden sind und man parallel mehr Kerne benötigt um seine Applikation am Laufen zu halten. Du weißt überhaupt nicht was im Hintergrund läuft. Man muß Thread 1 aus einem Pool daher nicht an Core0 verweisen. Wenn die Warteschlange (Queue) zu lang wird - müßte man ja jedesmal manuell einen weiteren Prozessor (Kern) hinzufügen?

Der 3950x führt bis zu 16 einzelne Threads auf seinen Kernen aus – wobei er 16 physische Kerne belastet. Erst ab 17 Threads würde er einen Logischen zuteilen. Der Sheduler funktioniert also genauso wie er soll.

PS: Ehrlich - ich bin ab hier raus - ich sehe keinen Sinn in dieser Diskussion. Du kannst mit deiner Programmierung nicht verhindern - ob ein Anwender SMT oder HT aktiv läßt oder nicht - und in bestimmten Fällen ist es sogar besser.

Ich denke das war dein Grundtenor und wo diese ganze Diskussion begann. Es ist nicht Aufgabe des Spieleentwicklers die Systemkonfiguration jedes einzelnen Anwenders zu berücksichtigen - das obliegt diesem ganz allein. Dafür gibt es Empfehlungen in welchen Umfeldern eine bestimmte Performance erreicht werden kann.

DLM ist nicht perse unter W10 aktiv. Damals musstest du den Ryzenmaster installieren, heute den neusten Chipsatztreiber! Dann wird er automatisch ausgeführt. Gleiches gilt für die Einbindung der CCX.

Okay - das stimmt - wobei Windows den Treiber mitbringt.

PPS: Ich weiß auch nicht warum alle Threads kritisch sein sollten. Aber egal.

 

[Grestorn]

Und wozu soll das gut sein?

gastello oder BraveNeo (eh die selbe Person): Wenn zwei zeitkritische Threads zeitweise auf zwei virtuelle Kerne, die aber auf dem selben physischen Kern liegen, landen, dann können sie sich gegenseitig ausbremsen. Das ist der Grund. Ganz einfach.

Einfaches Beispiel: Wenn Du 8 echte Kerne hast und die Rechenleistung pro Kern (bei einem festen Takt) und ohne SMT/HT misst, und dann den selben Prozessor nimmst, SMT aber einschaltest und wieder die Rechenleistung der dann 16 virtuellen Kerne misst, dann wirst Du feststellen, dass die Leistung pro virtuellen Kern deutlich geringer ist. In der Summe sind die 16 Kerne zwar immer noch etwas leistungsfähiger als die 8 echten Kerne, aber eben nicht wenn man sich die virtuellen Kerne individuell anschaut (sonst würde sich die Gesamtleistung des Prozessors durch Zuschaltung von SMT ja auch glatt verdoppeln).

Daraus folgt direkt, dass es für ein Spiel mit einem oder mehreren zeitkritischen Thread lohnen kann und wird, wenn diese Threads einen physischen Kern für sich alleine haben, den sie nicht mit einem zweiten virtuellen Kern teilen müssen.

 

[gastello]

gastello oder BraveNeo (eh die selbe Person): Wenn zwei zeitkritische Threads zeitweise auf zwei virtuelle Kerne, die aber auf dem selben physischen Kern liegen, landen, dann können sie sich gegenseitig ausbremsen. Das ist der Grund. Ganz einfach.

Einfaches Beispiel: Wenn Du 8 echte Kerne hast und die Rechenleistung pro Kern (bei einem festen Takt) und ohne SMT/HT misst, und dann den selben Prozessor nimmst, SMT aber einschaltest und wieder die Rechenleistung der dann 16 virtuellen Kerne misst, dann wirst Du feststellen, dass die Leistung pro virtuellen Kern deutlich geringer ist. In der Summe sind die 16 Kerne zwar immer noch etwas leistungsfähiger als die 8 echten Kerne, aber eben nicht wenn man sich die virtuellen Kerne individuell anschaut (sonst würde sich die Gesamtleistung des Prozessors durch Zuschaltung von SMT ja auch glatt verdoppeln).

Daraus folgt direkt, dass es für ein Spiel mit einem oder mehreren zeitkritischen Thread lohnen kann und wird, wenn diese Threads einen physischen Kern für sich alleine haben, den sie nicht mit einem zweiten virtuellen Kern teilen müssen.

1. es gibt keine "virtuellen" Kerne.
2. nein - die Auslastung pro Kern wird höher - nicht "niedriger"
3. der Kern ist der gleiche (man muß sich nichts mit einem zweiten virtuellen Kern teilen) - nach der Affinitäts- und Prioritätsregel wird ein Sibling (Zwilling) auf diesem Kern ausgeführt. Das bestimmt in Vorverarbeitung der Sheduler. Jedem Thread steht dazu eine gewisse Prozessorzeit zur Verfügung - wenn er abgeschlossen wurde oder noch nicht abschließend berechnet, reiht ihn der Sheduler je nach Priorität wieder in die Queue ein.

Ab 90 Prozent Kernauslastung solltest Du deiner App manuell einen weiteren Kern zuweisen. Empfehlung von Microsoft.

PS: Ich breche das jetzt hier ab - weil Du unsachlich diskutierst.

 

[Grestorn]

1. Ach ne? Du darfst sie auch "logische" Kerne nennen, wenn Du das Wort virtuell nicht magst.
2. Ich schrieb nicht Auslastung sondern Leistung, also RECHENleistung
3. Was soll der Satz bedeuten? Zwei Threads, der eine auf dem virtuellen(!) Kern 0, der andere auf dem virtuellen Kern 1, laufen auf dem selben physischen Kern. Das ist so. Wenn Du den Effekt simulieren willst, dann stell von zwei Prozessen die Core-Affinity im TaskManager entsprechend ein.

ICH diskutiere unsachlich?! Das ist ein guter Witz. Ich bringe Fakten und Du bringst ehrlich gesagt nur Schmarrn.

 

[gastello]

1. Ach ne? Du darfst sie auch "logische" Kerne nennen, wenn Du das Wort virtuell nicht magst.
2. Ich schrieb nicht Auslastung sondern Leistung, also RECHENleistung
3. Was soll der Satz bedeuten? Zwei Threads, der eine auf dem virtuellen(!) Kern 0, der andere auf dem virtuellen Kern 1, laufen auf dem selben physischen Kern. Das ist so. Wenn Du den Effekt simulieren willst, dann stell von zwei Prozessen die Core-Affinity im TaskManager entsprechend ein.

ICH diskutiere unsachlich?! Das ist ein guter Witz. Ich bringe Fakten und Du bringst ehrlich gesagt nur Schmarrn.

Du hast keine Ahnung von SMT (Zen)! Ryzen verteilt intern die Threads an Funktionseinheiten - was Du vorher wem zuweist ist dabei nutzlos. Selbst Windows muß dieses nicht berücksichtigen - weil die Priorität jederzeit überschrieben werden kann.

Was Du in Windows unter Set Affinity einstellt ist ein Core Pinning - das hat mit Threadaffinität soviel zu tun - wie ein Sack Reis der gerade in China vom Wagen fällt. Das dient dafür einem Prozess weniger Kerne zuzuweisen - um mehr Prozessressourcen verfügbar zu machen - weil der Windowssheduler automatisch alle Core oder Prozessoren mit einbezieht die im System angemeldet und verfügbar sind. Dabei geht es nur um Beseitigung eines Cacheproblems mehr nicht. Das habe ich Dir zig Post vorher schon versucht zu vermitteln.

Du scheinst im ignorieren bestimmter Hinweise - genauso ausgeprägt zu sein wie dein Freund Schaffe89.

EoD.

Schönen Abend noch.

 

[BraveNeo]

Wer virtuelle Core 0 und 1 kennt ist sowieso raus.
SetAffinitätCPU0:
1
3
7
F
1F
3F
7F
FF

Sagt eigentlich alles und Macht keinen Sinn. Jetzt tackert er schon 2 kritische Threads an einen logischen Core. Fakten.

 

[Grestorn]

Ja, EOD. Wahnsinn, was Du da alles schreibst.

"Ryzen verteilt intern Threads an Funktionseinheiten".

Diesen Satz muss man sich mal auf der Zunge zergehen lassen.

Du bist echt Klasse. Danke für die glänzende Unterhaltung.

 

[gastello]

Du bist echt Klasse. Danke für die glänzende Unterhaltung.

Lies einfach mal das Whitepaper. Interessiert Dich doch sowieso nicht. Die Kerne sind statisch partioniert - so das jeder Thread die gleiche Zeit hätte - und es dann auch nicht zu kritischer Priorisierung kommt - weil es in bestimmter Reihenfolge abgearbeitet wird. Competitives zyklisches Scheduling gäbe es auch noch. Ryzen kann einen Thread höher priorisieren und führt bei jedem eine algorithmische Prioritätsanalyse für den Datenstrom durch. Auch die Translation Lookaside Buffers arbeiten auf diese Weise - um "virtuellen" Speicher zu priorisieren. Dabei werden auch Workloads mit geringer Latenz berücksichtig.

Aber laß mal - ist schon okay. Kennt man ja nicht anders.

 

[Grestorn]

Butter bei die Fische: Verlinke doch das White Paper, das Du meinst. Oder einen Artikel, der das bespricht, was Du behauptest.

Alles was Du schreibst ist ein Gemenge von Buzzwords die alleine erst mal so GAR nichts bedeuten. Aber Du kannst mir doch sicher eine Quelle verlinken, die das alles, was Du da aufzählst, detailliert erklärt. Dann kann ich mir ein Bild machen, ob das irgendetwas mit dem Thread-Scheduling eines OS zu tun hat, was ich erst mal nicht annehme.

Ich freu mich ja dann darauf, diese tollen revolutionären Features nutzen zu können, wenn nächste Woche mein 3950x kommt.

Ach ja, wie erklärst Du Dir denn, dass auch AMD bei einigen Spielen Leistung verliert, wenn man SMT aktiviert? Das dürfte ja nicht passieren, wenn der tolle Prozessor Threads selbständig, ohne zutun des OS auf andere "Funktionseinheiten" (was ist das überhaupt? Meinst Du einen Kern? Oder ein Chiplet?) verschieben kann...

 

[BraveNeo]

Butter bei die Fische: Verlinke doch das White Paper, das Du meinst. Oder einen Artikel, der das bespricht, was Du behauptest.

Alles was Du schreibst ist ein Gemenge von Buzzwords die alleine erst mal so GAR nichts bedeuten. Aber Du kannst mir doch sicher eine Quelle verlinken, die das alles, was Du da aufzählst, detailliert erklärt. Dann kann ich mir ein Bild machen, ob das irgendetwas mit dem Thread-Scheduling eines OS zu tun hat, was ich erst mal nicht annehme.

Ich freu mich ja dann darauf, diese tollen revolutionären Features nutzen zu können, wenn nächste Woche mein 3950x kommt.

Ach ja, wie erklärst Du Dir denn, dass auch AMD bei einigen Spielen Leistung verliert, wenn man SMT aktiviert? Das dürfte ja nicht passieren, wenn der tolle Prozessor Threads selbständig, ohne zutun des OS auf andere "Funktionseinheiten" (was ist das überhaupt? Meinst Du einen Kern? Oder ein Chiplet?) verschieben kann...

Verlink du doch erst mal was du behauptest? Tacker bei der Allianz einfach weiter Cores an deine Threads. Wahrscheinlich haben die ausreichend CPU Resscoure.

Das steht auch schon weiter oben. Aber wir haben 1980 unsere Threads an Cores getackert da machen wir das 2019 auch.

Wegen Leuten wie dir gibt es kaum Fortschritt, warst du nicht genau der, der dx12 im 3dc verdammt hat? Komisch nun setzt Nvidia mit DXR drauf und dx12 ist ja so nice.

Buzzwords liefert du nur selbst, ohne deren Bedeutung zu kennen, weil dir logisch und virtuell nicht mal ein Begriff ist. Wer soetwas als Entwickler verwechselt schießt sich imo selbst ab.

Es gibt keinen virtuellen Kern 0 und 1 und auch keinen logischen Kern 0 und 1. Soviel dazu du Experte.

 

[Grestorn]

Zunächst mal, einige Dich mal mit Dir selbst, ob Du lieber den Namen "gastello" oder "BraveNeo" nutzen willst.


Zum Begriff virtuelle Kerne:

Simultaneous Multithreading – Wikipedia

"Von der Multicore-Architektur unterscheidet sich SMT dadurch, dass die dem System gemeldeten Prozessoren einer SMT-CPU keine unabhängigen Prozessoren sind. Bei SMT teilen sich die virtuellen Prozessoren den Zugriff auf dieselben Datenverarbeitungseinheiten (ALU/FPU), während im Mehrkernprozessor jeder Kern seine eigene Datenverarbeitungseinheit besitzt."


Zum Begriff "Logischer Kern"



Wie nennst Du denn die 16 "Dinger", die da angezeigt werden? Windows nennt sie jedenfalls "Logischer Prozessor". Eigenartig.

Physische Kerne sind das, was Windows als "Cores" anzeigt.

Zum Thema wie Windows Logische Kerne (oder eben "Logical Processors") behandelt, beschreibt dieser Artikel:

LOGICAL_PROCESSOR_RELATIONSHIP (winnt.h) - Win32 apps | Microsoft Docs


"Virtueller Kern", "Logischer Kern", "Virtueller Prozessor" und "Logischer Prozessor" sind alles Synonyme für das selbe Ding.


Und Du willst uns weiterhin weiß machen, dass Ryzen am OS vorbei seine Threads irgendwie anders auf die logischen Prozessoren verteilt, als das OS es vorgibt? Macht Ryzen dann wohl auch gleich noch das Scheduling selbst?

 

[gastello]

Zunächst mal, einige Dich mal mit Dir selbst, ob Du lieber den Namen "gastello" oder "BraveNeo" nutzen willst.

Es gibt tatsächlich keinen virtuellen Kern 0 und 1. Oder nennst Du physische Kerne 0 und 1 - und logische Kerne 0 und 1. Auf physischen Zencores beansprucht der logische Anteil 5 Prozent der Gesamtfläche (er ist physisch vorhanden) und kann einen Effizienzgewinn von 20 Prozent ausmachen - der dann bei aktiviertem SMT einen Kern als zwei logische aufteilt - daran ist absolut nichts virtuell. Threads werden mit Tags markiert und selbst wenn zwei aktiv sind - werden beide isoliert.

Das Zen Security-Whitepaper findest Du auf AMD.com - da wirst Du doch als SW noch hinklicken können - oder? Du solltest Dir selbst überlegen welchen Namen Du hier tragen willst. Von hardwarespezifischen Eigenschaften bezüglich AMD Hardware weißt Du jedenfalls nicht viel.

Setze mich Bitte auf ignor - weil ich keine Lust habe mich auf so herablassende Weise von Dir behandeln zu lassen. Mir ist dabei egal was Du bist oder machst.

 

[Grestorn]

Es gibt tatsächlich keinen virtuellen Kern 0 und 1. Oder nennst Du physische Kerne 0 und 1 - und logische Kerne 0 und 1.

Warum beantwortest Du mir nicht einfach die Frage, wie Du die 16 "Dinger" nennst, die Windows da anzeigt? Einfache Frage... Wenn Du der tolle Hecht bist, der Du sein möchtest, wirst Du doch diese einfache Frage beantworten können.

Ich habe auf der AMD Webseite kein kostenloses Whitepaper zu Ryzen gefunden. Nur einige über Epyc. Zu viele um sie alle zu lesen. Sonst hätte ich Dich nicht gefragt, welches Du genau meinst.

Du bist schon lange auf Ignore bei mir (mit beiden Namen), aber heute habe ich echt Spaß daran, Dich einfach mal als das zu outen, was Du bist.

Der Satz

"Auf physischen Zencores beansprucht der logische Anteil 5 Prozent der Gesamtfläche (er ist physisch vorhanden) und kann einen Effizienzgewinn von 20 Prozent ausmachen - der dann bei aktiviertem SMT einen Kern als zwei logische aufteilt - daran ist absolut nichts virtuell. Threads werden mit Tags markiert und selbst wenn zwei aktiv sind - werden beide isoliert."

ist der Hammer. So viel Worte und KEINERLEI Aussage. Schon grammatikalisch macht er keinen Sinn. Und ich kann ihm nicht im Ansatz entnehmen, was Du sagen willst. Der "logische Anteil" teilt "einen Kern als zwei logische auf"? Ich dachte, es gibt keine logischen Kerne?!

"Virtuell" heißt übrigens nur "nicht reell" oder "vorgetäuscht". (Virtualitaet – Wikipedia). Und das ist genau das, was ein solcher logischer Kern ist.

 

[gastello]

Warum beantwortest Du mir nicht einfach die Frage, wie Du die 16 "Dinger" nennst, die Windows da anzeigt? Einfache Frage... Wenn Du der tolle Hecht bist, der Du sein möchtest, wirst Du doch diese einfache Frage beantworten können.
Dein Niveau ist unterirdisch.

Ich habe auf der AMD Webseite kein kostenloses Whitepaper zu Ryzen gefunden. Nur einige über Epyc. Zu viele um sie alle zu lesen. Sonst hätte ich Dich nicht gefragt, welches Du genau meinst.
Whitepaper sind in jedem Fall kostenlos aber nicht für jeden zugänglich - suche einfach weiter.

Du bist schon lange auf Ignore bei mir (mit beiden Namen), aber heute habe ich echt Spaß daran, Dich einfach mal als das zu outen, was Du bist.
Gut - dann ganz unten eine Antwort auf deine These. Was Du bist weiß ich jetzt.

Welcher von den Kernen - die der Taskmanager im Ressourcenmonitor auflistet (dieser scheint Dir heute ja mächtig zuzusetzen) - ist nun ein logischer (von mir aus auch virtueller) und welcher ein physischer Kern - erleuchte mich!

Ich habe genau das geschrieben was auch ich auch gemeint habe - SMT ist NICHT nur ein virtueller Kern. Ich meine auch nicht - nicht reell oder vorgetäuscht.

Hier kannst Du nachlesen - das was du behauptest nicht immer zutrifft (aber lass mich raten - auch die Hechte sind alle nur blöde Spinner?): Testing Ryzen 9 with SMT On vs. SMT Off - TechSpot