ΔΣΛ
PCGH-Community-Veteran(in)
Deren CPUs gehen so schon zu oft in flammen auf"Intel - der Flammenwerfer!"


Deren CPUs gehen so schon zu oft in flammen auf"Intel - der Flammenwerfer!"


Vielleicht sind die 7 Stunden täglich seine Arbeitszeit, sprich Vollzeitstreamer.51 Std Spielzeit diese Woche
Wie schafft man das neben der wöchentlichen Arbeitszeit und lebenserhaltenen Tätigkeiten?
Und mit der Aktion sind sie dann einen Schritt weiter ...dann wären sie jetzt auch nicht an dem Punkt wo sie heute stehen > am Abgrund !



Gar nicht unklug. Bei Dyson Sphere Program z.B. laufe ich mit +100 FPS flüssig. Wenn ich SMT aktiviere, habe ich 20-30 FPS weniger und es ruckelt öfter mal.Unklug bei einer Ryzen-CPU mit zwei CCDs, denn fehlende Threads sorgen für frühere Verschiebungen der Last auf das zweite CCD, was immer mit einer Latenz einhergeht, die nachweislich Performance kostet. Anwendungen dagegen profitieren eigentlich immer von den zusätzlichen Threads.
Was Intel da treibt, verstehe ich dagegen nicht. Arrow Lake hat gezeigt, dass es auch ohne HTT geht, vor allem die Frametimes können sich sehen lassen. Jetzt geht man einen Schritt zurück, fügt HTT wieder hinzu, opfert dafür Effizienz, doch wofür? Um in Anwendungen wieder etwas weiter vorn zu sein? Der Zug ist im Desktop doch eh schon lange abgefahren, zum professionellen Arbeiten kauft man sich Workstation-CPUs![]()
Hast du dazu Benchmarks zur Hand? Würde mich interessieren. Meine Messungen zeigen mir zwar relativ oft höhere Avg. Fps, jedoch (teils stark) niedrigere P0.2-Fps, was sich am Ende dann weniger flüssiger anfühlt. 30 Fps weniger und mehr Ruckler hört sich jedenfalls nach einem anderen Problem als der CPU an, so viel kann SMT nicht ausmachen.Wenn ich SMT aktiviere, habe ich 20-30 FPS weniger und es ruckelt öfter mal.
Es kommt immer darauf an, wie viel die Kerne untereinander kommunizieren müssen. Wenn die den allergrößten Teil der Zeit unabhängig rechnen können, macht es nicht so viel aus, wenn die auf einem anderen CCD liegen.Also SMT aus. Mag sein, dass andere Spiele damit besser laufen.
Vielleicht versucht der Scheduler, alles auf einem CCD zu laufen zu lassen, wenn da genug Threads vorhanden sind, mit der Folge, dass nur sechs statt zwölf Kerne verwendet werden?...so viel kann SMT nicht ausmachen.
Genau das ist doch der Sinn davon. Fast alle Spiele laufen auf einem einzelnen CCD besser. Muss auf das zweite ausgelagert werden, kostet das Leistung, immer.Vielleicht versucht der Scheduler, alles auf einem CCD zu laufen zu lassen, wenn da genug Threads vorhanden sind, mit der Folge, dass nur sechs statt zwölf Kerne verwendet werden?
Nein.Genau das ist doch der Sinn davon. Fast alle Spiele laufen auf einem einzelnen CCD besser. Muss auf das zweite ausgelagert werden, kostet das Leistung, immer.
Gab es nicht das Gerücht, dass Intel weg von unterschiedlichen Core-Architekturen (P- und E-Cores) auf ihren CPUs will?Was Intel da treibt, verstehe ich dagegen nicht. Arrow Lake hat gezeigt, dass es auch ohne HTT geht, vor allem die Frametimes können sich sehen lassen.![]()
Wo sind aktuelle Benchmarks dazu?Allein CoD mw19 waren das damals knapp 25% Höhere 1% lows im CPU Limit.. BF5 sogar noch mehr.
Bei einem CCD läuft die Last doch auf allen Kernen, da wird nichts geparkt.heutzutage kann man beim 7800x3d/9800x3D cppc nicht mehr ausschalten..
aber nach wie vor das scheduling besser über alle cores verteilen.. mit dem powersettingsexplorer.
https://www.reddit.com/r/Amd/s/szFsM6MijqWo sind aktuelle Benchmarks dazu?
es muss nicht unbedingt geparkt werden...Bei einem CCD läuft die Last doch auf allen Kernen, da wird nichts geparkt.
Ich frage mich bei dem was du beschreibst ob es wirklich das hin und her schaufeln der Daten ist. Gerade bei einem CCD hängt alles am gleichen L3 und von dort sind Daten sehr schnell beschafft, andernfalls wäre ja auch ein X3D sinnlos.https://www.reddit.com/r/Amd/s/szFsM6Mijq
hab den 5950x leider nicht mehr. der bench jetzt ist ca 3 jahre alt.. wie gesagt damals schon an euch weiter geleitet mit der bitte es gegen zu checken und es hatte euch nicht interessiert.
es muss nicht unbedingt geparkt werden...
damals konnte man halt sehen das zb ein Spiel was 8 Threads spawnen kann.. bevorzugt auf Core 1 und Core 2 liefen.. und nach bedarf noch auf Core 3.
damit diese höher boosten konnten.. wärend die restlichen Kerne fast kaum ausgelastet wurden... es wurde prioritisiert erst ein Kern voll ausgelastet bevor ein Thread auf einen anderen CPU kern geschoben wurde. bzw der nächste kern angebrochen wurde.
hat sich jetzt im Spiel die Zene geändert und damit die CPU Auslastung musste der Sheduler immer erst mal alles umsetzten und neu verteilen um auf Core 1 + 2 zb mehr platz für den Wachsenden Thread zu schaffen... oder bei weniger cpu auslastung alles auf wenige kerne wieder zusammen zu legen.
mit CPPC disabled wurden die threads gleichmässiger über die Kerne verteilt (auch wenn die ersten kerne noch nicht voll ausgelastet waren) und konnten dynamisch wachsen und schrumpfen je nach zene ohne ständig neu verteilt zu werden.
und das wegfallen von übermässigen und unnötigen Sheduling hat mehr gebracht als der CCD interconnect hat reduzieren können.
hast du 8 Threads a CPU 20% auslastung kannst du das ganze mit 8Kernen zu je 20% auslastung realisieren... oder mit 2 Kernen zu je 80% .. in beiden fällen kommst du auf deine 160...
nur steigt das ganze in der nächsten Zene auf 8Threads a 40% ... muss alles was vorher bei 8x20=2CPU cores lief neu verteilt werden
bei 8x20=8CPU cores kann sich die auslastung ändern ohne das der Sheduler alles neu verteilen muss