Handskriven assembler snabbar upp kod

Liknande nyhet som gjorts tidigare. Troligen clickbait även denna gång? Det blev nämligen inte "94 gånger snabbare" den förra gången det rapporterades.

https://www.sweclockers.com/nyhet/39966-viktigt-videoprogram-...

EDIT: Såg att tidigare artikeln var nämnd här också. Åtminstone är det en rimligare rubrik den här gången.

Liknande information kommer hela tiden, jag har hört det tillbaks till 90talet. Och det finns lösningar där assembler blir effektivast. Oftast är det dock tidsbrist/budget som hindrar.
Liksom oavsett hur mycket pengar man har, så kanske man inte hinner uppdatera en assemblerlösning inom den tidsram man har.

Jag är dock fascinerad av all bloated lösningar. Ta Nintendo Nes, spelen startas nästan direkt. Sedan ta Apple iPad med M4 och väntetiden på att vissa spel startas påminner om 486 tiden.
Man kan undra varför? Där svaret är att spelen i det senaste fallet inte precis är kodade i assembler för maximal prestanda, utan att dessa spel laddar hur mycket skit (ramverk, bibliotek) som helst i bakgrunden.

Samma sak är det med många program. Jag har använt liknande program i 90talet på en 486a och sedan använder man senaste versionen på en modern dator och de känns lika sega i uppstart, menyer etc. Såklart dagens versioner har fler funktioner, skapar ett helt annat resultat. Men när datorer idag är extremt mycket snabbare än en 486a så förväntar man sig att det ska flyta på bättre.

Piratesoftware skulle behöva Niklas Haas

Äh, ett program skrivet till en 486 fungerar typ enbart på 486:an, kanske någon enstaka till dator typ 386. Det fanns inget grafikkort att bry sig om, något säkerhetstänk eller liknande fanns inte, den behövde stödja ett enda operativsystem, med några enstaka processorer, nätverk och usb å liknande behövde de inte bry sig om. Jämfört med spel idag som ska fungera på 99999999999 olika kombinationer av datorer på flera olika operativsystem, även 10+++år gamla sådana, och det ska fungera med alla tänkbara ljudkort och grafikkort, med femtioelva olika usbenhetskombinationer och säkerhet å antipiracy ska ju också vara med å kräva prestanda.
Så det är ju inte helt otroligt att spel idag tar lite tid att starta. Å då har jag inte nämnt hur mycket mer komplexa spel är idag..

Att c-kompilatorer suger på att skapa maskinkod jämfört med handknackad assembler är en grov generalisering. Kanske i deras speciella undantag? Men i det generella fallet så gör kompilatorn ett bättre jobb än de flesta människor, speciellt på moderna cpu:er.

Jag förstår att det är ett skämt, men känns inte som att den kompetens Niklas visar upp är så relevant för Piratens egentliga problem.

Man måste ha i åtanke att det är vektorisersde instruktioner det handlar om. I min erfarenhet är kompilatorer inte jättebra på att omvandla komplexa operationer till vektoriserade instruktioner, även om det blir helt ok för simplare saker som att multiplicera en array med en konstant t.ex. I princip varje gång jag översätter c/c++ till handskrivna vektoriserade instruktioner så blir koden snabbare, ungefär i linje med teoretisk max för antal vektorelement.

Javisst det var ett skämt. Nej jag tror inte heller att Niklas Haas assemblerkunskaper kan lösa narcissism och spagettikod.

Intel har ju inte heller AVX-512-stöd numer. De började ta bort det i mjukvara i Alder Lake (som bara hade stöd på P-cores), och nuvarande generation har inte stöd överhuvudtaget.
På klientprocessorer, då, men det är ju bara de som spelar någon större roll i den här diskussionen.

Jag håller med om att kompilatorerna gör ett fantastiskt jobb. Inspekterar man den genererade koden går det ofta att hitta en onödig move eller att man skulle kunna hyvla bort någon instruktion om man genererat en annan instruktionssekvens, men att den koden skulle exekvera snabbare på dagens superskalära out-of-order-CPUer är långt ifrån säkert.

När vi kommer till autovektorisering så gör de dock inte ett riktigt lika bra jobb. Det funkar hyfsat för "snälla" loopar med regelbundna accesser, och ett antal mönster som förekommer i vanliga bänkmärken Beger man sig bortanför de vältrampade stigarna blir koden inte sällan långt från optimal. Ibland triggar inte vektoriseringen alls och ibland har koden stor förbättringspotential.

I AVX finns instruktioner som VPSADBW, VPMADDUBSW, VPSHUFB, VPGATHERDD och VPERMT2B. De är mycket användbara vid videoavkodning men är komplexa och kan vara svåra för en kompilator att matcha mot koden. Exempelvis summerar VPSADBW de absoluta differenserna per byte i två vektorregister.

Så i vissa fall, i innersta loopen, kan handknackad assembler göra märkbar, eller i alla fall mätbar, skillnad, men det är inget som vem som helst kan göra.

Värt att notera i testerna som finns här är att den C-baseline som finns används i praktiken inte till något annat än vid debugging. Lite synd att man inte har med x86_64 baseline också, som är SSE2 (alla CPU-modeller som stödjer x86_64 stödjer minst SSE2, i praktiken kräver väl Windows idag minst SSE4 så det kanske är en vettig baseline).
https://ffmpeg.org/pipermail/ffmpeg-devel/2025-July/346726.ht...

Det är i.o.f.s imponerande att AVX-512 versionen är i genomsnitt 42 gånger snabbare än C-versionen, även 1,5 gånger snabbare än AVX2 är absolut inte att förakta givet nivåerna på prestandaökning vi normal ser nu för tiden.

Kompilatorer är idag mäkta imponerande på alla former av skalär kod. Men tyvärr kommer man inte jättelångt med autovektorisering, bl.a. p.g.a. att det ofta kan vara omöjligt för kompilator att "bevisa" att vektoriserad kod inte bryter mot det beteende som t.ex. C och C++ standard ställer på deras respektive "abstrakta maskin".

Intel forskade länge rätt hårt på att "knäcka" SIMD bara genom smarta kompilatorer. Tog Nvidias CUDA och ett Intel skunkworks vid namn ISPC (rätt mycket "CUDA för x86_64/ARM64") att inse att det finns långt bättre vägar framåt.

ISPC är väldigt likt C och C++, men man beskriver potentiell parallellism på ett väldigt snarlikt sätt som CUDA. Går garanterat att handhacka ännu bättre SIMD kod med de mer obskyra instruktionerna, men ISPC har visat sig vara kapabel att producera vektoriserad kod som presterar helt i nivå med handknackad assembler.

Den stora fördel är att en källkod då kan generera SSE, AVX, AVX-512, NEON i ett gäng varianter bara genom att köra kompilatorn med olika flaggor.

Förhoppningsvis hamnar inte ISPC på Intels chopping block som en del andra av deras projekt gjort nu (t.ex. ClearLinux som var en testing ground bl.a. för SIMD optimeringar för olika Linux bibliotek).