Das liegt aber - wie du schon treffend sagst - weniger an der "HT"/SMT Technologie als viel mehr an den Spieleentwicklern, die die Spiele auf maximal 4 Threads auslegen.
Deshalb kommt AMDs FX auch so schlecht dabei weg, außer in Spielen, die 8 Threads gut auslasten können. Wo wir dann wieder bei Frostbyte und Cryengine sind.
Diese beiden Engines sind nämlich was Multithreading angeht gegenüber vielen anderen Engines klar im Vorteil.
Wieso hält sich dieses Argument eigentlich immernoch?
Wer hat das eigentlich "erfunden"?
Denn rein aus der programmiersicht ist das irgendwie unsinnig... Da geht Keiner hin und baut exakt vier Threads, die dann auf wundersame Weise genau zur gleichen Zeit laufen und somit genau nur vier Thread CPUs (und keine anderen mehr) zu mehr Leistung verhelfen.
Hier mal ein Versuch um für den Nicht-Programmierer einfach darzustellen, da kommt viel eher ein Programmierer und baut Software Multithreaded auf (das ist eine Grundsatzfrage -> entweder man macht es oder eben nicht!). Software besteht heute idR aus vielen vielen verschiedenen Threads. Dabei gibt es "Steuerthreads", wenn man sie so nennen kann, die einfach andere "Workerthreads" starten und die Laufzeiten überwachen/steuern usw. Auch ein Mix aus beiden wäre denkbar.
Ein großer Teil des Workloads bei diesen Titeln/Engines, die du benennst unter dem Gesichtspunkt, kann mit 8 Threads umgehen wird hervorgerufen durch den Umstand, dass man mittlerweile anfängt, Teile der Berechnung in eigenen Threads laufen zu lassen. So lässt sich bspw. die KI Berechnung vollständig von der Physikberechnung trennen. Das sind zwei völlig verschiedene paar Schuhe und nutzt völlig andere Codezeilen... Also ab damit in eigene Threads, damit die Berechnung unabhängig im Fall der Fälle auch gleichzeitig den anderen Aufgaben laufen kann. Diese beiden Beispiele können wiederum (je nach Komplexität der Berechnung) abermals auf mehreren Workerthreads aufbauen usw.
Unterm Strich, Software ist Multithreaded und das ist gängige Praxis. Dass dabei nicht bis ins Unendliche skaliert werden kann mit der Leistung liegt am Anwendungsfall. Hier eben Games... Ein Spiel tickt nach einer eigenen Zeit. Die Spielmechanik selbst läuft unabhängig der CPU Geschwindigkeit immer gleich. Sonst würden schnellere CPUs einfach ein schnelleres Spiel bedeuten -> gabs früher mal, ist aber heute nicht mehr so! Das heist also auch gleichsam, dass die Berechnungen, sofern sie einmal durch sind erst im nächsten Durchlauf (also dem nächsten Tick) der Zeiteinheit ausgeführt werden muss. Dazwischen? Ist einfach nichts...
Wenn also die Berechnung des Spiels in einer definierten Zeit abhändelbar ist, kann der Programmierer noch so viel Threads in den Berechnungen nutzen -> da kommt einfach keine Last zustande, vor allem dann nicht, wenn die Hardware schnell genug ist. Mit einer noch breiteren CPU wird die Gesamtlast einfach weiter sinken, die Berechnung geht deswegen aber nicht schneller.
Anders kann das bei Zusatzaufgaben aussehen, wie oben angesprochen Physik/KI oder ähnliches. Das lässt sich theoretisch bis zum Erbrechen auf MT hinoptimieren. Hier kommt aber das klassische Henne/Ei Problem zum tragen. Ein Entwicklungsstudio, was ihre Software auch verkaufen will, muss natürlich dafür sorge tragen, dass sie entsprechend läuft. Geht das Spiel nun sagen wir auf gängigen Quadcore CPUs aka Intel i5 nicht, weil zu wenig MT Power, dann wird die Software nur noch von einem sehr geringen Teil des Marktes überhaupt stemmbar sein -> das fabriziert kein Entwickler freiwillig. Deswegen hält man sich mit diesem Zusatzzeug einfach (noch) zurück bis der Markt soweit ist, dass es da weiter vorran geht.
PS: auch ist im übrigen da kein SMT/HT involviert. Das ist simples Multithreading. Für die Software ist es primär völlig egal, wie die Hardware die Threads abarbeitet. Intern in der CPU ist so oder so die Reihenfolge nicht identisch der Codezeilen des Hochsprachenprogrammcodes. Stichwort dazu: Out of Order. Auch das ist nämlich gängige Praxis heute. Deswegen passt auch das Argument mit dem FX nicht. Denn der kommt nicht so schlecht weg, weil er acht Threads hat und die Anwendungen das nicht nutzen, sondern er kommt so schlecht weg, weil die pro Thread Leistung im Vergleich drastisch schlechter ausfällt in diesen Games... Und das ist völlig unabhängig ob da nun SMT/HT involviert ist oder nicht. Ein fiktiver Bulldozer Modul mit der pro Takt Performance auf Haswell/Broadwell/Skylake Niveau und vier Modulen würde in Games einfach mal nicht langsamer sein als der Intel. Eher sogar schneller, weil nicht nur das Spiel die CPU benutzt sondern auch so Sachen wie Treiber auf Multithreading aufbauen... Entsprechend mehr Sachen gleichzeitig auch mehr Leistung bedeuten würden.
Wie sooft liegt der Knackpunkt aber im Verständnis. Multithreading heist von je her nicht mehr Leistung, sondern es heist einfach mehr Aufgaben zur gleichen Zeit... Was die Leute wollen ist aber mehr Leistung von einer definierten
Aufgabe -> in dem Fall ein Spiel. Das wird so nicht aufgehen. Ging gestern nicht, ist heute nicht so und wird auch morgen nicht aufgehen. Man wird aber MT weiterhin pushen, sofern der Markt es abdecken kann um einfach mehr Aufgaben dranzubauen. Das bringt mehr Geschwindigkeit in Summe. Da die Abarbeitungsgeschwindigkeit für ALLE Aufgaben in Summe eben nicht steigt. Das ist ein winziges Detail für den Außenstehenden, dreht die Sinnhaftigkeit von Multithreading aber eigentlich komplett in ein anderes Licht!
EDIT: Mit Zen hat das aber irgendwie alles gar nix zu tun
Zen wird eher die pro Takt Performance wohl anständig steigern können und anstatt CMT auf SMT gehen. Wie viele "Cores" das Ding am Ende haben wird, abwarten... Bei mindestens vier + SMT und ansatzweise ähnliche pro Takt Performance zu Intel hat AMD zumindest faktisch keinen Nachteil mehr. Bleibt nur zu hoffen, dass da nicht irgendwo was anderes krankt. Caches, Anbindung oder weis der Teufel was... BD ist ja auch nicht primär langsam, bekommt eher die Leistung nur bedingt auf die Straße.
