Denke schon das man damit rechnen sollte.
Ryzen 7000 mit mehr Cache: AMD stellt gleich drei X3D-Modelle vor
- Ersteller HWL News Bot
- Erstellt am
Supermax2003
Urgestein
- Mitglied seit
- 04.12.2003
- Beiträge
- 6.987
Falls die 3D-Cpus jemals erscheinen sollten. Wo sind die News? Entweder eine Verschiebung oder Feuer frei jetzt.
Zum Glück hast Du das geschrieben, jetzt muss AMD ja reagieren. 👍
n3cron
Enthusiast
Ich denke die 7950X3D wird am besten abschneiden, genauso wie die 7900X3D.. die haben den Vorteil gegenüber der 7800X3D das sie über ihr zweites CCD auch auf hohe Taktrate gehen könne. Das führt unterm Strich dazu das Je nach Game Präferenz die Leistung immer möglichst oben ist. Also in diesen Games in denen der 5800X3D das nachsehen hatte wegen dem geringen Takt, wo es nicht auf den Cache ankommt.
Stellt sich nur die Frage woher das System weiß welches Spiel wovon profitiert.
Ich habe ehrlich gesagt null Bock das nachher bei jedem game selbst einstellen oder zuweisen zu müssen...
Ich habe ehrlich gesagt null Bock das nachher bei jedem game selbst einstellen oder zuweisen zu müssen...
n3cron
Enthusiast
Ich denke entweder mit predefined Profilen oder aber per Benchmark, so wie der Controller von SSDs dazu lern bzw. häufig aufgerufenen Daten priorisiert. Das System wird einfach ausprobieren können. Vielleicht kann man das aber auch an Merkmalen erkennen und dem Windows Scheduler dieser Merkmale "trainieren" oder so.
Wie jemals erscheinen ,sind doch offiziell angekündigt worden.
Nur Geduld Brauner😎
Du meinst vielleicht Monat und nich Montag....
Tech Enthusiast
Enthusiast
Wie kommst Du zu der Schlussfolgerung?
Warum würde das für den kleineren Chip sprechen?
Ich vermute Mal das es hier viele skeptisch sehen das der schnelle Chiplet über den anderen Chiplet seinen 3DCache Beziehen muss und das das ganze anscheinend mit Microsoft stehen oder fallen könnte.Wie kommst Du zu der Schlussfolgerung?
Warum würde das für den kleineren Chip sprechen?
Sprich das es abhängig von der Software ablaufen wird.
Wirkt es sich auf die Latenzen aus das ansprechen allgemein wird es Konflikte geben ?
Könnte sogar im schlechtesten Fall die Performance aus diesen Gründen sogar Mal schlechter sein usw.
Das muss nicht sein aber erstmal nicht ganz abwegig das es nicht reibungslos laufen könnte.
Das werden dann die Tests zeigen.
Beim 7800X3D hat man das alles nicht bis auf den niedrigeren Takt der ein wenig Performance kostet gegenüber dem 7700X was aber wieder durch den Cache ausgeglichen werden kann und wo er besonders skaliert an Leistung zu gewinnen kann.
Gab ja Recht wenig neue Spiele wo der 5800X3D auf die Leistung des 5800X zurück gefallen ist.
Zuletzt bearbeitet:
Tech Enthusiast
Enthusiast
Aber das ist doch gar nicht so?
Beide haben ihren eigenen Cache. Eines hat nur mehr davon.
Ja die haben beide ihren eignen Cache aber auf dem langsameren CCD wohlmöglich 5GHz sitzen noch mal die 64MB 3D Cache.
Das schnellere CCD hat also keinen 3D Cache Huckepack.
Zuletzt bearbeitet:
Tech Enthusiast
Enthusiast
Also das Beste aus beiden Welten.
Maximaler Takt, oder maximaler Cache. Je nach game braucht man das eine, oder das andere.
Ergo eher ein starker Bonus für die 2 CCD Chips, gegenüber dem 7800X3D.
Selbst wenn Microsoft da was in Windows für machen müsste (und das, was sie machen ist weiß Gott nur ein Bruchteil von dem, was die CPU selber macht), kann man davon ausgehen, dass es besser läuft mit der Option beide Welten zu verbinden, als überhaupt nur eine der Welten zu haben.
n3cron
Enthusiast
Ihr habt beide Recht, es gibt einen ganz normalen Cache wie bei den normalen 7950X mit dem Unterschied einer hat noch den zusätzlichen "gestapelten Cache" oben drauf. Im schlimmsten Fall hat man "nur" die Performance eines normalen 7950X ... die jetzt auch nicht so unterirdisch ist wie hier einige meinen
Auch ganz interessant die sich mit meiner Vermutung möglicherweise bestätigt:
www.tomshardware.com
Der Gain mit Speicher OC ist jetzt nicht so weltbewegend. Ja er ist da, aber der Gegenwert eher madig.
Beitrag automatisch zusammengeführt:
Auch ganz interessant die sich mit meiner Vermutung möglicherweise bestätigt:
AMD Ryzen 9 7950X vs Intel Core i9-13900K Face Off
Zen 4 vs Raptor Lake, Fight!
www.tomshardware.com
Zuletzt bearbeitet:
Ne, das eine CCD wird nicht auf den Cache des anderen Zugreifen - ergibt auch absolut keinen Sinn, weil der Cache Zugriffe über die IF abfedern/verringern soll - was soll es also bringen über die gleich lahme IF Verbindung zum anderen CCD zu laufen? Da kannste auch direkt GB weise Daten aus dem RAM nutzen, denn der hängt auf halben weg von CCD1 über IO Die zu CCD2 eben am IO Die in der Mitte.
Es wäre schön, wenn es so wäre
Die CPU selbst macht da quasi gar nix...
Die kann auch ohne Logik gar nichts machen. Also ne Logik wie es Intel versucht einzubauen zwischen den E-Cores und P-Cores - aber auch das funktioniert nur reaktiv und gemessen am Performanceboost zwischen Win 10 und 11 eher so semi gut.
Rein vom Code her legt der Windows Threadscheduler den Workload eines Software Threads auf einen der beiden Threads eines Cores. Und exakt diese Bindung zwingt den Workload auf den CCD1 oder CCD2. Da gibt es quasi nichts, was das CPU seitig irgendwie steuert.
Was heute existiert ist das benennen der schnellsten Cores - das wird dem Threadscheduler mitgeteilt, sodass Workloads mit niedriger Last primär auf die schnellsten Cores gelegt wird. Das aber ist auch schon nur ne absolute Krücke - denn sobald genug Last existiert kann keine Software der Welt wissen, ob jetzt die µOps des einen oder irgendwelcher anderen Tasks zu bevorzugen sind. Nicht machbar...
Wer hier glaubt, das wäre sozusagen das "Beste" aus beiden Welten glaubt scheinbar auch an den Weihnachtsmann.
Was sein kann ist, dass es mit genug Handarbeit den besten Kompromiss liefert - das würde ich definitiv nicht abstreiten. Aber die Beste Lösung wäre beiden CCDs den Cache drauf zu packen und irgendwie dafür zu sorgen, dass das taktseitig keine nennenswerte Differenz macht. Wahrscheinlich ist selbst der Takt ansich nichtmal die größte Baustelle dabei - sondern eher die Kosten
Der Huckepack Cache scheint nach wie vor nach Produktion des Dies oben drauf gebracht zu werden. Was es anfällig für Fehler macht? Mindestens aber kosten die weiteren Schritte Zeit und Geld.Beim 5800X3D war die "Begründung" damals, dass man mit der Spannung nicht so hoch gehen kann/darf - hier hätte man mMn elegant bei einem Zen4 Design eine bessere Lösung finden können. Bspw. entkoppelte Spannung von Cache und CPU Bereich. Der Takt selbst war eigentlich nie wirklich ein Grund. Auch nicht die Temperaturen. Das sind nur Resultat der Produktionsentscheidung die Dinger abzuschleifen und den Cache drauf zu bringen.
Ne, im schlimmsten Fall laufen Threads, die vom größeren Cache profitieren, weil durch diesen IF Zugriffe verringert werden auf dem CCD, wo der Cache nicht in der vollen Größe drauf ist und gleichsam laufen die Threads, die vom Takt profitieren auf dem dann niedriger taktenden anderen. -> wie viel das kosten wird, ist nicht klar aktuell. Bei 1T Performance reden wir wahrscheinlich im Worst Case um 10-15% -> so was die Taktdifferenzen angeht.Ihr habt beide Recht, es gibt einen ganz normalen Cache wie bei den normalen 7950X mit dem Unterschied einer hat noch den zusätzlichen "gestapelten Cache" oben drauf. Im schlimmsten Fall hat man "nur" die Performance eines normalen 7950X ... die jetzt auch nicht so unterirdisch ist wie hier einige meinen
Das ist exakt das selbe Thema, warum die 1T bis Teillast Performance bei den dual CCD Modellen seit Zen2 reeelativ stark schwankt, was die Konsistenz der Wertermittlung angeht. Vor allem wenn man eben nicht unter Laborbedingungen testet. Das OS wird häufig den Task auch auf dem falschen CCD abladen.
Bspw. so:
Was auch immer Windows geritten hat, da jetzt den zweiten CCD auf Core 2 Last zu geben... -> es dudelt hier ein Livestream in nem Browser. Das sind die 6%.
Btw. der 10. Core von vorn - bei mir ist das der schlechteste. -> wirklich toll funktioniert das mit dem Steuern über den Threadscheduler definitiv nicht...
Mal schauen wie AMD das löst. Sie wollen wohl angeblich Whitelists pflegen... Das riecht nach ner eher halbgaren Lösung
Zuletzt bearbeitet:
n3cron
Enthusiast
Natürlich ist das dumm, im ideal fall wird der zweite CCD auf schlafen/Standby gelegt und bei bedarf aktiviert.
Ich kenne das Problem ich habe den 3900X.. allerdings bis auf hier und da ist läuft es trotzdem erstaunlich gut. Intel hatte am Anfang mit den Hybrid Prozessoren auch Probleme.
Ich bin mir sicher das es immer noch ab und zu mal passiert das der falsche Prozessor angesprochen wird.
MehlstaubtheCat
Urgestein
Zugriff über den IF von einem zum anderen CCD ist schneller als über den Ram zu gehen.
Aber klar mit höheren Latenzen verbunden als innerhalb des CCDs zu bleiben.
Ich schreibe Windows vor, welcher Kern welches Programm bekommt mit Process Lasso, ich vertraue da werde AMD noch Microsoft.
Aber klar mit höheren Latenzen verbunden als innerhalb des CCDs zu bleiben.
Ich schreibe Windows vor, welcher Kern welches Programm bekommt mit Process Lasso, ich vertraue da werde AMD noch Microsoft.
Tech Enthusiast
Enthusiast
Es wäre schön, wenn es so wäre
Die CPU selbst macht da quasi gar nix...
Control unit - Wikipedia
Woher sollte Software wissen, wohin die Anfragen gehen sollen?
Wenn Software das wirklich so machen würde, wie Du es beschreibst / meinst, könnte man mit Software wie im Film die Hardware grillen.
Natürlich ist da nur eine API und was dahinter passiert ist ne Blackbox für das OS und läuft über die CU der CPU.
Was genau da nun Windows machen soll hab ich noch nicht ganz verstanden, weil alle Erklärungen dazu auf einer falschen Annahme beruhen. Nämlich, dass Windows die Aufgaben an die CPU Kerne verteilt.
Dem ist nicht so,... Windows kann bestenfalls der CPU sagen: "Hier ist ne Aufgabe, die eher eine starke CPU braucht!" oder "hier ist ne Aufgabe, die eher mehr Cache braucht!".
Die CU bekommt diese Info dann durch die API und kann das dann entweder befolgen, oder es komplett ignorieren,...
.. in der Realität wird das vermutlich so laufen, dass Windows sagt: "Need Cache Cores!" - die CU dann die Aufgabe für ein paar Nanosekunden splittet und checked, wo es wirklich schneller geht... und dann die volle Workload dahin umschichtet. Egal, was Windows sagt.
Natürlich wäre es toll, wenn Windows immer direkt richtig liegt. Das erspart paar Nanosekunden, was bei CPU Lasten durchaus spürbar ist. Aber es wird mitnichten so sein, dass die CPU hilflos ist ohne Windows.
Es wird immer Defaults geben und die CU wird immer recht gut wissen, was da verbaut ist und was sie damit tun kann.
Na, dann mache ich das eben.
Ich sehe die Sache mit der Priorisierung beim Scheduling auch problematisch. Keine Ahnung wie das überhaupt klassifiziert werden könnte. Angenommen man hat einen Prozess, von dem man als Anwender weiß, dass er von mehr Cache (oder von mehr Takt) profitiert, könnte man dann nicht manuell per `affinity` eine entsprechende Menge von Cores zuweisen und so das Problem selbst lösen?
Das Scheduling wird wohl in Zukunft die Cache Miss Rate berücksichtigen, falls unterschiedliche Cache Größen festgestellt werden. Vermutlich wird aber nichts anderes übrig bleiben, als auszuprobieren, ob der Wechsel auf einen Cache-Kern Vorteile bringt. Standardmäßig wird, denk ich mal, die höhere Frequenz priorisiert und dann eben bei wenig Hits gewechselt.
Das Scheduling wird wohl in Zukunft die Cache Miss Rate berücksichtigen, falls unterschiedliche Cache Größen festgestellt werden. Vermutlich wird aber nichts anderes übrig bleiben, als auszuprobieren, ob der Wechsel auf einen Cache-Kern Vorteile bringt. Standardmäßig wird, denk ich mal, die höhere Frequenz priorisiert und dann eben bei wenig Hits gewechselt.
Zuletzt bearbeitet:
Die CPU verteilt Prozesse nicht ohne weiteres auf die Kerne. Das macht der Scheduler im Kernel. Zumindest bei Windows und bei Linux. Das war schon immer die Aufgabe vom Betriebssystem (Man kann ja einen Prozess im Taskmanager auf einen Kern festlegen. Der Scheduler legt fest, wo die Prozesse und Threads laufen sollen, und wer gerade läuft. In Windows laufen ja hunderte Thread gleichzeitig bei maximal 32 Kernen auf dem Desktop. Die CPU hilft da mit, aber die Hoheit hat das Betriebssystem. Dafür gibt es in CPUs den Kernel Mode. Als ich im Studium am Unix Kernel programmiert habe, gab es noch keine Mehrkern CPUs auf dem Desktop. Der keine Mainframe in der Uni hatte aber 8 CPUs. Heute CPUs können mit ihren AI Funktionen den Code umstrukturieren, um die CPU Resourcen besser auszulasten. Damit Programmteile nicht auf den E-Cores ausgeführt werden, musste Microsoft den Scheduler anpassen bzw. die Programme mussten das über Patches korrigieren. Da gab es keine Microcode Updates für, von denen man etwas mitbekommen hätte. Die Hauptkerne der Ryzen-CPUs auf den jeweiligen CCDs werden an den Kernel gemeldet, damit der Scheduler die Prozesse bei Single-Core Last auf die besten Kerne verteilen kann.
Zuletzt bearbeitet:
Supermax2003
Urgestein
- Mitglied seit
- 04.12.2003
- Beiträge
- 6.987
Sehr bald ist Februar, und es gibt noch nicht mal Preisupdates. Wie war das beim 5800X3D, ab wann sind da die Infos geflossen? Sieht stark nach einer Verschiebung aktuell aus.
@Supermax2003 Mal den Teufel mich an die Wand 
Hab hier alles liegen fürs neue AM5 System…
Und die Finger jucken bereits…
Interessant:
videocardz.com
Hab hier alles liegen fürs neue AM5 System…
Und die Finger jucken bereits…
Beitrag automatisch zusammengeführt:
Interessant:
AMD Ryzen 7000X3D series now listed as 'unlocked for overclocking' - VideoCardz.com
AMD seems confused about overclocking support for Ryzen 7000X3D series AMD unlocks OC for Ryzen 7000X3D or this is just another mistake? AMD product pages may sometimes be quite misleading. The pages for Ryzen 7000X3D already made the news earlier this month when AMD had updated them with a...
videocardz.com
Zuletzt bearbeitet:
- Mitglied seit
- 15.11.2002
- Beiträge
- 27.054
Nun doch oder ein Fehler: Ryzen-7000X3D-Prozessoren mit OC-Unterstützung - Hardwareluxx
Nun doch oder ein Fehler: Ryzen-7000X3D-Prozessoren mit OC-Unterstützung.
www.hardwareluxx.de
Aber leider hat fdsonne es schon richtig geschrieben. Der Threadscheduler vom OS bestimmt tatsächlich, welcher Thread auf welchem Kern läuft. Du beschreibst genau das, was Intel mit dem Hardwarescheduler macht. AMD hat aber keinen Hardwarescheduler, so dass das OS über die Treiber-API und das Ressourcenmanagement über den Scheduler im Kernel des OS die Zuweisung macht. Und zwar ausschließlich! Ich glaube, dass AMD richtig Druck durch die Raptoren hat und eigentlich nur ein Nachfolger des 5800X3D geplant war (7800X3D) - genau so war es auch am Anfang in diversen Leaks kommuniziert worden! Den 7950X3D und den 7900X3D haben die aus der Not heraus geboren, damit sie überhaupt konkurrenzfähig bleiben. Die Raptoren können halt Zocker-CPUs sein, aber auch gute Anwendungs-CPUs. Da musste AMD reagieren! Deshalb ist ja auch solch eine halbgare Lösung über eine Whitelist rausgekommen - das hat fast was von 80er-Jahre-Style……Haben CPUs quasi schon immer.Control unit - Wikipedia
en.wikipedia.org
Woher sollte Software wissen, wohin die Anfragen gehen sollen?
Wenn Software das wirklich so machen würde, wie Du es beschreibst / meinst, könnte man mit Software wie im Film die Hardware grillen.
Natürlich ist da nur eine API und was dahinter passiert ist ne Blackbox für das OS und läuft über die CU der CPU.
Was genau da nun Windows machen soll hab ich noch nicht ganz verstanden, weil alle Erklärungen dazu auf einer falschen Annahme beruhen. Nämlich, dass Windows die Aufgaben an die CPU Kerne verteilt.
Dem ist nicht so,... Windows kann bestenfalls der CPU sagen: "Hier ist ne Aufgabe, die eher eine starke CPU braucht!" oder "hier ist ne Aufgabe, die eher mehr Cache braucht!".
Die CU bekommt diese Info dann durch die API und kann das dann entweder befolgen, oder es komplett ignorieren,...
.. in der Realität wird das vermutlich so laufen, dass Windows sagt: "Need Cache Cores!" - die CU dann die Aufgabe für ein paar Nanosekunden splittet und checked, wo es wirklich schneller geht... und dann die volle Workload dahin umschichtet. Egal, was Windows sagt.
Natürlich wäre es toll, wenn Windows immer direkt richtig liegt. Das erspart paar Nanosekunden, was bei CPU Lasten durchaus spürbar ist. Aber es wird mitnichten so sein, dass die CPU hilflos ist ohne Windows.
Es wird immer Defaults geben und die CU wird immer recht gut wissen, was da verbaut ist und was sie damit tun kann.
Na, dann mache ich das eben.
Beim 7900X3D stelle ich mir das noch grotesker vor… Wie sollen da denn genau die Kernaufteilungen, bzw. die Zusatz-Cache-Aufreilungen sein? Also entweder man hat 8 zu 4 Kerne und den Zusatzcache auf dem 8er Chiplet - dann könnte man mit der gleichen Zuordnung in der Whitelist arbeiten. Aber bei 6 zu 6? Hat dann nur das eine 6er-Chiplet den Zusatzcache? Das wäre ja totaler Blödsinn, da man dann in Spielen auf 2 Kerne mit dem Zusatzcache (im Verhältnis zum 7800X3D, 7950X3D) verzichten würde. Aber genau so wird das kommen! Dem 7900X3D wird der Cache auch nur auf einem Chiplet zur Verfügung stehen! D.h. nur 6 3D-Cache-Kerne und eine andere Whitelist Zuordnung… Also wie schon erwähnt, irgendwie alles aus der Not geboren….. Kaufe trotzdem den 7950X3D blind, da ich alle anderen Komponenten schon bei mir rumliegen habe. Besser, ich denke da nicht mehr genauer darüber nach….
Zuletzt bearbeitet:
Tech Enthusiast
Enthusiast
Hast Du für die Aussage einen Link, wo ich das nachlesen könnte?
Das behaupten so viele in Foren (die finde ich dann über Google), aber das klingt einfach wild und undenkbar deppert, wenn AMD diesen Schritt nicht so löst, wie CPUs das seit den Lochkarten lösen.
Eigentlich jede komplexe Hardware hat so was, ... weil es einfach Sinn macht strikt zwischen Umsetzung und Anfrage zu trennen. Wenn ich als Anfrager von IRGENDWAS vorher erst verstehen muss, WIE die andere Seite das lösen könnte,... dann muss ich ja genauso viel über deren Produkt wissen, wie sie selber. Ansonsten kann das ja nur schief gehen?!
Man stelle sich vor, dass die Auto Software genau wissen müsste wie jeder einzelne Teil im Motor läuft, damit sich das Auto bewegt.
Und als IT / Software-Entwickler kann ich ganz klar sagen: Programmieren auf einer CPU ist um ein VIELFACHES einfacher, als für eine GPU. Also muss es da eine CU geben. Ohne wäre das gar nicht machbar. Sonst müsste ja auch jede Entwicklungsumgebung den Code entsprechend der Ziel CPU anders kompilieren, was definitiv nicht passiert. Es wird nur zwischen 32 und 64 bit unterschieden.
Und ich kann natürlich der CPU sagen, dass ich nen eigenen Kern für eine Aufgabe brauche, oder 20 Threads, oder auch 1000 Threads (nicht identisch zu den Thread Angaben bei CPUs) . Was die CPU aus meiner Anfrage dann macht, ist ihr Ding.
Die Idee, dass das OS zwischen mir als Softwarentwickler und AMD als Hardwarehersteller übersetzen soll, wo sie die Hardware nicht selber bauen und die Software natürlich gar nicht kennen können, ist so wild, dass ich es ehrlich gesagt nicht glauben kann. Das schreit einfach nur "unmöglich" an nahezu jedem Ende.
Alles in der IT läuft über APIs. Software wie Hardware. Schnittstellen an jedem Ende. Nummer 1 Regel dabei: Jede Schnittstelle ist eine Blackbox. Und das ist bei CPUs seit den Lochkarten auch so gewesen.
Nun soll AMD das einfach mal "weglassen"?
Die Zuordnung passiert nicht im Anwendungsbereich, sondern direkt im Kernel! Deshalb gibt es ja auch die Treiber für die Hardware! Wenn das so wäre, wie Du es beschreibst, würde es auch keine Bluescreens geben, denn dann würde die CU Anfragen im z.B. falschen Speicherbereich unterbinden - macht sie aber nicht….. Das Problem heutzutage im Bereich Softwareentwicklung ist, dass alle nur noch mit vorgefertigten APIs und Softwarelösungen programmieren. Aber die Maschinensprache ist seit den ersten PCs die selbe! Wer lernt denn heute noch Assembler? Eben, keiner mehr…
Also nochmal: Der Scheduler, der ein Teil des Kernels ist!!!! bestimmt die Threads - ausschließlich! Intel hat mit dem Thread-Director genau das in seinen Hybrid-CPUs, was Du als CU beschreibst (eine CU ist aber eigentlich was anderes). Es ist ein HW-Scheduler, der die Thread-Zuweisung übernimmt und ggf. anpasst! Dem Kernel des OS wird praktisch darüber vorgegaukelt, alle Kerne wären gleich! Bei AMD gibt es sowas nicht! Dort muss das OS (Scheduler im Kernel) die Zuweisung übernehmen - aber der Scheduler im Kernel kennt keine unterschiedlichen Kerne, oder andere Spezifika! Damit er die Priorisierung optimal ausführen kann, nutzt er z.B. die Treiberebene und das Ressourcenmanagement des OS, die ihm die Auswahl erleichtern. Ein PC hat noch nie anders funktioniert - er kennt nur Maschinensprache! Deshalb brauchst Du einen Übersetzer - und genau der ist die Schnittstelle! Das hat auch nichts mit AMD zu tun, sondern gilt generell! AMD hat nur jetzt zusätzlich das Problem, dass sie eben keinen HW-Scheduler haben (das ist eigentlich fatal!!!!!). Jetzt muss es das OS selbst machen und dem Scheduler im Kernel die richtige Auswahl ermöglichen. Und genau darum geht es: Wie gut funktioniert das, wenn es selbst bei CPUs mit komplett gleichen Kernen oft nicht sauber funktioniert? Microsoft wird ständig das OS anpassen müssen, damit das beim 7950X3D und beim 7900X3D funktioniert! Deshalb die Whitelist-Lösung! Das ist alles aus der Not geboren, ohne Mist! Ich bin mir sicher, dass das auch der Grund ist, warum die CPUs verschoben werden. Der 7800X3D ist nicht das Problem, sondern eben der 7950X3D und noch mehr der 7900X3D.
Eben weil die neue CPU-Generation Hybrid-CPUs sind und das OS es ohne ständige Anpassung an die entsprechende Anwendungssoftware einfach nicht kann. Deshalb hat Intel den Thread-Director entwickelt - sicher nicht aus Spass an der Freude! Und was macht AMD? Die können nicht so einfach einen HW-Scheduler einbauen, denn das geht vielleicht bei einer monolithischen CPU. Aber bei einer CPU-Architektur mit mehreren Chiplets? Wo soll er denn sitzen? Er müsste ja dann im zentralen Steuerchip sitzen und dann über die viel langsameren Leitungen (Latenzproblem) die einzelnen Chiplets abfragen/steuern.
Deshalb hat AMD auch keine solche Lösung. Das ist halt Fluch und Segen einer solchen Architektur!
Dein Beispiel mit dem Auto ist sogar das beste Beispiel dafür. Denn die Software der Headunit steuert eben so gut wie gar keine primären Fahrfunktionen! Das machen die einzelnen Steuergeräte, die nichts mit der Software der Headunit gemeinsam haben! Das passiert direkt hardwarenah ohne API, Übersetzer, oder anderen softwaretechnischen Trennungen!
Also nochmal: Der Scheduler, der ein Teil des Kernels ist!!!! bestimmt die Threads - ausschließlich! Intel hat mit dem Thread-Director genau das in seinen Hybrid-CPUs, was Du als CU beschreibst (eine CU ist aber eigentlich was anderes). Es ist ein HW-Scheduler, der die Thread-Zuweisung übernimmt und ggf. anpasst! Dem Kernel des OS wird praktisch darüber vorgegaukelt, alle Kerne wären gleich! Bei AMD gibt es sowas nicht! Dort muss das OS (Scheduler im Kernel) die Zuweisung übernehmen - aber der Scheduler im Kernel kennt keine unterschiedlichen Kerne, oder andere Spezifika! Damit er die Priorisierung optimal ausführen kann, nutzt er z.B. die Treiberebene und das Ressourcenmanagement des OS, die ihm die Auswahl erleichtern. Ein PC hat noch nie anders funktioniert - er kennt nur Maschinensprache! Deshalb brauchst Du einen Übersetzer - und genau der ist die Schnittstelle! Das hat auch nichts mit AMD zu tun, sondern gilt generell! AMD hat nur jetzt zusätzlich das Problem, dass sie eben keinen HW-Scheduler haben (das ist eigentlich fatal!!!!!). Jetzt muss es das OS selbst machen und dem Scheduler im Kernel die richtige Auswahl ermöglichen. Und genau darum geht es: Wie gut funktioniert das, wenn es selbst bei CPUs mit komplett gleichen Kernen oft nicht sauber funktioniert? Microsoft wird ständig das OS anpassen müssen, damit das beim 7950X3D und beim 7900X3D funktioniert! Deshalb die Whitelist-Lösung! Das ist alles aus der Not geboren, ohne Mist! Ich bin mir sicher, dass das auch der Grund ist, warum die CPUs verschoben werden. Der 7800X3D ist nicht das Problem, sondern eben der 7950X3D und noch mehr der 7900X3D.
Eben weil die neue CPU-Generation Hybrid-CPUs sind und das OS es ohne ständige Anpassung an die entsprechende Anwendungssoftware einfach nicht kann. Deshalb hat Intel den Thread-Director entwickelt - sicher nicht aus Spass an der Freude! Und was macht AMD? Die können nicht so einfach einen HW-Scheduler einbauen, denn das geht vielleicht bei einer monolithischen CPU. Aber bei einer CPU-Architektur mit mehreren Chiplets? Wo soll er denn sitzen? Er müsste ja dann im zentralen Steuerchip sitzen und dann über die viel langsameren Leitungen (Latenzproblem) die einzelnen Chiplets abfragen/steuern.
Deshalb hat AMD auch keine solche Lösung. Das ist halt Fluch und Segen einer solchen Architektur!
Dein Beispiel mit dem Auto ist sogar das beste Beispiel dafür. Denn die Software der Headunit steuert eben so gut wie gar keine primären Fahrfunktionen! Das machen die einzelnen Steuergeräte, die nichts mit der Software der Headunit gemeinsam haben! Das passiert direkt hardwarenah ohne API, Übersetzer, oder anderen softwaretechnischen Trennungen!
Zuletzt bearbeitet:
Ähnliche Themen
