Nach meinem Kenntnisstand ist SMT rein virtuell, das heißt es verbessert nur die Ausnutzung bestehender Transistoren und Sonstigem, und braucht keine zusätzliche hardware auf der CPU.
Falls ich mich da täusche, darfst du mich aber gern eines Besseren belehren
Für SMT braucht man mindestens einen zweiten Satz Register für den Programmkontext des zweiten Threads und was auch immer man braucht, damit ein Betriebssystem eine weitere CPU erkennt. Ist insgesamt nicht viel und die frühen Atoms hatten z.B. SMT statt Out-of-Order-Execution, weil SMT ähnliche Probleme lindert. Daraus könnte man schließen, dass SMT weniger aufwändig ist, vielleicht aber auch, dass es bei niedrigen Kernzahlen besser skaliert, ich tippe jedoch auf ersteres oder beides.
Beim Pentium 4 hatte Intel seinerzeit einige wenige Frontend-Einheiten doppelt angelegt; seitdem könnte ich mich nicht mehr an Angaben erinnern. Einige Einheiten, vor allem Scheduler und Puffer, bei Fetch und Load/Store sowie in der Sprungvorhersage, könnte man aber gegebenenfalls kleiner ausführen, wenn weniger Aufgaben im Auge behalten werden sollen. Umgekehrt könnte theroretisch alles bis auf die eigentlichen Rechen-Pipelines mehrfach verbaut sein und das Ergebnis würde immer noch unter "SMT" fallen. Aber es darf bezweifelt werden, dass beispielsweise zwei physisch getrennte Scheduler mehr Nutzen denn Chaos bringen und somit ist nicht zu erwarten, dass sowas jemals irgendwo implementiert wurde/eingespart werden kann.
Da gibt es wirklich viel Spielraum. Man könnte prinzipiell die Recheneinheiten von allen Kernen zusammenlegen und daraus einen CPU-Kern mit n-fach SMT machen. Allerdings bekommt man dann vermutlich zu große Verzögerungen bei der Auswahl des nächsten Threads oder bis ein Thread wieder dran ist. Ich vermute, dass in der Praxis nur Platz für einen zweiten Programmkontext geschaffen wird, um überschüssige Einheiten auszulasten. CPUs haben ja die meisten Einheiten mehrfach, damit man aufeinander folgende Befehle, die unabhängig von den vorhergehenden, sich noch in der Pipeline befindlichen, Befehlen sind, parallel ausgeführt werden können. Da gibt es ein typisches Limit, wie viel da in der Regel möglich ist. Um maximale sequentielle Performance zu gewährleisten ist die Anzahl der Einheiten entsprechend großzügig dimensioniert, so dass oft Einheiten frei bleiben. Wenn dann der aktuelle Thread ins Stocken kommt, können diese im Moment überschüssigen Einheiten von einem zweiten genutzt werden. Kann natürlich aber auch sein, dass für bestimmte SMT-Implementierungen einzelne Einheiten, die besonders in so einem Fall doch in einem "Single-Thread-Kern" nicht oft genug vorkommen und so den Effekt von SMT stark behindern würden, entsprechend öfter vorhanden sind.
Im Rahmen der für ein Forum praktikablen Genauigkeit ist "Null" sicherlich keine schlechte Angabe. Im Zweifelfall waren es eben "1,2 Prozent auf den nächstliegenden 10er abgerundet".
Kann man vermutlich so stehen lassen. Der einzige Sinn, sich gegen SMT zu entscheiden sind vermutlich Marketing, Defekte, wenn die CPU intern nicht parallel genug aufgebaut ist, dass sich das lohnt, wenn man sich ausrechnet, dass die Komplexität für einen Scheduler, noch mehr Threads zu verwalten, höher ist als der Nutzen oder eben irgendeine Kombination davon.
Ja gut wenn es die software nur nicht kann weil der Software die logischen Kerne ausreichen. Dann werden die recheneinheiten nicht optimal ausgelastet. Und dann müsste die CPU auch weniger Strom verbrauchen und auch weniger Abwärme produzieren.
Jein. An sich ist das so intuitiv und würde auch stimmen, gäbe es da nicht die Turbos. Die sorgen dafür, dass ein Überschuss im Energiebudget in mehr Takt umgesetzt wird. Eine CPU würde bei besserer Auslastung also niedriger Takten, aber trotzdem mehr schaffen.