Arrow Lake påstås få Thunderbolt 5 men kan gå miste om Hyper-Threading

Hyperthreading ser till att du får bättre användning, utlization, av din superskalära processors funktionsenheter. Kör man bara med en instruktionsström kommer det vara svårt för processorn att utnyttja alla möjligheter att exekvera instruktioner parallellt, men i normalfallet kommer ingen sakna hyperthreading. Numera finns det tillräckligt många kärnor att köra på. Det kommer att gå finfint i Windows. Du kommer tappa lite i Cinebench, men vem bryr sig?

HT kom väl för man hade mer minnesbandbredd än cpu kraft, medans nu har vi så många cores att HT inte längre fyller ett syfte?

Är prestandan ej lidande så saknas det inte.
Saknas det så finns AMD.

Inte speciellt minnesbandbredd.

Om du tänker dig en superskalär processor som en arbetsledare (schedulern) som skall dela ut uppgifter till anställda (exekveringsenheter) utifrån en lista (ett program), så är det ibland svårt att hitta så många uppgifter att utföra oberoende av varandra som det finns anställda. Om arbetsledaren har två listor att leta uppgifter från, så blir det lättare att hitta uppgifter som är oberoende av varandra. Dessutom är det så att om ett program måste stanna för att vänta på något (som data från RAM) kan schedulern fortsätta att dela ut uppgifter från det andra programmet. Detta är Simultaneous Multi-Threading (SMT), eller Hyperthreading som Intel kallar det (det är deras varumärke).

Har man bara en processorkärna så finns det säkert en programtråd någonstans som väntar på att exekveras. Har man 12 så är det inte alls lika säkert att det finns. Genom att det numer ofta finns massor av kärnor som väntar på jobb, är det inte säkert att det betalar sig att implementera Hyperthreading. Däremot lär det finnas kvar på server-nivå.

En av Intels styrkor är att de simulerar väldigt mycket med verklig program. Om de tror att det inte längre lönar sig så har de säkert rätt i det.

Trådarna får dela på alla resurser som är tilldelade per kärna. Cachen är långt ifrån det enda. Det spelar dock ingen roll om det bara går en tråd på kärnan (då kan den tråden använda all cache den kärnan har - den är inte statiskt utdelad), så jag tror inte att det är det som är skälet. Möjligen är den optimeringsfråga, att det är lättare att optimera mängden resurser om man alltid har en kärna istället för om man ibland har en och ibland två. Kan också handla om säkerhet, att man inte vill läcka information mellan trådarna och att det kostar prestanda att försöka förhindra det.

Frågan är om redan Arrow Lake implementerar det som beskrivs i detta patent eller om det dyker upp senare.

Det som beskrivs där lär fungera rätt dåligt ihop med SMT, det är på många sätt en direkt invers av den tekniken.

SMT är ett sätt att i de flesta fall öka totala mängden arbete en fysisk kärna kan göra genom att ge den fler möjligheter att välja vad som ska köras i beräkningsenheterna. Detta sker på bekostnad av enkeltrådprestanda, även när SMT fungerar väl och totala arbetet över två programtrådar blir, säg 130 %, av en tråd på samma kärna har man nu sänkt prestanda per tråd till 65 %.

Det man försöker få till med "Rentable Units", RU, är att dela upp varje programtråd i olika segment. Vid varje tidpunkt körs en specifik programtråd på exakt 1 CPU-kärna (alt så körs den inte alls), men det finns en extra schemaläggare utöver den som lurar ut vilken/vilka beräkningsenheter som ska används där man väljer huruvida ett visst segment ska köras på en P- eller E-kärna.

Sett till total mängd arbete CPUn maximalt kan göra måste RU ge ett lägre resultat jämfört med SMT (Cinebench-poängen kommer bli lite lägre, men kanske inte längre relevant när just sådant görs >x10 snabbare med GPGPU?).

Vinsten, förutsatt att det faktiskt fungerar i praktiken, är att P-kärnorna kan än mer fokusera på att vara snabba på lite smalare fall som har relativt dålig utväxling på "antal transistorer som behövs för att öka prestanda" medan E-kärnorna i stort sätt kan ignorera de fallen helt och i stället bli lika eller nära nog lika snabb på de "vanliga fallen" som P-kärnorna.

Ser inte riktigt hur prestanda per kärna kommer öka i någon större utsträckning av detta, men man får fördelarna med SMT (hög prestanda totalt sett) genom att ha "tillräckligt många" E-kärnor (som idag tar ~1/4 av kretsytan av en P-kärna) samtidigt som man får en bättre genomsnittlig prestanda per programtråd då man inte får SMTs långa per-tråd prestanda.

Sen går det nog inte att komma ifrån att man vill bort från SMT p.g.a. att tekniken har konstateras "broken by design" ur ett säkerhetsperspektiv. Oavsett tillverkare så är slutsatsen att enda sättet att använda SMT i "molnet" är att alltid säkerställa att alla CPU-trådar som delar samma fysiska kärna inte får delas mellan två olika instanser. Ingen slump att minsta antalet vCPUs man hittar hos t.ex. AWS är 2 st, i det läget får man typiskt båda CPU-trådar på en fysisk CPU-kärna.

På en hemdator fungerar dock SMT, ur ett säkerhetspersketiv, helt OK. Är normalt samma användare som kör alla programmen på datorn, så nästan aldrig någon risk (undantaget är malware/virus, men även i det fallet finns i praktiken långt enklare attackvektorer -> icke-problem).

Att det går att bygga mikroarkitekturer med långt bättre prestanda per kärna än vad vare sig Intel eller AMD har utan att använda SMT vet vi redan då Arm, Apple och snart även Qualcomm alla har CPUer med 30-40 % högre prestanda per cykel. Frågetecknet är hur mycket av det ligger i ARM64 vs x86_64. Gissningsvis en hel del givet att Intel också kommer implementera deras APX relativt snart, APX är en större förändring av x86 ISA än både 32-bit och 64-bit förändringarna var (APX är typ ARM64 implementerad inom ramen för x86).

Specifikt högre spelprestanda är något som kan komma av något annat, det Intel kallar ”Adamantine”. Det är också något Intel har patent kring.

Adamantine är på flera sätt motsvarande det AMD/TSMC kallar ”3D cache” och som används i deras X3D-modeller.

Är vissa av ”läckorna” kring Arrow Lake som nämner ”Adamantine”, finns och andra läckor som påskiner att det finns test-kretsar av Adamantine med 128, 256 resp. 512 MB kapacitet.

Enda officiella som sagts kring Adamantine vad jag vet det Pat Gelsinger sade i höstas. Där nämndes att tekniken kommer används ”i framtiden” samt att det finns en del tekniskt relevanta skillnader jämfört med TSMCs teknik som AMD använder, en som nämndes är att ”Adamantine” placeras under compute-tile istället för ovanför den som i fallet med 3D-cache.

Adamantine är också vad Arm-SoC tillverkarna brukar kalla ”system-cache”, d.v.s inte bara CPU som kan använda den utan alla delar (GPU, NPU, xPU) kan alla använda detta.

Men läckorna är många gånger helt värdelösa. När patentet kring detta kom var flera läckor ”säkra” på att tekniken skulle komma med Meteor Lake. Vad jag förstår har Intel sagt att man inte kommer släppa just Meteor Lake modeller med detta, men att man kommer använda det ”senare”.