Viktigt videoprogram blir 94 gånger snabbare

För en sekund tänkte jag "Goda nyheter för min rpi nas som kör en jellyfin server!" Sedan läste jag avx512.. oh well..

Ärligt talat låter det nästan mer som att det är implementeringen av avx512 som gett prestandafördelen, inte att det var handskrivet i assembler. Kompilatorerna är rätt jäkla smarta idag, så ett sådant resultat hade förvånat mig.

Ja, det är ju hela grejen. Den enda haken, som ger något som helst vikt till "handskrivet" är väl då att kompilatorn uppenbart inte själv optimerar till den grad att den använder AVX512 i dessa fall.

Låt säga att man har en Ryzen 9000. Vad är ett exempel på ett verkligt scenario där man kommer märka skillnad? (Hittade inget sådant i Tom's Hardwares artikel heller.)

Dvs artikeln är mest clickbait. Tråkigt.

Clickbait

FFmpeg används till många saker som definitivt kan dra nytta av snabbare bearbetning.

https://x.com/FFmpeg/status/1852542388851601913

Förutsätter ju att den CPU som sitter i din mediesticka har AVX512-instruktionsset:
https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512

Vet inte om man ska kalla det clickbait eller missuppfattning, men ffmpeg i helhet blir 100% garanterat inga 3 gånger snabbare av detta, för att inte nämna 94 gånger...

Ett fåtal funktioner av sannolikt tiotusentals tjänar bra på AVX-512, är vad vi kan säga från Twitter-inlägget. Detta är är alltså s.k. microbenchmarks, som testar en pytteliten del av något stort.

Från en slide ang just ffmpeg och AVX-512:

Om dav1d tjänar 10-20% i decoding på detta så kommer inte ffmpeg tjäna 3-94 gånger.

Jag uppgraderade nyligen från en 5950X till en 9950X som ju har stöd för AVX512. Skillnaden är helt galen, minst 400% snabbare. 9950X kan koda 2 videos snabbare än vad min 5950X gör 1 video - och det med ett långsammare preset (x265 slow vs x265 medium på den gamla - slow tar typiskt mer än dubbelt så lång tid som medium).

Tänk hur mycket energi man kan spara med sådan effektivisering.

Varför skriver man detta med assembler 2024?

Intel brände sig rejält på att tro att man kunde ta "vanlig" C eller C++ kod och från det generera bra SIMD-optimerad kod. Visade sig att det inte går utanför ett par rätt nischade fall p.g.a. att det helt enkelt saknas kritisk information för kompilatorn givet hur dessa språk definieras.

Är just detta problem Nvidia knäckte med CUDA och faktiskt även Intel knäckt för CPUer med deras ISPC-kompilator (som till deras fasa dess initiala grundare lade till ARM64 stöd för direkt efter han slutade på Intel, så med ISPC får man inte bara SSE, AVX, AVX2, AVX-512 stöd utan man får även NEON-stöd för ARM64).

Exakt, det som nämns är att en specifik funktion såg x94 gånger speedup. Och det från ANSI-C versionen som helt saknar SIMD-optimeringar. I det specifika fallet blev ökningen i den funktionen x1,4 över AVX2.

Det stora lyftet kommer när man går till SSSE3, efter det är det relativt små ökningar.

Precis, jag försöker skada filmerna så lite som möjligt. Har ett gediget bibliotek av fysisk media, som jag lägger på min NAS för enklare åtkomst.

Hårdvarukodning är ljusår efter vad gäller både kvalitet och filstorlek. De är rejält mycket snabbare (särskilt NVENC är galet snabb) men kvaliteten och filstorleken framförallt lämnar mycket att önska. De är nog mer tune:ade för streaming där prestanda är mer viktigt. Definitivt inget du använder för ditt filmbibliotek!

Det är till och med värre än så. Enligt Hacker News så implementerar den naiva C-versionen ett 8-tap filter medan SIMD-varianterna implementerar ett billigare 6-tap filter, och jämförelsen gjordes med optimeringar av (-O0).

Det är heller inte en optimering i FFMPEG utan i dav1d som FFMPEG och många andra program använder.