Intel försvarar AVX-512 mot de som "önskar den en smärtsam död"

Permalänk
Cyberman

Intel försvarar AVX-512 mot de som "önskar den en smärtsam död"

I svaret på kritiken mot instruktionstilläggen AVX-512 försvarar Intel tekniken och menar att den är uppskattad hos kunder.

Läs hela artikeln här

Permalänk
Medlem

Som jag tidigare förutspådde här på Swec.

Se även Ice Lake AVX-512 Downclocking.

Permalänk
Medlem

Ett nischat område helt enkelt. Real World för 0,1% kanske?

Permalänk
Medlem
Skrivet av mkk:

Ett nischat område helt enkelt. Real World för 0,1% kanske?

Det låter rent spontant som en onödigt dyr satsning om det används av så få. Måste ju vara att det är omtyckt (som Intel hävdar) och ökar i försäljning.

Permalänk
Medlem
Skrivet av elajt_1:

Det låter rent spontant som en onödigt dyr satsning om det används av så få. Måste ju vara att det är omtyckt (som Intel hävdar) och ökar i försäljning.

Eller helt enkelt något de är bättre på, och då hör det ju naturligtvis till "Real world applications" och ett måste att ha kvar

Permalänk
Medlem
Skrivet av mkk:

Ett nischat område helt enkelt. Real World för 0,1% kanske?

Skrivet av elajt_1:

Det låter rent spontant som en onödigt dyr satsning om det används av så få. Måste ju vara att det är omtyckt (som Intel hävdar) och ökar i försäljning.

Har sett detta argument användas om alla nya tekniker. Flerkärniga processorer? Nischat område. GPGPU? Nischat område. SIMD? Nischat område.

Givetvis är det få applikationer som drar nytta av dessa tekniker i början.

Permalänk
Medlem

Läste en artikeln nyligen som lite mer allmänt dryftar ledningsproblemen hos Intel, där Francois Pidnoel sågar AVX-512 tämligen skoningslöst:

Pidnoel flat-out dismissed including AVX512 in consumer chips as a mistake.

"You had Skylake and Skylake X for a reason," Piednoel said. "AVX512 is designed for a race of throughput that is lost to the GPU already. There's two ways to get throughput. One is to get the throughput is by having larger vectors to your core, and the other way is to have more cores."

Piednoel, who once told me after Intel's Pentium 4 misadventure that "we learned you can't recompile the world," seemed to imply the software game wasn't winning Intel any battle this time either.

"The state of software out there is really not favoring going larger vectors," Piednoel said in the video. "In fact, you can see clearly in Cinebench for example—that is not one of my favorite benchmarks, especially for a laptop where it doesn’t make any sense—but you can see that AMD is winning the battle of throughput. It's because they have more cores and they can afford to have more cores."

Källa: https://www.pcworld.com/article/3569182/whats-wrong-with-inte...

Permalänk
Medlem

Hela argumentet och problemet med AVX-512 var väl fragmenteringen och att inte ens lakefield hade stöd på alla kärnorna utan bara ena... det är ju sjukt konstigt att ha en instruktion som bara används ibland och helt inkonsekvent. Köper jag en processor förväntar jag mig att ett program kan köras på alla kärnorna, och köper jag efterföljande modell förväntar jag mig att inte behöva kompilera om programmet utan att det slutar fungera (kanske inte fungerar optimalt dock...)

Ingen har väl klagat på att instruktionerna existerar alls egentligen, det är väl att ingen implementation är logisk som är stora problemet.

Gillar att de säger att x86 är gemensam plattform för cloud och client, det kommer inte stämma länge till. ARM64 är här för att ta stora delar av den kakan

Permalänk
Medlem

Det där "försvaret" låter mest som kvalificerat marknadssvammel utan substans alls.

Permalänk
Medlem

Vad är detta?

Permalänk
Medlem
Skrivet av Klappa:

Vad är detta?

En graf över hur mycket klockfrekvensen droppar vid exekvering av AVX/AVX-512. På Ice Lake-X är denna drop betydligt mindre än på Skylake-X.

Permalänk
Medlem

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.

Permalänk
Datavetare

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.

Permalänk
Medlem
Skrivet av Yoshman:

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.

Du har säkert helt rätt, men det var ju inte det han sa. Du kanske skulle frilansa lite för Intel så att de lär sig tala klarspråk och kommer ur marknadsdimman?

Nej det jag tänkte på var nog mer floskler och svammel såsom:

"AVX-512 is a great feature. Our HPC community, AI community, love it. Our customers on the data center side really, really, really love it. Our CPU cores are our crown jewels. So when we do a CPU core and add an instruction to it, historically the power of x86 and our instruction set extensions have been that we made them available everywhere. Because of that, when we have an IP like Sunny Cove and it appears both in a server like an Ice Lake server and on a client, like an Ice Lake client, you get the commonality of the instruction set."

Inte ett vettigt ord där. Skulle lika gärna kunna handla om knäckebröd, toapapper eller vad som helst. Din beskrivning av nyttan med AVX-512 har substans, men just det han säger, så som det står citerat. Det är för mig bara "corporate bullshit" helt utan substans, och det var det jag kritiserade, inte AVX-512 i sig.

Permalänk
Datavetare
Skrivet av Ozzed:

Du har säkert helt rätt, men det var ju inte det han sa. Du kanske skulle frilansa lite för Intel så att de lär sig tala klarspråk och kommer ur marknadsdimman?

Nej det jag tänkte på var nog mer floskler och svammel såsom:

"AVX-512 is a great feature. Our HPC community, AI community, love it. Our customers on the data center side really, really, really love it. Our CPU cores are our crown jewels. So when we do a CPU core and add an instruction to it, historically the power of x86 and our instruction set extensions have been that we made them available everywhere. Because of that, when we have an IP like Sunny Cove and it appears both in a server like an Ice Lake server and on a client, like an Ice Lake client, you get the commonality of the instruction set."

Inte ett vettigt ord där. Skulle lika gärna kunna handla om knäckebröd, toapapper eller vad som helst. Din beskrivning av nyttan med AVX-512 har substans, men just det han säger, så som det står citerat. Det är för mig bara "corporate bullshit" helt utan substans, och det var det jag kritiserade, inte AVX-512 i sig.

"AVX-512 is a great feature. Our HPC community, AI community, love it."

Det är ju helt sant. Det är en nisch, men det är en nisch som är väldigt viktigt bl.a. för HPC och AI.

"Our customers on the data center side really, really, really love it."

Ingen aning hur väl det där stämmer. Använder själv datacenter rätt mycket, men det är områden där både SIMD och GPGPU är rätt irrelevant.

"Our CPU cores are our crown jewels. So when we do a CPU core and add an instruction to it, historically the power of x86 and our instruction set extensions have been that we made them available everywhere. Because of that, when we have an IP like Sunny Cove and it appears both in a server like an Ice Lake server and on a client, like an Ice Lake client, you get the commonality of the instruction set."

Detta är nästan helt sant, just AVX saknas ju fortfarande på Atom. AVX512 hade ju funnits på alla "Core" produkter idag om Intel inte så totalt misslyckats med deras 10 nm.

För det Atom typiskt används på serversidan, microservices, så är SIMD nästan alltid irrelevant. Men då just AI kryper i mer eller mindre allt är jag övertygad om att vi kommer få se AVX stöd i nästa Atom-generation. ARM skruvade ju upp SIMD-kapacitet rejält i Cortex X1 specifikt för att AI börjar bli så vanligt.

Möjligen är hela SIMD-tekniken ett sidospår. Ett potentiellt alternativ vore ju att förlägga det man idag kör på SIMD till iGPU. Går inte att lägga det på dGPU, är för stor latens. Men rätt designad delar ju iGPU och CPU i alla fall LLC, så är fallet sedan Sandy Bridge för Intel och de flesta ARM-systemkretsar fungerar också på det sättet. Var väl lite det som Linus Torvalds var inne på, grundläggande flyttalsstöd direkt i CPU och lägg AVX-lika saker på iGPU. Det kräver då i.o.f.s. endera att alla CPU-modeller har iGPU eller så är man tillbaka till fragmenteringen...

Permalänk
Medlem
Skrivet av Yoshman:

"AVX-512 is a great feature. Our HPC community, AI community, love it."

Det är ju helt sant. Det är en nisch, men det är en nisch som är väldigt viktigt bl.a. för HPC och AI.

"Our customers on the data center side really, really, really love it."

Ingen aning hur väl det där stämmer. Använder själv datacenter rätt mycket, men det är områden där både SIMD och GPGPU är rätt irrelevant.

"Our CPU cores are our crown jewels. So when we do a CPU core and add an instruction to it, historically the power of x86 and our instruction set extensions have been that we made them available everywhere. Because of that, when we have an IP like Sunny Cove and it appears both in a server like an Ice Lake server and on a client, like an Ice Lake client, you get the commonality of the instruction set."

Detta är nästan helt sant, just AVX saknas ju fortfarande på Atom. AVX512 hade ju funnits på alla "Core" produkter idag om Intel inte så totalt misslyckats med deras 10 nm.

För det Atom typiskt används på serversidan, microservices, så är SIMD nästan alltid irrelevant. Men då just AI kryper i mer eller mindre allt är jag övertygad om att vi kommer få se AVX stöd i nästa Atom-generation. ARM skruvade ju upp SIMD-kapacitet rejält i Cortex X1 specifikt för att AI börjar bli så vanligt.

Möjligen är hela SIMD-tekniken ett sidospår. Ett potentiellt alternativ vore ju att förlägga det man idag kör på SIMD till iGPU. Går inte att lägga det på dGPU, är för stor latens. Men rätt designad delar ju iGPU och CPU i alla fall LLC, så är fallet sedan Sandy Bridge för Intel och de flesta ARM-systemkretsar fungerar också på det sättet. Var väl lite det som Linus Torvalds var inne på, grundläggande flyttalsstöd direkt i CPU och lägg AVX-lika saker på iGPU. Det kräver då i.o.f.s. endera att alla CPU-modeller har iGPU eller så är man tillbaka till fragmenteringen...

Det som jag tycker fattas är främst konkreta exempel. Att iklä sig talarrollen för ett helt community utan att gå in på specifika fall är meningslöst om man ska förklara hur något är felaktigt, eller ja, i det här fallet varför det vore dumt att önska det en smärtsam död. De som faktiskt använder det förstår väl nyttan så då är det bara drygt att formulera sig som en säljare som skall dumma ner saker, även om det han säger stämmer..

Linus har ju i sin kritik gått in ganska specifikt och förklarat vad han ogillar, och skall man bemöta det så tycker jag att man även i bemötandet skall vara specifik, så däri ligger främst min kritik av försvaret. Om Linus nu har missat att det finns en nytta med att få in viss parallellisering med låg latens för att "stark parallellisering görs bäst med GPU", eller vad det nu kan vara så missar man ju från Intels sida en chans att knäppa honom på näsan.

Däremot så är känns det andra citatet mer välavvägt, och därför tog jag inte upp det. Det är klart att det tar tid för ny teknik att mogna, men det i sig är ju ingen anledning att skippa första generationen.

Permalänk
Medlem
Skrivet av Yoshman:

kompilatorer genererar bättre kod än vad 99 % av programmerarna skulle kunna få till med handskriven assembler.

Detta stämmer när det gäller kod som inte kan vektoriseras, men om vi pratar SIMD så är situationen helt annorlunda då kompilatorer är riktigt usla på autovektorisering annat än i extremt triviala fall.

Det är i min erfarenhet inga större svårigheter för t.o.m. en nybörjare att få 2-10x prestandaförbättring om man skriver kod med asm och/eller instrinsics jämfört med vad kompilatorn genererar, både på x86 och ARM, när det gäller kod som lämpar sig väl för vektorisering.

Permalänk
Datavetare
Skrivet av Gramner:

Detta stämmer när det gäller kod som inte kan vektoriseras, men om vi pratar SIMD så är situationen helt annorlunda då kompilatorer är riktigt usla på autovektorisering annat än i extremt triviala fall.

Det är i min erfarenhet inga större svårigheter för t.o.m. en nybörjare att få 2-10x prestandaförbättring om man skriver kod med asm och/eller instrinsics jämfört med vad kompilatorn genererar, både på x86 och ARM, när det gäller kod som lämpar sig väl för vektorisering.

Nitpick: är inte kompilatorer som är usla på att vektorisera, även där är kompilatorer långt bättre än väldigt nära 100 % av alla programmerare. Däremot är det rätt hopplöst att autovektorisera kod skrivet i våra idag mest populära programspråk då de helt enkelt beskriver problemet på ett väldigt skalärt sekventiellt sätt. Är främst flyttalskod som är helt hopplös att autovektorisera (problemet är att flyttaloperationer inte är kommutativa), ser något bättre ut för heltal (då de är kommutativa).

Nvidia knäckte nöten med CUDA och Intel har en LLVM-baserad kompilator som kallas ISPC som kan generera väldigt effektiv SIMD för x86 och lite oväntat ARM (oväntat då det är primärt ett Intel-projekt, men det är helt open source).

I samband med lanseringen av Xe kommer Intel också släppa OneAPI. Det är också ett ramverk där en kompilator (DPCPP: Data Parallell C++) används för att generera effektiv kod för GPU, FGPA samt SIMD på CPU. Det trevliga med OneAPI här är att den dataparallella koden kommer (i alla fall för GPU, har bara testat det än) kompileras till ett mellanformat och först på varje maskin översätts mellanformatet till faktiskt maskinkod. Fördelen med det är att man löser exakt den kritik Torvalds framförde: det blir ingen fragmentering då det som levereras fungerar överallt, men tekniken gör det möjligt att använda AVX512 på system där det finns annars kan man köra AVX eller till och med SSE (eller NEON om det är en ARM).

Det tar alltid lång tid innan ny teknik riktigt anmanas på ett effektivt sätt. Just SIMD verkar ha varit en rätt svår nöt att knäcka, var först när Nvidia (CUDA) insåg att man borde se på problemet från en helt annan vinkel som de blivit riktigt användbart. Verkar ha tagit ett stund för CPU-sidan att lura ut hur man bäst översätter CUDA till CPU-SIMD.