Linus Torvalds kritisk är till stor del en helt annan än den Francois Piednoel lyfter fram, tycker den senare är helt ute och seglar.
Torvalds huvudklagomål är egentligen att AVX512 bara finns i vissa produktserier. Grejen är att det inte alls var planen, Cannon Lake blev i praktiken aldrig lanserad men det var egentligen Skylake krympt till 10 nm med AVX512 stöd. Hade den lanseras enligt plan hade vi inte haft någon fragmentering på Intelsidan.
Piednoel må ha rätt i att bandbredden AVX512 kan ge är totalt poänglöst på en bärbar. Men finns absolut ingen krav att verkligen köra 512-bitars bredd på en klientplattform, huvudpoängen med att ha AVX512 även på bärbara är så att man kan testa AVX512 optimerade bibliotek designade för datacenter på datorn utvecklaren sitter på.
Torvalds har ju skeptisk till att ARM64 ska lyckas i datacenter just då det saknas desktop-datorer med ARM64. Han har nog bara delvis rätt i detta, där han har rätt är att utan bra stöd på skrivbordet kommer det finnas färre bibliotek som drar nytta av lite mer CPU-arkitekturspecifika finesser.
SIMD är ett typexempel på en sådan CPU-arkitektur finess, de programspråk vi använder har en design som passar illa för att kompilatorer automatiskt ska dra nytta av finessen. Har däremot svårt att se svårigheten att utveckla "normal" skalär kod på min x86_64 laptop för att sedan kompilera det för t.ex. ARM64 och köra i "molnet", det är ett "löst" problem idag då kompilatorer genererar bättre kod än vad 99 % av programmerarna skulle kunna få till med handskriven assembler.
Däremot är det ju svårt att designa optimala NEON-accelererade bibliotek om datorn jag sitter använder sig av SSE/AVX. Samma gäller AVX512, ska man utnyttja på bredare front måste det finnas även i bärbara, men helt OK om faktiskt databredd är 256 eller till och med 128-bitar!
Skrivet av Ozzed:
Det där "försvaret" låter mest som kvalificerat marknadssvammel utan substans alls.
Om du definierar "kvalificerat marknadssvammel utan substans alls" som att AVX512 faktiskt ger ett rejält tillskott i prestanda i MKL, ett bibliotek som under senaste decenniet varit det mest använda bibliotek för HPC, simuleringar och program för matrisberäkningar likt Matlab på x86 CPUer, så visst!
SIMD är en nischfiness, men det är något som rätt använt faktiskt kan vara väldigt användbart. Får allt mer känslan av att Apple är den enda som faktiskt lyckats designa en vettig teknik för "modern 3D" i sitt Metal. Förutom att det ger samma fördelar som Vulkan/DX12 trots långt mindre boiler-plate så har man där även en riktigt tight integration med SIMD (SSE/AVX på x86 och NEON på ARM). Till och med för 3D-grafik finns delar där SIMD på CPU är den mest optimala lösningen, handlar typiskt om att man inte har gigantiska datamängder och måste kombinera matrisberäkningar (typiskt 4x4 vilket är perfekt match för 128-bitar SIMD med 32-bit floats) med skalär logik.
Vissa saker, de latenskritiska och där man måste växla mellan skalära flöden och kraftigt dataparallella flöden, är långt mer effektiva att hantera helt på CPU. Däremot är det meningslöst för CPUer att ens försöka tävla med GPGPU i de fall som är primärt dataparallella, här ser vi ju att mellanklass-GPUer slår de senaste x86 server CPUerna.
Skrivet av Rebben:
Det är en redundant instruktion då GPUer redan gör detta mycket snabbare. Samtidigt är den väldigt nishad så den lilla andel som inte kan köra GPU men absolut måste kunna köra dessa instruktioner är nog mindre än 0,001% av användarna.
AVX512 finns endast för att Intel skall kunna vinna fler processorbenchmarks.
Då tror jag du helt missat vilket problem SIMD är designat att lösa.
Man kan dela in problem på flera sätt. I toppen kan man dela de latenskritiska och de bandbredds/beräkningskritiska. De förra lär under överskådlig tid stanna på CPU då de kräver maximal prestanda per kärna, de skalar typiskt uselt med CPU-kärnor.
Den senare gruppen kan sedan delas in i just bandbreddskrävande och beräkningskrävande. Första gruppen är uppenbart vettigare att köra på GPU, bandbredden där är på en helt annan nivå än för CPU.
Den andra gruppen måste åter igen delas upp i uppgiftsparallella och dataparallella. Uppgiftsparallella problem löser man bäst genom att addera fler kärnor till CPUer, den senare gruppen hanteras långt mer effektivt med SIMD/SIMT.
Och är verkligen dataparallella problem så nischade, hört talas om matriser? Väldigt mycket kan beskrivas med matriser och SIMD är långt mer effektivt sätt att parallellisera sådana beräkningar jämfört med att slänga på flera CPU-kärnor. För att ens kunna använda flera CPU-kärnor på ett effektivt sätt här behövs väldigt stora matriser, fast har man väldigt stora matriser är CPUer chanslösa mot GPUer.
SIMD är den optimala lösning för dataparallella problem där storleken på data inte är stor nog för att overhead att köra på GPU leder till en nettovinst. Ett exempel på detta är AI: att träna nätverket är extremt beräkningsintensivt, GPUer är därför totalt överlägsna CPUer. Att använda ett tränat nätverk för att göra utsagor är väldigt ofta latenskritisk, men ändå beräkningsintensivt, perfekt match för SIMD och SIMD på CPU dominerar också just inferens idag.
AVX512 har också andra fördelar än just 512-bitars bredd. SIMD är inte effektivt i uppgiftsparallella problem då det inte blir effektivt att hantera divergerande kodvägar när alla "lanes" måste köra samma instruktion (SI = Single Instruction). AVX512 löser inte problemet, men det innehåller stöd för att effektivt hantera viss divergens mellan "lanes" och det gör att man effektivt kan hantera en större antal problem. Så även om man bara har 128-bitars bredd rent fysisk finns klara fördelar med att ha tillgång till AVX512 instruktioner.
Å andra sidan: ser gärna att man helt slutar stoppa in nya saker i x86, svårt att se något snabbare sätt att få en CPU-arkitektur som med råge passerat bäst-före att bytas ut mot något där det faktiskt ser utveckling!
Blir också spännande att se hur ARM Cortex X1 står sig, där har man tagit en annan riktigt kring SIMD. I stället för att öka vektorbredden, NEON är 128-bitar och kan ses rätt mycket som en 128-bitars variant av AVX2, har man dubblat antalet NEON ALUs.
Så Intel ökar vektorbredden, men man har hållit antal ALUs rätt konstant. ARM har valt att hålla vektorbredden konstant och öka antal ALU. För desktop är jag övertygad om att ARMs väg är den rätta, lite svårare att se vilken väg som är optimal för datacenter. Vi lär få se, det lär komma en server-variant av Cortex X1.