News Zurück in die Zukunft: Intel setzt wieder auf Hyper-Threading

dann wären sie jetzt auch nicht an dem Punkt wo sie heute stehen > am Abgrund !
Und mit der Aktion sind sie dann einen Schritt weiter ... :-D

"Ob auch Desktop-CPUs zukünftig wieder mit Hyper-Threading aufwarten können, ist noch offen"

Zuerst dachte ich mir Respekt, INTEL wird doch nicht einen "Fehler" eingestehen und diesen korrigieren.
Mittlerweile drängt sich mir allerdings der Verdacht auf, dass es INTEL einzig allein um die Marge geht
und deren Darstellung/Argumentation lediglich (wie immer) reines Marketing "Gewäsch" ist ... :ka:
 
Hmm. Sowohl die Reaktion von Intel, als auch die Reaktionen hier im Forum machen wenig Sinn für mich.

Intels kann ich noch eher nachvollziehen, im Serverbereich ist SMT halt doch wichtiger, da man dort hohen Durchsatz mit massiver Parallelität und niedrig getakten Kernen erreicht. Und gerade bei Webservern und Datenbanken warten die CPU Kerne oft auf die Peripherie, sei es RAM, Netzwerk oder Festplatte, weshalb SMT hier stark hilft um die CPUs auszulasten.

Aber Intel muss auch klar sein, dass sie nicht deswegen den Servermarkt verlieren, sondern weil AMD seit mehr als 5 Jahren die Leistung eines Intel Zweisockelsystems auf einer CPU anbietet - auch als Intel noch SMT verbaut hat.

Hier im Forum wird SMT aus irgendwelchen Gründen in den Himmel gelobt, wohl weil die neuen Intels nicht besonders gut gegen AMD abschneiden. Aber genau wie im Servermarkt denke ich, dass die Probleme von Intel woanders liegen.

Wer das anzweifelt möge sich Apples M-Prozessoren anschauen. Die können sowohl im Single als auch im Multithread durchaus mit AMDs X3Ds mithalten, und schaffen das mit einem weit geringeren Powerbudget (aber dafür deutlich mehr Chipfläche).
 
Ich verstehe es nicht ganz, da gerade bei der Multicore-Performance der 265k und 285k ja sehr gut abschneiden, auch ohne SMT. Bei anderen Sachen wo man hinter dem x3d liegt, also bei Spielen, bringt SMT ja eher Nach als Vorteile. Außer du hast nur 8 Kerne und ein Spiel profitiert von mehr Kernen. Aber bei Intel ist man da ja bei 20 Kernen für 300€. Ist ja etwas anderes als beim 9800x3d mit nur 8 Kernen.

Und dann kommen noch diverse Schwierigkeiten dazu... Man hat ja bis zu 3 verschiedene Kerne in einer CPU und dazu dann noch Multithreading. Das muss ja auch erst mal alles korrekt adressiert werden.
 
Vor ein paar Jahren wurde noch gefeiert, dass Intel SMT rauswirft... man hat ja genug Kerne und es wäre nicht so performant.
Jetzt führt Intel SMT als Neuerung ein und man feiert Intel, weil es mehr Performance bringt.

Muss man nicht verstehen
 
Da man den dafür Verantwortlichen schon gefeuert hat, war es wohl notwendig, diese "Neuigkeit" in möglichst blumigen PR-Sprech zu verpacken. Bin echt gespannt, wann intel von nVIDIA geschluckt wird.
 
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 :ka:
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.
Bei Cities 1 und 2 verhält es sich ähnlich. Also SMT aus. Mag sein, dass andere Spiele damit besser laufen. Aber ich werde ganz sicher nicht jedes Mal, nur weil ich das Spiel wechsle, erst wieder ins BIOS gehen und SMT aktivieren/deaktivieren.
Da ich mit keinem Spiel bisher Performanceprobleme habe, brauch ich ergo kein SMT. Was daran jetzt unklug sein soll, erschließt sich mir nicht.
 
Wenn ich SMT aktiviere, habe ich 20-30 FPS weniger und es ruckelt öfter mal.
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.
 
Also für mich sah dieser weg-von-HT-Move eher wie die Antwort auf die steigende Anzahl an Vorfällen von zu schnell sterbenden CPUs aus. Letzten Endes schien es so, dass man bei Intel sich gegen AMD nicht mehr so recht zu helfen wusste und Push-it-to-the-Limit die Antwort war. Das führt in der Regel zu einen recht deutlichen Druck auf die Arbeiter, welche wiederum Ergebnisse liefern, die dem Chef zwar gefallen, aber an der Realität vorbei gemessen wurden und man eigentlich an den Sicherheitsgrenzen kratzt. Da braucht man sich dann nicht wundern, dass die CPU-Mortalitätrate unverhältnismäßig nach oben schießt. Tja, und da man ja keine Prozessoren auf den Markt bringen kann, welche kaum besser oder gar schlechter sind als die vorangegangene Generation, hat man HTT rausgeschmissen um dem entgegen zu wirken.
Das ist zumindest, was ich aus dieser ganzen Situation rausgelesen habe. Bleibt abzuwarten ob Intel sich wirklich gesundschrupft und sich von toxischen Mitarbeitern befreien kann und man vielleicht wieder ganz oben mitspielt.
 
@PCGH_Dave
Nein, hab ich nicht, ich spiel DSP derzeit nicht. Ich wüsste jetzt auch nicht, welches Problem meine CPU haben sollte. Es läuft ja alles, wie es soll. Solange SMT aus bleibt. Da die Power locker für alles reicht, hält sich mein Experimentierdrang da doch in Grenzen.

Das Einzige, was interessant wäre, wäre vielleicht ein Vergleich der Leistung mit SMT unter Linux statt Windows. Vielleicht ist es ja eher eine Sache unter Windows. Aber ich hab leider keinen Platz mehr frei, da mir meine Experimentierplatte abgeraucht ist. -.-
 
Also für mich sah dieser weg-von-HT-Move eher wie die Antwort auf die steigende Anzahl an Vorfällen von zu schnell sterbenden CPUs aus. Letzten Endes schien es so, dass man bei Intel sich gegen AMD nicht mehr so recht zu helfen wusste und Push-it-to-the-Limit die Antwort war. Das führt in der Regel zu einen recht deutlichen Druck auf die Arbeiter, welche wiederum Ergebnisse liefern, die dem Chef zwar gefallen, aber an der Realität vorbei gemessen wurden und man eigentlich an den Sicherheitsgrenzen kratzt. Da braucht man sich dann nicht wundern, dass die CPU-Mortalitätrate unverhältnismäßig nach oben schießt. Tja, und da man ja keine Prozessoren auf den Markt bringen kann, welche kaum besser oder gar schlechter sind als die vorangegangene Generation, hat man HTT rausgeschmissen um dem entgegen zu wirken.
Das ist zumindest, was ich aus dieser ganzen Situation rausgelesen habe. Bleibt abzuwarten ob Intel sich wirklich gesundschrupft und sich von toxischen Mitarbeitern befreien kann und man vielleicht wieder ganz oben mitspielt.
 
Also SMT aus. Mag sein, dass andere Spiele damit besser laufen.
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.
...so viel kann SMT nicht ausmachen.
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?
 
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?
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.
 
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.
Nein.
Nicht unbedingt.

Ich weiß noch das es damals bei meinem 5950X
schon einige Spiele gab die es schafften alle 16 CPU Kerne + HT anzusprechen

Das Problem war damals schon nicht der interconnect...
sondern CPPC in Zusammenhang mit dem Windows Sheduler..
was immer wieder versucht hat soviel Leistung wie möglich auf so wenige Kerne wie möglich (bevorzugt Auf CCD1) zu legen... Um bei den restlichen kernen Strom zu Sparen und die aktiven höher boosten zu lassen

Hierbei wurden die ersten Kerne meist so ausgiebig belastet das bei Spielen.. die je nach zene halt sehr dynamische CPU Auslastung haben...
Erstmal vom sheduler alles um gelagert werden musste damit der Thread "wachsen könnte"
Was ordentlich 1%lows gekostet hat

Mit CPPC disabled war das gleiche Spiel vom thread Sheduler her viel gleichmäßiger über die Cores und natürlich auch CCDs verteilt..
In sehr dynamischen zenen konnte die CPU Last wachsen ohne vom Sheduler ständig neu ausgeglichen und umgelagert zu werden...
Was einen massiven Anstieg der 1%lows zur Folge hatte .
Allein CoD mw19 waren das damals knapp 25% Höhere 1% lows im CPU Limit.. BF5 sogar noch mehr.


Ich habs euch.. und auch dir @PCGH_Dave .. damals gesagt.. euch benchmarks mit capframex geschickt und es hat euch damals nicht interessiert..
ihr seid nichtmals darauf eingegangen als ich euch darum gebeten hatte da Mal offiziell gegen zu Benchen!


Selbst beim 5800x3D hab ich beim 1CCD noch höhere 1% lows festgestellt mit CPPC off.

heutzutage kann man beim 7800x3d/9800x3D cppc nicht mehr ausschalten..
aber nach wie vor das scheduling besser über alle cores verteilen.. mit dem powersettingsexplorer.
1753629100804.png

- Threadplanungs-Richtlinie für heterogene Systeme
-Planungsrichtlinie für Threads mit kurzer Laufzeit in heterogenen Systemen

beides auf "Alle Prozessoren" stellen und die Threads werden viel gleichmässiger über die CPU cores bei einem Ryzen verteilt.
allein das gleichmässiger verteilen wiegt die Verluste über den Interconnect mehr als auf.

(für Intel Hybrid und 2ccd X3D hybrid CPUs glaube ich besser auf bevorzugt leistungsfähige CPUs... kann ich so nicht sagen ich hab so n ding nicht)
 
Zuletzt bearbeitet:
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. :ka:
Gab es nicht das Gerücht, dass Intel weg von unterschiedlichen Core-Architekturen (P- und E-Cores) auf ihren CPUs will?
Ich glaube ja daran, dass Intel HT in den Desktop Lion Cove Cores entfernt hat, da man herausgefunden, dass man das Scheduling zwischen P-Core-Only, P-Core-HT und 1,2,3,4 E-Cores unmöglich sauber umsetzen kann. Einfach zu viel Variablen.

Wenn man beides zusammen nimmt, bringt HT dann wieder mehr, als es schadet. Vielleicht ist es sogar notwendig, um die nötige Single-Core-Leistung zu erreichen.

Edith: Link zum Gerücht: https://m.3dcenter.org/news/geruech...ab-2028-wieder-einheitliche-cpu-kerne-bringen
 
Allein CoD mw19 waren das damals knapp 25% Höhere 1% lows im CPU Limit.. BF5 sogar noch mehr.
Wo sind aktuelle Benchmarks dazu?
heutzutage kann man beim 7800x3d/9800x3D cppc nicht mehr ausschalten..
aber nach wie vor das scheduling besser über alle cores verteilen.. mit dem powersettingsexplorer.
Bei einem CCD läuft die Last doch auf allen Kernen, da wird nichts geparkt.
Spannend wird das bei CPUs mit zwei CCDs. Und bei einer 3D-CPU machts eigentlich nur Sinn, dass die Last beim Spielen auf CCD0 bleibt. Aber ich werde mir das einmal ansehen.
 
Wo sind aktuelle Benchmarks dazu?
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.


Bei einem CCD läuft die Last doch auf allen Kernen, da wird nichts geparkt.
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... was 1%lows gekostet hat durch den zusätzlichen verteilungsaufwand

bei 8x20=8CPU cores kann sich die auslastung ändern ohne das der Sheduler alles neu verteilen muss.. selbst wenn das auf 8x40 gestiegen ist musste der sheduler immer noch nicht neu eingreifen.
 
Zuletzt bearbeitet:
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
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.
Zumal ein verteilen auf mehr Kerne immer mit einem Overhead kommt, weshalb es normalerweise sinnvoller ist die Kerne auszulasten statt es auf diverse zu verteilen, auch wenn es möglich ist.
 
Zurück