Skrivet av DasIch:
Problemet med HT är att det inte alltid är mer effektivt eller ens snabbare. Det kan i vissa fall påverka prestandan negativt och dessutom leda till högre latens. Samtidigt tar det upp 5% av kiselytan.
Mest troligt har alltså Intel valt detta för att det är den mest effektiva lösningen.
Sett enbart till prestanda har man börjat lära sig rätt väl var HT fungerar och var de inte fungerar. Just fallet där det kan paja prestanda handlar nästan uteslutanden om beräknings-tunga fall där working-set är tillräckligt litet för att få plats i CPU-cache (någon nivå) men där det inte får plats när två trådar är aktiva. I det läget ger HT både sämre prestanda och högre strömförbrukning.
Fallen där det fungerar riktigt bra är där working-set är långt större än vad som får plats i cache. Då blir man nästan helt begränsad av latens mot RAM. Flera trådar per kärna betyder betyder sämre prestanda per tråd -> färre cykler per minnestransaktion sett från en specifik CPU-tråd -> effektivt sett lägre latens mot RAM givet CPU-trådens maximala kapacitet. I detta fall kan HT ge väl över 50 % prestandaboost. Dock nära nog totalt irrelevant för en desktop-applikationer.
Huvudproblemet med HT är nog inte kretsyta, det är att värdet minskar med ökande antal kärnor (tillräckligt många kärnor så blir bandbredd mot RAM en flaskhals och då hjälper inte HT alls) och sedan har SMT vissa typer av säkerhetsproblem från hur den fungerar.
Såg ett tag ut som AMD designat runt vissa av sårbarheterna, men nu har man visat att det fundamentala problemet finns kvar och är bara angreppssättet som behövdes justeras. Vissa sårbarheter fungerar bara på AMD och vissa bara på Intel, men de angriper samma fundamentala problem med SMT: när flera trådar så tätt delar resurser kommer man få implicit information kring vad "den andra tråden" gör tillräckligt snabbt för att det ska bli ett potentiellt problem.
Förstår man begränsningar hos SMT är det ändå värdefullt i flertalet fall, primärt kring servers. T.ex. så säkerställer molnleverantörerna att en enskild kund kör allt själv på varje fysisk kärna, så de läckor som kan uppstå är då ett problem den kunden kan hantera då det bara händer mellan dennes applikationer.
Som @Dyluck nämner: tror också att borttagandet av HT hänger ihop med APX. Det kommer vara den största förändringen av x86 ISA någonsin och en bieffekten det medför är att kostanden för flera CPU-trådar kommer gå upp. Ovanpå det är hela poängen med APX att kunna få liknande instruktionsparallelism som vi redan ser hos ARM64, lyckas det blir HT långt mindre värdefullt. Givet pull-requests till LLVM pekar mycket på att första CPU-modellerna med APX-stöd kommer under 2025 (så Arrow Lake / Lunar Lake ser ut att inte få stödet).
