@Shaav: das würde ich vermuten, ja.
Also sofern die unter Windows ausgelesenen Daten nicht Schwachsinn sind (also die CPU bei 100% auf allen Kernen auch wirklich an seiner maximalen Auslastung ist), dann ist es ja unmöglich, technisch/physikalisch (also real) die CPU überhaupt noch mehr auszulasten. Mehr als 100% des Chips zum Rechnen zu Nutzen für maximale Auslastung geht ja schlecht.
Der Punkt bei den virtuellen Kernen - nichts anderes ist/macht SMT ja - ist ja gerade, dass daran nichts real ist. Die sind einzig und allein dazu da, um die CPU im Alltagsszenario besser auszulasten. In der Realität wartet ein Thread ja ständig auf user input, auf network connections, auf I/O operations, u.v.m.
Auch laufen in der Realität ja immer X Prozesse mit Y Threads, sodass der Scheduler sowieso immer fleißig durchwechseln muss, sobald irgendwas auf pause ist.
Bei Spielen oder sonstigen Anwendungen ist die Auslastung ja immer stark schwankend, weil je nachdem was aktuell passiert der Aufwand variiert. Wenn ich etwa auf eine Wand starre in einem Spiel wird das viel weniger Ressourcen fressen, als wenn ich im nächsten Frame ins offene Gelände hetze und herumballer.
Um die Pausezeiten beim Wechseln von Operationen in der Pipeline zu überbrücken (das frisst recht viele Takte in der Realität) hat man durch SMT virtuelle Kerne, d.h. ein Prozess kann in deiner pipeline aktuell aktiv sein, kurz pausieren weil er auf I/O wartet und in der Zwischenzeit wird dann ein anderer Prozess, der ebenfalls nur pausiert war und auf CPU-Zeit wartet, aufgerufen und sofort ausgeführt werden und dann kann wieder zurückgesprungen werden.
Ohne SMT muss jedes Mal deine pipeline frei gemacht werden und dann dauert das komplette Switchen von Prozessen viel mehr Takte, als wenn du "virtuelle Wartelinien hast", die sofort loslegen können, sobald ein aktuell aktiver Thread pausiert.
Das ist jetzt natürlich eine stark vereinfachte Darstellung (studiere jetzt auch nicht gerade an einer TU, aber Leute von dort sind öfter mal bei uns (mache Robotikzeug; da kommt man um Leute die die Hardware managen nicht drumherum^^), aber so in etwa läuft das ab. Hat mir mal einer deutlich detaillierter erklärt.
Ist grundsätzlich aber wie gesagt auch logisch herleitbar: du kannst ja weder deine ALU, noch überhaupt selbst deine Transistoren, usw. usf. über das physikalische Lastlimit des Chips ausnutzen. Also sobald jede Einheit in jedem Takt auch was tut, ist ja Vollauslastung erreicht. Da geht technisch gesehen nicht mehr.
Der Punkt, warum man SMT hat und was es macht, ist ausschließlicher der, dass man in der Realität bei zig Programmen ständig Wartezeiten hat und die soll SMT minimieren, indem virtuell geparkte Threads, die auf CPU-Zeit warten, sofort starten können und nicht immer abgeräumt und neu aufgebaut werden müssen.
Bei FFT wird aber eben ja gerade mittels schneller Fouriertransformation die CPU mit mathematischen Berechnungen komplett ausgelastet - deshalb ja auch 100% Last (was viel mehr ist, als etwa das durchschnittliche Spiel jemals schafft). Das geht da sehr einfach, weil man natürlich einfach pro Kern bzw. pro phys./virt. Kern einen Worker starten kann der die ganze Zeit in FFTs loop'ed.
EDIT: Das einzige Szenario, dass ich mir vorstellen könnte (abgesehen davon, dass das ausgelesene 100% bei deaktiviertem SMT schlicht falsch ist), ist dass das SMT feature selbst (da hardware-feature) ein wenig Strom frisst. Afaik sind das aber eher kleine Architekturanpassungen, es würde mich also wundern, wenn da irgendwas oberhalb der Messungenauigkeit herauskommt.
Ein fleißiger TU-Student (oder Absolvent) kann das sicher noch viel detaillierter beleuchten.
