Enorm skillnad med AVX-512 i nya Xeon-kretsar

Gillar Phoronix, både mängden tester samt att det är en av få siter som testar Linux-programvara.

En sak de kunde göra bättre är lite vettigare "base-lines" i den här typen av tester (som i sig är superintressant).

Dels väljer tenderar Phoronix specifikt välja ut de fall som har den största skillnaden, skulle vara trevligt att få en bra känsla för hur representativt resultatet är i ett större kontext.

Dels missar man ofta väldigt spännande jämförelser, de flesta resultat är rätt meningslösa i isolation, de behöver sättas i relation till konkurrerande produkter. I detta fall borde man haft med någon Zen 4 AMD Epyc modell.

Zen 4 stödjer AVX-512, men är "bara" 256-bitars internt. Högst intressant inte bara för Zen 4 utan även för kommande Intel CPUer med AVX10 som kommer ha alla fördelarna från AVX-512 (finns flera stycken) men där konsumentmodellerna kommer ha 256-bitars register.

Den stora saken att ta med sig från den här typen av test är ändå att de (åter igen) visar hur kritisk programvara är för modern HW. SSE/AVX användes länge väldigt sparsamt, den förlösande detaljen är ISPC som rätt mycket kan beskrivas som "CUDA för CPU SIMD".

Från det har Intel sedan jobbat vidare med deras OneAPI där samma källkod kan används både på CPU och GPU. ISPC används då som "backend" för CPU-delen (mixat med handskrivna delar från Intels MKL) medan SyCL används som "backend" för GPU-delen.

Ganska användbart i spel, AI, databaser etc. Används ofta för generella saker som sortering, sökning, intersektioner, minneskopiering.
I början när AVX-512 kom så användes det i syntetiska tester imo, såg bra ut i benchmarks. Men klockade ner processorn så mkt att annat som kördes samtidigt i andra program gick i halva hastigheten.

10% högre förbrukning för i snitt dubbel prestanda är en ganska bra tradeoff.

Phoronix har jättemånga sådana tester.

Intel har blivit stämda p.g.a. att Sapphire Rapids inte hade buggen i HW. Det p.g.a. att man anser att avsaknad av problemet i HW bevisar att Intel känt till problemet länge.

Historiskt har användning av SIMD (som på x86 kom första gången med Pentium MMX) i praktiken krävt handoptimering.

Historien bakom ISPC är rätt interessant. Det var egentligen ett sidoprojekt/skunk-works som Intels kompilator-team initialt fnyste åt medan de var övertygade att rätt väg framåt var via så kallad auto-vektorisering.

Redan de tidiga resultaten från ISPC var så bra att kompilator-gänget utgick från att det var något fel alt. tillrättalagda specialfall. Men med tiden börjar det gå upp för allt fler hur brutalt mycket bättre denna approach var jämfört med auto-vektorisering (som man i princip konstaterat inte kan användas mer än i ett par rätt speciella fall för de vanligaste programspråken som C++, Java, C# etc).

Extra roligt är det att när den som drog igång ISPC slutade på Intel så hade han kvar "commit" rättigheter till ISPC GitHub-repo. Som en "kul grej" testade han att implementera stöd för Arm NEON (typ Arms motsvarighet till SSE/AVX), Intel var inte helt nöjda med det men då de fattade hur det skulle se ut om de tog bort det (vem som helst hade redan då "read" rättigheter till ISPC) så valde man tillslut att lämna kvar stödet.

Men man har inte precis lagt resurser på att implementera ARM64 SVE, typ Intel AVX-512 "done-perfect"...

ISPC gör, precis som CUDA för Nvidia GPUer, att man kan skriva i stort sätt "vanliga" C/C++ program som på ett mycket effektivt sätt drar nytta av SIMD instruktioner.

Men är i första hand bara en viss typ av problem som drar stor nytta av SIMD, dessa kallas "data-parallella" problem. De flesta (men inte alla) problem som skalar nära nog perfekt med CPU-kärnor är data-parallella.

"Problemet" för tekniken på CPU är idag inte att kunna använda den, utan det är att GPUer är specialdesignade för att hantera just dataparallella problem så de flesta saker som passa väl här går betydligt snabbare att köra med GPGPU (t.ex. 3D-rendering, träning av ML-modeller, vissa typer av simulering, etc).

Den andra typen av parallella problem kallas uppgiftsparallella. Dessa fungerade i princip inte alls tidigare, men en av fördelarna med AVX (och även Arms SVE) är att man kan hantera fall OK-ish om de har begränsad varians mellan uppgifterna.

Exempel på ett uppgiftsparallellt problem som i praktiken inte alls fungerar på SIMD/GPGPU är kompilering. Raytracing är däremot ett fall som man nu kan hantera trots att det har ett visst mått av divergens (visst mått uppgiftsparallellism), Intels Embree använder idag ISPC som bas (bl.a. Blender kör med Embree på CPU).

Just PS3 emulering har egentligen mindre med SIMD att göra, den stora anledningen att AVX-512 ger sådan boost där är att AVX-512 fått flera instruktioner som är en perfekt alt. nära perfekt match med instruktioner hos Cell-processorn. Utan AVX-512 får man "emulera" dessa instruktioner.