Skrivet av Dyluck:
Den klassas nog som "fixed" även om det bara är ucode som har uppdaterats.
Downfall är så pass ny att jag tror inte dom hunnit fixa i själva chipet.
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.
Skrivet av Niolator:
Är inte AVX-512 framtagen enbart för att ge fördelar i syntetiska test och inte har så stor påverkan på normal användning?
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).
Skrivet av FriendOfPi:
AVX är användbart i vissa typer av laster, men har precis som du säger inte så stor påverkan på "normal" användning. Det är inte ofta ett "vardagligt" program behöver nyttja registerbredder som är större än 64 bitar eller skyffla/manipulera jättemängder med data.
Men jag kan nämna ett användningsområde som kanske "gemene man" har nytta av och det är ifall man gillar att spela spel på emulatorer... När man emulerar hårdvara med stora registerbredder (som tex Playstation) då kan AVX göra signifikant inverkan på prestanda.
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.