Framtida Intel-processorer får AVX-512 i alla kärnor

Linus är mindre impad

https://www.zdnet.com/article/linus-torvalds-i-hope-intels-av...

Läser man hela TomsHardware artikeln den stora nyheten inte AVX10, utan det som lite nämns i förbifarten på slutet: APX.

TH sammanfattning av APX är rätt bra

• 16 additional general-purpose registers (GPRs) R16–R31, also referred to as Extended GPRs (EGPRs) in this document

• Three-operand instruction formats with a new data destination (NDD) register for many integer instructions

• Conditional ISA improvements: New conditional load, store and compare instructions, combined with an option for the compiler to suppress the status flags writes of common instructions

• Optimized register state save/restore operations

• A new 64-bit absolute direct jump instruction

Allt utom det sista känns lite bekant, vad Intel gjort här är i praktiken att definiera en x86_64 av ARM64 ISA (och precis som väntat är det ett par saker man inte kan "rätta till" då det är omöjligt utan att släppa bakåtkompatibilitet, primärt handlar det om semantik relaterat till multi-core CPU där ARM64/RISC-V är mer effektiva jämfört med x86).

Läser man vad Intel själv skriver är ju AVX10 bara en del av APX, AVX10 är den del som länken ovan till Torvalds "AVX-512 borde dö" riktar sig mot medan resten är det Torvalds säger att Intel borde fokusera på: ökar prestanda på "vanlig heltalskod".

Intel nämner att APX är den största förändring av x86 ISA sedan införandet av x86_64, det är i praktiken en helt ny instruktionsuppsättning. Till skillnad mot ARM64 (som är helt separat från 32-bit Arm, Arm CPUer som kan köra 32-bit program har i praktiken två instruktionsavkodare, Apple droppade rätt snabbt 32-bit stödet och Arm själva droppade det i sina Cortex A CPUer från förra året) är APX återigen en utökning av x86.

Ska bli spännande att se hur snabbt APX

Och slutligen, AVX10 är egentligen inte att ta AVX-512 till E-cores. Det finns två helt ortogonala finesser med AVX-512, båda är användbara i isolation, bara en kommer till E-cores.

AVX10 splittar upp alla AVX-512 instruktioner i 3 klasser: 128-bit, 256-bit och 512-bit. TH har fel när de skriver

"This feels akin to Arm's support for variable vector widths with SVE."

därför att detta missar explicit den del som är så värdefullt med SVE: samma maskinkod fungerar oavsett om man kör med 128-bit register, 256-bit, 512-bit (eller vad det må vara, SVE stödjer upp till 2048-bit register). Mer än 128-bit är sällan användbart utanför HPC

Både AVX och AVX-512 stödjer 128-bit samt 256-bit, men till skillnad från SVE är det olika maskinkod beroende på vektor-längd.

Det AVX10 gör är ger E-cores alla instruktioner från AVX-512 i 128-bit och 256-bit. Tar man SweC artikels exempel med emulatorer är det inte 512-bit register som är användbart (det är antagligen helt meningslös här), utan vinsten kommer av att vissa specifika instruktioner i AVX-512 passar väldigt bra i vissa lägen.

Problemet med AVX10 är just att det krävs en check vad varje CPU stödjer, och man måste ha en speciell binär om man vill köra med 512-bit register, det programmet fungerar inte på en CPU som stödjer AVX10 men max 256-bit.

I praktiken är det nog ett icke-problem, extremt få desktop-applikationer (med undantag kanske för maskininlärning, men där är det nog hyfsat lätt att ha multipla binärer och välja "rätt" vid runtime...) har någon nytta av 512-bit register, 128-bit är nog den vanligaste vettiga bredden. Däremot finns flera applikationer som har nytta av en del av de instruktioner som finns i AVX-512.

TL;DR av det hela är, ska bli väldigt spännande att se hur mycket (heltals)prestanda man kan få ut ur APX + hur lång tid det kommer ta innan applikationer kan använda APX som sitt normalfall (för APX är som sagt en helt ny instruktionsuppsättning som i sig inte fungerar på dagens x86_64 CPUer).

Prioritet

Ett av de kritiska designkriterierna för APX (och därmed AVX10) är att det ska gå att implementera med en relativt liten transistorbudget. Uppenbara sättet att göra något sådant är att behålla så mycket som möjligt så nära vad som redan finns.

Å ena sidan kan man se det som "glaset halvtomt", det finns helt klart nackdelar. x86 är redan rejält komplex att avkoda, detta gör det ännu lite värre.

En annan är att det i praktiken helt raderar ut en av fördelarna med "CISC": kompakta instruktioner. Kortast möjliga instruktion med REX2 blir 3 byte, de flesta kommer vara 4 byte eller längre. AVX10 (EVEX-prefix) instruktioner verkar vara minst 6 byte(!) långa.

Å andra sidan kan man se det som "glaset halvfullt", stora fördelen är att det går att införa gradvis då man är helt bakåtkompatibel. Vidare verkar Intel använda en ABI som gör att "gammal" kod kommer kunna anropa in i bibliotek som använder APX-finesser, det på ett sätt som inte kräver någon förändring av anropen (applikationen).

Som @Findecanor skriver är AVX10 (nästan) exakt samma sak som AVX-512 + tillägg av statusregister som egentligen säger: jag stödjer all AVX-512 instruktioner, fast bara med 128-bit och 256-bit register.

"Dubbelpumpad" SIMD

Min gissning varför man inte tog samma väg som AMD gjort i Zen4 är dessa:

1. register är i praktiken en form av cache, en cache vars utformning gör att det tar massor med transistorer. Finns en uppskattning att de 32 AVX-512 registren tar 6-7 % av kretsytan av "compute-kretsen" i Zen4. Det väldigt mycket redan i en P-core, det blir orimligt mycket i en E-core (där andelen skulle vara signifikant högre då dessa är flera gånger mindre än en P-core).

2. det är inte 100 % AVX-512 instruktioner med endast 128-bit och 256-bit resultat, AVX10 skiljer sig i vissa lägen för att få in stödet för ökning från 16 till 32 heltalsregister.

3. om det inte finns 512-bit register behöver man inte heller spara/återställa dessa vid kontext-switch. 32 st 512-bit register tar 2k, det är ~94 % av alla register som måste sparas vid en kontext-switch (minskar till 89 % när man ökar från 16 till 32 heltalsregister). Med 256-bit register utgör de "bara" 80 % (även de 8 mask-register i AVX-512 kan då minskas till halva storleken).

4. finns egentligen ingen vinst med bredare register än vad man har data-path till, utöver kompatibilitet. I teorin finns en vinst då det blir färre instruktioner, men det SIMD typiskt är bra på tenderar ha data-throughput som flaskhals och inte instruktions-throughput (ofta logiskt rätt enkel kod).

Om dessa gissningar är någorlunda rätt blir nästa gissning att 1. och 2. har ganska mycket högre prio jämfört med de två sista.

SVE-like

Något likt SVE skulle i praktiken betyda en helt ny instruktionsuppsättning, samtidigt som man inte kan ta bort SSE/AVX utan att paja kompatibiliteten. Arm tog en väldigt stor risk när de designade en ny ISA från scratch med ARM64, de flesta tidigare sådana försök har misslyckats rätt kapitalt... De måste helt enkelt förutsatt att det inom relativt kort tid skulle gå att droppa 32-bit ISA:an. Tog Apple ett par år (A6/A6X var sista CPU med stödet), tog Arm 10-12 år (ARM64 ISA släptes 2010, första Arm CPU med ARM64 stöd släpptes 2012), båda får anses vara i sammanhanget väldigt snabbt.

På mobil/desktop ARM64 har alla så här långt nöjt sig med 128-bit fysiska register (är bara Fujitsu A64FX som kör något större, den har 512-bit). Det är mer flexibelt med 4 st 128-bit pipelines (vilket är vad både Apple Silicon och nu även Cortex X2/X3 kör med) jämfört med 2 st 256-bit pipelines: båda ger samma peak-kapacitet, fördelen förra är att man enklare når nära peak, fördelen med den senare är att det tar färre transistorer.

Och Apple har inte ens brytt sig om att implementera SVE än, men precis som för AVX-512 även med 128-bit instruktioner finns fördelar med SVE över NEON (som är Arms motsvarighet till SSE, eller mer likt AVX med 128-bit register).