Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsBIOS-Updates für Ryzen: Asus' Turbo Game Mode schaltet 2. CCD und SMT ab
Auch da quellt pure Ahnungslosigkeit raus.
Wenn du das Problem an sich verstehen würdest, wüsstest du, dass das Unfug ist.
Abgesehen davon liefert AMD seit einer Weile Chipsatztreiber aus, die einen Dienst mitinstallieren, der bei bekannten Anwendungen die jeweiligen Threads möglichst auf das - je nach Anwendungsfall - besser geeignete Die schieben.
Fakt ist aber: Der Scheduler muss hier unter Bildungsmangel leiden, er selbst ist da unschuldig.
Der Chipsatztreiber, der eigentlich keiner ist, ist nichts anderes als ein Addon der dem Scheduler unterstützt, weil er von sich aus das Scheduling nicht ausreichend hinbekommt.
Der Scheduler hat alle Informationen um Threads vom gleichen Prozess in einer eigenen Cache Domaine (z.b CCD) zu lassen. Das macht unter anderem der Linux Scheduler so. Effektiv müssten Multi CCD Prozessoren wie Mehrsockel Systeme behandelt werden.
Ich wollte eventuell mal wieder ins CPU AMD Lager wechseln seit langer langer Zeit, aber wenn ich lese, das SMT so viele Mikroruckler verursacht, muss ich wohl doch bei Intel bleiben? Weil mit Intel und SMT ( Intel Marketing Name HT) habe ich in keinem meiner Spiele Mikroruckler... was nun?
Ich hatte noch nie Mikroruckler, die auf SMT zurückzuführen gewesen wären. Im konkreten Fall kann es auch einfach an anderen Dingen liegen und das Abschalten von SMT kaschiert dann nur Symptome, behebt aber nicht das Problem. Oder es sind Spiele, die auf Single-Core oder Dual-Core optimiert sind. Da hakt es dann auch ganz gerne mal und die Framezahl bleibt im Keller. Das sind dann aber keine Hardware-Probleme, sondern Eigenheiten einer (alten) Spiele-Engine oder ähnliches. Wenn das ein flächendeckendes Phänomen wäre, würde darüber wohl auch mehr berichtet.
@Dasher
Und du kommst daher und spinnst daraus, dass man mit dem Weglassen gleich Platz für ganze Kerne mehr auf dem Die bekommt.
Schau dir an, wie groß (im Sinne von Fläche) die Komponenten eines Kerns sind und dann denke dir deinen Teil.
Da hast du Recht! Da hat sich ein Fehler eingeschlichen! Hier die korrigierte Version:
Wenn durch das Weglassen von SMT (bei einem Kern) 5% Platz gespart werden, bleiben bei diesem Kern 95% Platz übrig. Der nächste Kern kann dementsprechend - obwohl mathematisch zwar unabhängig - natürlich keine 5% mehr sparen. Daraus ergibt sich folgende (vereinfachte) Formel, die sowohl mathematisch als auch kaufmännisch als auch philosophisch interpretiert werden kann und teilweise durch Autoformatierung brutalst verstümmelt wurde:
(((100%Platz - 5%Platz)^Kernanzahl)*(-100%(Teig/Teig))+100%)*Krassimus!
Bei einem 20-Kerner lassen sich so also nur ~64% einsparen. Um auf die beliebte Einsparung von 69% zu kommen, müssen Siliziumhohlräume mit Antimaterie gefüllt werden. Das kann auch durch Krassismus-Fakultät nicht umgangen werden!
Kurzum:
HT/CMT/SMT/etc. hat entsprechend des Workloads sehr wohl eine Berechtigung - (angeblich) eingesparte Fläche hin oder her.
Vielleicht sollten heutige Kinder lieber Sarkasmus vor der Prozentrechnung lernen.
Krik schrieb:
@sil79
"Trust me, bro!" reicht als Beleg für deine Behauptung nicht aus.
Der Chipsatztreiber, der eigentlich keiner ist, ist nichts anderes als ein Addon der dem Scheduler unterstützt, weil er von sich aus das Scheduling nicht ausreichend hinbekommt.
Der Scheduler hat alle Informationen um Threads vom gleichen Prozess in einer eigenen Cache Domaine (z.b CCD) zu lassen. Das macht unter anderem der Linux Scheduler so. Effektiv müssten Multi CCD Prozessoren wie Mehrsockel Systeme behandelt werden.
Und SMT gibt es seit über 2 Jahrzehnten im X86-Bereich, das ist mehr als genügend Zeit damit sich auch mal die Anwendungen dort anpassen.
Ergänzung ()
Krik schrieb:
Bei den ganzen Ruckelgeschichten bei Spielen, die auf SMT und HT zurückzuführen sind, wundert es mich, dass die großen Engine-Schmieden nicht schon lange darauf ein Auge gelegt haben. HT gibt es seit 2002 und SMT seit 2017.
While multithreading CPUs have been around since the 1950s, simultaneous multithreading was first researched by IBM in 1968 as part of the ACS-360 project.<a href="https://en.wikipedia.org/wiki/Simultaneous_multithreading#cite_note-3"><span>[</span>3<span>]</span></a> The first major commercial microprocessor developed with SMT was the Alpha 21464 (EV8). This microprocessor was developed by DEC in coordination with Dean Tullsen of the University of California, San Diego, and Susan Eggers and Henry Levy of the University of Washington. The microprocessor was never released, since the Alpha line of microprocessors was discontinued shortly before HP acquired Compaq which had in turn acquired DEC. Dean Tullsen's work was also used to develop the hyper-threaded versions of the Intel Pentium 4 microprocessors, such as the "Northwood" and "Prescott".
Nach der Installation wird dann offensichtlich, was der Modus bei Asus tut: Er deaktiviert ein potentielles 2. CPU-Kern-Chiplet auf Ryzen 9 und Simultaneous Multi-Threading. EXPO wird nicht aktiviert.
Das gleiche könnte man doch auch erreichen, indem man im Taskmanager die entsprechende Anwendung nur auf die physischen CPU-Kerne eines Chiplets setzt und die am besten auch gleich für alle anderen Anwendungen sperrt. Das hätte den Vorteil, dass der Rest der CPU für anderes genutzt werden kann und diese eine Anwendung keine CPU-Zeit mehr geklaut wird.
Das natürlich mit einem Tool, dass diese CPU-Zuordnungen automatisch macht.
Z. B. stürzte der Treiber meines CanoScan N1220U bei Multicore-CPUs schon beim Vorschau-Scan ab, deshalb habe ich das Grafikprogramm mit dem ich den Scanner nutzte, beim Start von Ez-Tools automatisch auf CPU1 nageln lassen, schon gab es keine Probleme mehr.
Wäre gut, EXPO kurz zu erklären - mir zumindest sagte das bisher nichts:
Die AMD EXPO™ Technologie (Extended Profiles for Overclocking) wurde entwickelt, um benutzerfreundliche Übertaktungsfunktionen für alle Speichertypen zu bieten, damit Benutzer ihre Systemleistung durch beschleunigten Speicher optimieren können.
Wäre es nicht schlauer, AMD stellt den Spieleentwicklern eine API zur Verfügung, die Schwachstellen im Windows Scheduler umgeht oder noch besser, sie arbeiten mit MS zusammen, um das auf Systemebene zu fixen.
Einen Neustart, um 50% meines teuer bezahlten Prozessors zu deaktivieren, nur um in ein paar Games, schlechte Programmierung zu optimieren, ist ja etwas daneben. Aber verkauft das ruhig den Gamern als Feature.
Das schöne am PC ist, dass ich alles drauf machenkann. Nach der Arbeit oder in den letzten Minuten, ab in Chat, Kumpels und Kumpelinen eingeladen und los gehts mit der Gamingsession. Oder während des Gaming, noch schnell etwas produktiv sein, so wird die Kiste auf Konsolen-Niveau herabgestuft.
Nun so, Sekunde, ich muss mal neu booten und ins Bios, kann dauern, der Ram trainiert sich dann auch wieder eventuell neu an. Holt euch mal alle solange ein Kaltgetränk 😞
@xpad.c Die Formulierung ist und bleibt unsinnig, weil nie klar wird, respektive vermischt wird, worauf sich die Prozent beziehen. Gebe dir aber recht, dass ich da wohl auf den Boten geschossen habe.
ich habe die Aussage als, die maximal das machen verstanden, da du das ja mit dir verglichen hast der mehr macht, das würde dann auch Leute inkludieren, die nichts machen.
Die Nutzung von SMT bedeutet allerdings nicht nur den Verbrauch von Chipfläche, sondern auch den Mehrverbrauch von el. Energie; die Mehrleistung von SMT gibt es nicht ohne Energiemehraufwand.
Was oftmals bedeutet:
Der Turbotakt kann bei akt. SMT nicht mehr so hoch sein wie bei deaktiviertem SMT. Und wenn max. Turbotakt wichtiger ist im Vergleich dazu mehr Threads nutzen zu können sollte SMT deaktiviert werden.
Von daher hängt pro oder contra SMT ganz von der Art der Software ab welche man auf dem Rechner nutzt.
Der Chipsatztreiber, der eigentlich keiner ist, ist nichts anderes als ein Addon der dem Scheduler unterstützt, weil er von sich aus das Scheduling nicht ausreichend hinbekommt.
Der Scheduler hat alle Informationen um Threads vom gleichen Prozess in einer eigenen Cache Domaine (z.b CCD) zu lassen. Das macht unter anderem der Linux Scheduler so. Effektiv müssten Multi CCD Prozessoren wie Mehrsockel Systeme behandelt werden.
Nur dass du jetzt ausgelassen hast, dass der Scheduler nicht wissen kann ob eine Anwendung auf dem Die mit mehr Cache oder höherer Frequenz laufen soll.
Und genau das kann der Scheduler nicht, weil er dafür Listen braucht, die das Treiberpaket mitbringt, um dann dem Scheduler zu sagen, wo er welche Anwendungen hin schieben soll.
Natürlich enthält das Paket auch Treiber, aber eben nicht nur.
Der Blödsinn kommt hier primär von dir.
Bei Multisockel Systemen geht es um NUMA und schon lange vor allem darum die Daten im jeweils lokal angebundenen RAM zu halten.
...ja, das kann man dann noch weiter unterteilen (non-flat) und auch auf Chip-Ebene runterbrechen, was aber nicht das Primärziel ist und Probleme mit sich bringt. Du kennst dich damit aus und kennst sie?
Ergänzung ()
WinnieW2 schrieb:
Die Nutzung von SMT bedeutet allerdings nicht nur den Verbrauch von Chipfläche, sondern auch den Mehrverbrauch von el. Energie; [...]
Der Turbotakt kann bei akt. SMT nicht mehr so hoch sein wie bei deaktiviertem SMT. Und wenn max. Turbotakt wichtiger ist im Vergleich dazu mehr Threads nutzen zu können sollte SMT deaktiviert werden.
Das ist grundsätzlich falsch.
Wenn die Threads/Kerne nicht benötigt werden, greifen Energiesparmechanismen.
SMT wird außerdem eingesetzt, weil das Verhältnis von Leistungsgewinn zu Energie- und Flächenbedarf gut ist. SMT ist kein Energiefresser.
Von daher hängt pro oder contra SMT ganz von der Art der Software ab welche man auf dem Rechner nutzt.
Natürlich nur wenn die Kernzahl die Leistung nicht abdecken kann, insofern ist der Teil richtig. Aber nur dahingehend, ob SMT einen Vorteil bringen kann oder nicht. Nachteile sind rein Scheduler bedingt und sollten heutzutage nicht mehr auftreten. Der Unterschied zwischen Logischen und Physischen Kernen ist ihnen bekannt.
Ergänzung ()
floTTes schrieb:
5% pro Kern? Damit kommst'e doch bei 8 Kernen auf 40%, bei 16 Kernen sogar auf 80% eingesparte Fläche. Mit Epyc baust'e dann schwarze Löcher.
Junge... es gibt echt viel Artikel und Literatur zu CPU-Aufbauten und du könntest dich einfach mal selber bilden und einarbeiten. Der Kram ist "überall" kostenfrei zugänglich. Und sonst empfiehlt sich die c't - die bringen zu jeder neuen Architektur Artikel und viele Detail-Infos
Junge... es gibt echt viel Artikel und Literatur zu CPU-Aufbauten und du könntest dich einfach mal selber bilden und einarbeiten. Der Kram ist "überall" kostenfrei zugänglich. Und sonst empfiehlt sich die c't - die bringen zu jeder neuen Architektur Artikel und viele Detail-Infos
Also wenn man etwas wissen will muss man immer alles selbst erarbeiten. Sehr gut. Ich hoffe du stellst selbst in Zukunft nie wieder irgendeine Frage zu irgendetwas und erarbeitest dir gefälligst alles selbst. Warum baust du nicht gleich auch noch alles selbst an? Wieso kaufst du Fertigprodukte? Mach doch gefälligst mal alles selbst Jungchen.
Was für ein vollkommen sinnfreier Kommentar der gegen alles steht was die Menschheit bisher vorangebracht hat. Man kann und muss nicht immer alles selbst erlernen. Im Gegenteil. Man muss auf das Wissen anderer aufbauen.
Bilde du dich mal weiter wie man als Gemeinschaft zusammen arbeitet und Fortschritte schafft. Dazu gehört dass man jedem ein Spezialgebiet gibt. Und da komme ich. Jemand der eine Frage stellt die von jemand aus dem Spezialgebiet beantwortet werden könnte.
Ich könnte dir noch erklären wieso der Außenblick ohne selbst in dem Spezialgebiet tätig zu sein sehr wichtig für den Fortschritt ist. Aber das lasse ich dich mal selbst erarbeiten.
Ich würde die Rückkehr des klassischen Turbo-Knopfes wirklich begrüssen - selbst im Auto bietet das Automatikgetriebe einen "Sport-Modus".
Die Aufgabe ist hier wie da durchaus ähnlich - ein sparsamer, ruhiger und komfortabler Alltagsbetrieb, Office, Surfen, Video ... - und ab und an mal richtig krachen lassen, wo Lärm und Verbrauch keine Rolle spielen, Agilität und schnelle Reaktion im Vordergrund stehen.
Selbstverständlich sollte der "Turbo-Modus" konfigurierbar sein - nicht nur SMT- und ggf. CCD-Abschaltung - sondern auch TDP, RAM-Timings, Lüfterkurven, Verwendung der dGPU ...
Wie jetzt, in einem Beitrag ist das doof, weil es Intel macht und nun kommt es als Feature, weil ASUS/AMD das für eine gute Idee halten? Hab' ich was verpasst?
Dann bleibt von einem 9950X3D im "Game Mode" nix, als ein 9800X3D? Sehr überzeugend (jaja, ich weiß .. nach einem Neustart+Besuch des BIOS wirds wieder der Alte, SEHR praxistauglich!).
Wieso kein TURBO-Knopf am Gehäuse, wie früher? Der sollte "LAZER" heißen und direkt die RGB-Beleuchtung anschalten. 😏
Wobei es hier auf ein Zusammenspiel mit dem Betriebsystem ankommt. Grundsätzlich initialisiert Windows zuerst den 1. Thread auf allen physischen Kernen, und wenn alle Kerne aktiv sind wird bei akt. SMT der zweite Thread auf den Kernen genutzt.
Teillast-Szenarien (oder Leerlauf) betrifft die Sache nicht sondern falls nicht mehr Threads simultan genutzt werden als physische Kerne vorhanden sind, diese aber stark ausgelastet werden, damit meine ich häufige Spitzenlasten oder gar Dauerlast auf den Kernen.
Nagilum99 schrieb:
SMT wird außerdem eingesetzt, weil das Verhältnis von Leistungsgewinn zu Energie- und Flächenbedarf gut ist. SMT ist kein Energiefresser.
Richtig, aber SMT benötigt dennoch el. Leistung. Dass SMT ein Energiefresser ist habe ich nicht behauptet.
Die Frage ist vielmehr ob es einen Unterschied für den Fall gibt ob Kerne mit aktiviertem oder deaktiviertem SMT nur mit einem Thread ausgelastet werden, und mit ausgelastet meine ich > 80% Rechenlast.
Sorgt aktiviertes SMT dafür dass CPU-Kerne nicht den max. Turbotakt erreichen oder nicht?
Das ist hier offenbar der Beweggrund des Herstellers den sog. Game Turbo Mode zu implementieren. Weshalb sollte Asus das sonst machen wenn es keinen Unterschied gibt?
