Viktigt videoprogram blir 94 gånger snabbare

Permalänk
Kontot avslutas
Skrivet av osgorth:

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).

Kul för dig om du fick den förbättringen, men det är någon mer variabel som spelar in här än 5950X/9950X och avx512. För det första, har du aktiverat avx512? Det är inte enablat som standard i x265, utan det måste aktiveras manuellt. 9950X borde vara runt 50% snbbare i x265.

Nu har jag inte benchat just 9000-serien, men enligt detta test så är det under 10% förbättring, vilket jag tror stämmer rätt bra, då tester jag gjort med Xeon Sapphire Rapids har gett upp till 10% och Epyc Genoa runt 5%, så upp till 10% stämmer nog rätt bra för zen5.

Skrivet av Aleshi:

Streamingföretagen kör nog inte på CPU-baserad encoding/decoding. Men det är klart, blir det tillräckligt effektivt så kan man nog uppnå samma kvalitet på mindre bandbredd med bra CPU-encoding.

Det gör majoriteten av dom. hw-accelererad (asic/nvenc osv) används framförallt av live-encoders och för tjänster med användargenererat innehåll (youtube), där volym är viktigare än kvalitet. Annars för i princip alla premium tjänster är det mjukvaru-encoder som används, där ett flertal av dom större använder både x264 och x265 i stor utsträckning.

Permalänk
Medlem
Skrivet av Aleshi:

Streamingföretagen kör nog inte på CPU-baserad encoding/decoding.

Det kan jag garantera att de gör. Kvaliteten har blivit hög på sistone, med väldigt beskedliga bitrates. Det finns absolut ingen chans att uppnå den kvaliteten med GPU-encoding oavsett skills och settings.

Visa signatur

Lian-Li LanCool 216, ASRock B650E Taichi Lite, Ryzen 9950X, Arctic Liquid Freezer III 360, 64GB Kingston CL30/6000 RAM, MSI RTX 3090 Suprim X, 5TB NVMe SSD + 16TB SATA SSD, Seasonic Focus GX 1000W, LG 32GP850 + LG 42C2 OLED

Permalänk
Medlem
Skrivet av sKRUVARN:

Kul för dig om du fick den förbättringen, men det är någon mer variabel som spelar in här än 5950X/9950X och avx512. För det första, har du aktiverat avx512? Det är inte enablat som standard i x265, utan det måste aktiveras manuellt. 9950X borde vara runt 50% snbbare i x265.

Ja, det är väldigt skojigt.

Den enda skillnaden i settings är att jag ändrat från medium preset till slow, och att jag som du säger explicit aktiverar avx512.

Värt att notera för den som är intresserad är att kvaliteten har ökat märkvärt från medium->slow preset. Slow CRF18 ser bättre ut än Medium CRF17 t.ex. och framförallt Slow CRF19 är markant bättre än Medium CRF19. 19 är vad jag brukar köra på äldre filmer som oftast är gryniga och trista.

Båda maskinerna kör Win 10, och det enda som skiljer markant i övrigt är att det är DDR4 vs DDR5 men det borde inte påverka alltför mycket.

Visa signatur

Lian-Li LanCool 216, ASRock B650E Taichi Lite, Ryzen 9950X, Arctic Liquid Freezer III 360, 64GB Kingston CL30/6000 RAM, MSI RTX 3090 Suprim X, 5TB NVMe SSD + 16TB SATA SSD, Seasonic Focus GX 1000W, LG 32GP850 + LG 42C2 OLED

Permalänk
Skrivet av Yoshman:

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).

Även om kompilatorerna gör ett bra jobb i de flesta fall, går det ofta att titta på den genererade koden och se att man själv skulle kunna göra ett bättre jobb, lokalt. Här är det en onödig move eller här skulle den instruktionen vara effektivare. Skulle jag skriva bättre assembler än vad kompilatorn genererar för ett stort program? Nope, inte en chans, men i den lilla prestandakritiska funktionen kan det vara värt att försöka. Typiskt kan det handla om att du själv vet saker om förutsättningarna (indata) och kan ta några genvägar där kompilatorn, som i alla lägen måste hålla sig till vad språkstandarden säger, måste lägga ut fler instruktioner för att ta hand om fall som du vet inte kommer inträffa.

Kommer vi just till att generera SIMD-kod från program skrivna i C eller C++ så är ju det, som du säger, problematiskt. Kompilatorn letar efter ett antal givna mönster, typiskt olika loopkonstruktioner, där den vet hur de skall översättas till vektor-form (och senare till SIMD-instruktioner). Dessa mönster är på intet sett heltäckande när det gäller alla problem som kan lösas med SIMD. Här är det ganska vanligt att kluriga gubbar (eller gummor) kan producera handskriven assemblerkod som är märkbart effektivare genom att tänka lite utanför boxen jämfört med kompilatorn. De har helt enkelt fler mönster än kompilatorn att ta till i problemlösningen. Jag har en kollega som försvinner in på sin kammare och kommer ut tre dagar senare med sekvens av AVX-instruktioner som löser saker vi inte trodde var görbart med SIMD-kod.

Så, ja, det finns tillfällen då det är motiverat att handskriva assemblerkod även 2024. Det är inte ofta, men det kan vara värt tiden det tar. Men om vi skall vara realistiska så handlar den om X% uppsnabbning inte X gånger. Att jämföra med den naiva C-koden på -O0, suck...

Permalänk
Medlem
Skrivet av sKRUVARN:

Kul för dig om du fick den förbättringen, men det är någon mer variabel som spelar in här än 5950X/9950X och avx512. För det första, har du aktiverat avx512? Det är inte enablat som standard i x265, utan det måste aktiveras manuellt. 9950X borde vara runt 50% snbbare i x265.

Nu har jag inte benchat just 9000-serien, men enligt detta test så är det under 10% förbättring, vilket jag tror stämmer rätt bra, då tester jag gjort med Xeon Sapphire Rapids har gett upp till 10% och Epyc Genoa runt 5%, så upp till 10% stämmer nog rätt bra för zen5.

Det gör majoriteten av dom. hw-accelererad (asic/nvenc osv) används framförallt av live-encoders och för tjänster med användargenererat innehåll (youtube), där volym är viktigare än kvalitet. Annars för i princip alla premium tjänster är det mjukvaru-encoder som används, där ett flertal av dom större använder både x264 och x265 i stor utsträckning.

Skrivet av osgorth:

Det kan jag garantera att de gör. Kvaliteten har blivit hög på sistone, med väldigt beskedliga bitrates. Det finns absolut ingen chans att uppnå den kvaliteten med GPU-encoding oavsett skills och settings.

Ja, jag kom på lite det medan jag skrev. Därav sista meningen. Ni har såklart rätt.
Encoding är nog på det stora hela en väldigt liten utgift jämte själva streamingen då den knappst görs så många gånger per film.

Permalänk
Medlem

Synd att man för egen del aldrig lär äga en CPU med AVX512. Är fortfarande glad så fort något är optimerat för AVX2.

Har jag drömt, eller var det inte AVX2 som Game Porting Toolkit 2 nyligen fick stöd för?

Ang. FFmpeg, så har väl prestandan där inte varit mycket att hurra för tidigare?

Permalänk
Medlem
Skrivet av walkir:

Ang. FFmpeg, så har väl prestandan där inte varit mycket att hurra för tidigare?

Va? Vad jag vet har de alltid haft väloptimerad kod.

Visa signatur

Core i7 7700K | Titan X (Pascal) | MSI 270I Gaming Pro Carbon | 32 GiB Corsair Vengeance LPX @3000MHz | Samsung 960 EVO 1TB

Permalänk
Medlem

jag förstår inte hur detta kan ske. är inte C bara ett steg ovanför assembly.
omgörs inte C direkt till assembly kod?
vad är felet i kompileringen som gör att assembly inte funkar från högre kod?
kommer LLM kunna skriva om högkod till maskin bättre i snar framtid?

Permalänk
Medlem
Skrivet av Nioreh83:

Va? Vad jag vet har de alltid haft väloptimerad kod.

Får väl tillägga "på min hårdvara"

Permalänk
Medlem

x86 är ju knappast det energieffektivaste sättet att avkoda video... Lika fel som Cinebench som mått på CPU-effektivitet.

Permalänk
Medlem
Skrivet av nördigg:

jag förstår inte hur detta kan ske. är inte C bara ett steg ovanför assembly.
omgörs inte C direkt till assembly kod?
vad är felet i kompileringen som gör att assembly inte funkar från högre kod?
kommer LLM kunna skriva om högkod till maskin bättre i snar framtid?

Maskinkod är på en helt annan detaljnivå än C. Du måste därutöver även hantera register, stacken, minne mm "för hand" så det är definitivt inte något 1:1 förhållande. Jag satt en gång i tiden och knackade maskinkod till Motorola 68000 och det var knappt görbart ens på den tiden. Program med större komplexitet blir snabbt helt oöverskådliga om de skrivas helt i assembler.

Permalänk
Medlem

Från källan i artikeln:

There is an issue, though: Intel disabled AVX-512 for its Core 12th, 13th, and 14th Generations of Core processors, leaving owners of these CPUs without them. On the other hand, AMD's Ryzen 9000-series CPUs feature a fully-enabled AVX-512 FPU so the owners of these processors can take advantage of the FFmpeg achievement.

Älskar att Intel hittar på saker som AVX-512 för x86 och sedan bara låter AMD vara de enda som stödjer det i konsumenthårdvara, bra tänkt!

Skrivet av walkir:

Synd att man för egen del aldrig lär äga en CPU med AVX512. Är fortfarande glad så fort något är optimerat för AVX2.

Har jag drömt, eller var det inte AVX2 som Game Porting Toolkit 2 nyligen fick stöd för?

Ang. FFmpeg, så har väl prestandan där inte varit mycket att hurra för tidigare?

Nu har jag inte jämfört, men har de någonsin varit långsammare än något annat så att säga? Allt handlar ju om hur man konfigurerar med FFMPEG och där finns det verkligen inga gränser- testade ut super high effort AV1 encodings som tog många timmar för ett 3min klipp för att se hur bra komprimering/kvalitet jag kunde få at best, testat ut rimliga snabba configs för att snabbt visa någon instant replay för polarna i discord, allt är en avvägning men det kan ju bli typ hur snabbt som helst om man vill liksom.

Visa signatur

Gamingrigg: MEG x570 ACE, 5950X, Ripjaws V 32GB 4000MT/S CL16, 6800XT Red Devil LE, HX1200i.
Laptop: XPS 9570 x GTX 1050 x 8300h + 16GB Vengeance 2666Mhz + Intel AX200
Valheim server: i7-8559 + Iris Plus 655 + 32GB + 256GB
Printers? Yes. Ender 5, Creality LD-002R, Velleman VM8600, Velleman K8200

Permalänk
Medlem

Men liksom 94x mot baseline ja, men mot avx2 som de flesta moderna CPU:er har är det på de specifika delfunktionerna på skärmklippet snarare samma eller max +60% i näst sista delfunktionen. Och den första delfunktionen är ju aningen långsammare på avx512 än avx2.

Då avx512 har 512 bitar mot avx2 med 256 bitar borde vissa delmoment givet "perfekt parallellism" teoretiskt kunna nå dubbla prestandan, men de flesta delmoment gör något mer än bara plus/minus/gånger på ett antal parallella registervärden. De 512 bitarna bör kunna ses som upp till 32 st FP16 värden - i princip som att 32 värden kan beräknas i en instruktion där vanliga CPU-instruktioner ("baseline") behöver "loopa 32 varv" - massa "om och men" men principen för SIMD = Single Instruktion Multiple Data är just att parallellt göra samma beräkning (som plus) på flera olika värden (som 32 pixlar samtidigt).

Skall just driftsätta en Epyc-server med 4464P (en "mindre" Epyc-serie lanserad våren '24), skall motsvara Ryzen 7900x och jämför /proc/cpuinfo med en "vanlig" 5900x:
+ 5900x nämner avx och avx2
+ 4464P nämner dessutom avx512f, avx512dq, avx512ifma, avx512cd, avx512bw, avx512vl, avx512_bf16, avx512_vbmi2, avx512_vnni, avx512_bitalg och avx512_vpopcntdq

Ser ut som en rätt detaljerad lista med avx512-instruktioner Epyc-CPU:n stödjer 😊

Ubuntu 24.04 har ffmpeg 6.1.1 men får kompilera senaste källkoden 7.1 daterad 2024-09-24 så kan det bli... ännu lite bättre men sannolikt några procent på totalen, också kul men inte 94x kul 😉

Visa signatur

Dell XPS 17 - RTX 2060 - 4k touch - ersätter MSI GS73VR efter tre år
Byggen: Simply Red med 950 Pro - Liten Lian Li

Permalänk
Medlem
Skrivet av ErikLtz:

Men liksom 94x mot baseline ja, men mot avx2 som de flesta moderna CPU:er har är det på de specifika delfunktionerna på skärmklippet snarare samma eller max +60% i näst sista delfunktionen. Och den första delfunktionen är ju aningen långsammare på avx512 än avx2.

Då avx512 har 512 bitar mot avx2 med 256 bitar borde vissa delmoment givet "perfekt parallellism" teoretiskt kunna nå dubbla prestandan, men de flesta delmoment gör något mer än bara plus/minus/gånger på ett antal parallella registervärden. De 512 bitarna bör kunna ses som upp till 32 st FP16 värden - i princip som att 32 värden kan beräknas i en instruktion där vanliga CPU-instruktioner ("baseline") behöver "loopa 32 varv" - massa "om och men" men principen för SIMD = Single Instruktion Multiple Data är just att parallellt göra samma beräkning (som plus) på flera olika värden (som 32 pixlar samtidigt).

Skall just driftsätta en Epyc-server med 4464P (en "mindre" Epyc-serie lanserad våren '24), skall motsvara Ryzen 7900x och jämför /proc/cpuinfo med en "vanlig" 5900x:
+ 5900x nämner avx och avx2
+ 4464P nämner dessutom avx512f, avx512dq, avx512ifma, avx512cd, avx512bw, avx512vl, avx512_bf16, avx512_vbmi2, avx512_vnni, avx512_bitalg och avx512_vpopcntdq

Ser ut som en rätt detaljerad lista med avx512-instruktioner Epyc-CPU:n stödjer 😊

Ubuntu 24.04 har ffmpeg 6.1.1 men får kompilera senaste källkoden 7.1 daterad 2024-09-24 så kan det bli... ännu lite bättre men sannolikt några procent på totalen, också kul men inte 94x kul 😉

Nu gör du misstaget som andra gjort och jämför AVX2 mot AVX512 och drar slutsatsen att det nog inte kan vara så mycket snabbare. Du ska jämföra med assemblerkodad AVX512. Av nyheten att döma så är det där nyckeln är. Du får inte ut något av att jämföra teori mellan AVX2 och AVX512 utan att ha det i åtanke.
Men som sagt så får vi nog vänta och se vad det kan bli i praktiken.

Permalänk
Medlem
Skrivet av nördigg:

jag förstår inte hur detta kan ske. är inte C bara ett steg ovanför assembly.
omgörs inte C direkt till assembly kod?
vad är felet i kompileringen som gör att assembly inte funkar från högre kod?
kommer LLM kunna skriva om högkod till maskin bättre i snar framtid?

Det som AVX512/SIMD gör har inget direkt stöd i högre språk som C/C++ och kompilatorerna är just nu inte smarta nog för att klura ut exakt vad det är som utvecklaren vill åstadkomma jämfört med vad de faktiskt skrivit för kod, för att kunna omvandla det till AVX512 på ett optimalt sätt. AVX är kortfattat ett sätt att göra många olika operationer för flyttal samtidigt med en instruktion.

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 3200MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 24.04|

Permalänk
Medlem
Skrivet av Mithras:

AI-genererad assembly-kod inc

Ser inte fram emot att debugga den koden... 😱

Permalänk
Skrivet av Alling:

Skulle du kunna länka till källan du hänvisar till? Tack på förhand!

AVX512 i Zen5 testad av Phoronix

Permalänk

Anandtech hann med detta innan de dog...
none-AVX vs AVX

Permalänk

Jag sitter nu med en Rocketlake och Linux. En vanlig matrismultiplkation med double gå ca 15% snabbare med -mprefer-vector-width=512.
Effetken av -march=rocketlake är dock osynlig. Zen5 är bättre än alla Intel enligt Phoronix. Synd att inte Agner Fog tittat på Zen 5 än....

Permalänk
Skrivet av Alling:

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.)

Det kanske inte gör så stor nytta för gemene man men om man är typ YouTube eller pornhub och skall koda om 1000-tals filmer dagligen till olika upplösning och generera förhandsvisningar, thumbnails o.s.v så finns det mycket att vinna.
Framförallt sparar man in på mängden hårdvara och energi.

Permalänk
99:e percentilen
Skrivet av FattarNiInte:

Det kanske inte gör så stor nytta för gemene man men om man är typ YouTube eller pornhub och skall koda om 1000-tals filmer dagligen till olika upplösning och generera förhandsvisningar, thumbnails o.s.v så finns det mycket att vinna.
Framförallt sparar man in på mängden hårdvara och energi.

Känner du till, eller ser du framför dig, något exempel på ett verkligt scenario där den ändring artikeln handlar om gör märkbar skillnad för en videotjänst som YouTube?

Visa signatur

Skrivet med hjälp av Better SweClockers

Permalänk
Skrivet av Alling:

Känner du till, eller ser du framför dig, något exempel på ett verkligt scenario där den ändring artikeln handlar om gör märkbar skillnad för en videotjänst som YouTube?

Nä, det är strikt hypotetiskt.
Säg att man har 10000 servrar a' 50 000 kr per styck. Man lyckas öka prestandan med 1%, nu klarar 9900 servrar samma jobb.
Det är 5 miljoner kr i minskade hårdvarukostnader.

Permalänk
Medlem

Snälla Sweclockers, gör om rubriken! Det är rena falsarier, lögn, och förbannad dikt att påstå att "Viktigt videoprogram blir 94 gånger snabbare"!

Permalänk
99:e percentilen
Skrivet av Mikael07:

Snälla Sweclockers, gör om rubriken! Det är rena falsarier, lögn, och förbannad dikt att påstå att "Viktigt videoprogram blir 94 gånger snabbare"!

Ja, den rubriken ligger alltså inte bara alltjämt uppe, utan har därtill lyfts till toppen av framsidan och märkts med ”Missa inte”. Om ens hälften av det som framkommit i tråden hittills stämmer finns det ju inga som helst belägg för vad SweClockers basunerar ut. Hur i hela världen motiverar du detta, @alundberg?

Visa signatur

Skrivet med hjälp av Better SweClockers

Permalänk
Medlem
Skrivet av Mikael07:

Snälla Sweclockers, gör om rubriken! Det är rena falsarier, lögn, och förbannad dikt att påstå att "Viktigt videoprogram blir 94 gånger snabbare"!

Välkommen till nya Sweclockers!

Själv är jag intresserad av den praktiska nyttan för normalanvändaren.

För en som främst kör macOS (kanske redan onormal där?) där kretsarna i sig är optimerade för H.264 och HEVC så har jag svårt att förstå vad jag vinner med optimeringarna i FFmpeg.

Jag har liksom slutat sitta i Handbrake eller SUPER för att koda om videofilmer med en optimal profil för uppspelning på en gammal AppleTV.

Då kunde valet av fel profil för en specifik codec köra ett filmklipp helt ospelbart. Än värre med Matroska-containern, där allt först packades upp och kördes i minnet på macOS.

Skrivet av Alling:

Hur i hela världen motiverar du detta, @alundberg?

Tycker att 10 foruminlägg och över 1000 publicerade nyheter säger allt.

Permalänk
Medlem
Skrivet av Alling:

Ja, den rubriken ligger alltså inte bara alltjämt uppe, utan har därtill lyfts till toppen av framsidan och märkts med ”Missa inte”. Om ens hälften av det som framkommit i tråden hittills stämmer finns det ju inga som helst belägg för vad SweClockers basunerar ut. Hur i hela världen motiverar du detta, @alundberg?

Han skriver bara generella artiklar för flertalet tidningar, tex PCWorld, Macworld, pc för alla. Med det menar jag att jag inte tror att han är en expert. Men det borde Sweclockers vara.

Permalänk
Redaktion
Skribent
Skrivet av Alling:

Ja, den rubriken ligger alltså inte bara alltjämt uppe, utan har därtill lyfts till toppen av framsidan och märkts med ”Missa inte”. Om ens hälften av det som framkommit i tråden hittills stämmer finns det ju inga som helst belägg för vad SweClockers basunerar ut. Hur i hela världen motiverar du detta, @alundberg?

Det gör jag inte. Som skribent har jag ingen kontroll över exempelvis rubriksättning, det är redaktörerna du bör fråga om sånt. Vad jag kan säga är att jag i artikeln var tydlig dels med att det gäller en uppsnabbning av delar av koden och inte allt programmet gör men även med att moderna processorer oftast har inbyggda hårdvarukodare och -avkodare som gör att det här inte behövs.

Det intressanta för mig själv var att handkodad assembler fortfarande används och kan göra så stor nytta, och att den här ändringen i ffmpeg kan göra nytta för de som till exempel har en lite äldre processor i en mediacenterdator. Jag har själv Jellyfin som kör på en NUC med 10:e gen i3 som saknar avkodare för AV1, och blir nyfiken på om det här kan göra nytta med det. Jag kom faktiskt inte ens att tänka på att bolag som Netflix som kör mjukvarubaserad omkodning för maximal kvalitet kanske kommer få större nytta av det.

Permalänk
Redaktion
Skribent
Skrivet av m4gnify:

Han skriver bara generella artiklar för flertalet tidningar, tex PCWorld, Macworld, pc för alla. Med det menar jag att jag inte tror att han är en expert. Men det borde Sweclockers vara.

Har svårt att tänka mig att SweClockers eller någon liknande webbplats har möjlighet att ta in verkliga experter inom varje ämne de skriver om, varken kostnadsmässigt eller praktiskt med så snabba ryck som krävs för nyhetsrapportering. Jag erkänner villigt att jag likt de flesta journalister är lite "jack of all trades, master of none", men jag gör mitt bästa för att läsa på om det är något jag skriver om och blir osäker på. När jag har tid läser jag gärna kommentarer med mer detaljerad insyn i ämnena

Permalänk
Datavetare
Skrivet av Ingetledigtnamn:

Även om kompilatorerna gör ett bra jobb i de flesta fall, går det ofta att titta på den genererade koden och se att man själv skulle kunna göra ett bättre jobb, lokalt. Här är det en onödig move eller här skulle den instruktionen vara effektivare. Skulle jag skriva bättre assembler än vad kompilatorn genererar för ett stort program? Nope, inte en chans, men i den lilla prestandakritiska funktionen kan det vara värt att försöka. Typiskt kan det handla om att du själv vet saker om förutsättningarna (indata) och kan ta några genvägar där kompilatorn, som i alla lägen måste hålla sig till vad språkstandarden säger, måste lägga ut fler instruktioner för att ta hand om fall som du vet inte kommer inträffa.

Kommer vi just till att generera SIMD-kod från program skrivna i C eller C++ så är ju det, som du säger, problematiskt. Kompilatorn letar efter ett antal givna mönster, typiskt olika loopkonstruktioner, där den vet hur de skall översättas till vektor-form (och senare till SIMD-instruktioner). Dessa mönster är på intet sett heltäckande när det gäller alla problem som kan lösas med SIMD. Här är det ganska vanligt att kluriga gubbar (eller gummor) kan producera handskriven assemblerkod som är märkbart effektivare genom att tänka lite utanför boxen jämfört med kompilatorn. De har helt enkelt fler mönster än kompilatorn att ta till i problemlösningen. Jag har en kollega som försvinner in på sin kammare och kommer ut tre dagar senare med sekvens av AVX-instruktioner som löser saker vi inte trodde var görbart med SIMD-kod.

Så, ja, det finns tillfällen då det är motiverat att handskriva assemblerkod även 2024. Det är inte ofta, men det kan vara värt tiden det tar. Men om vi skall vara realistiska så handlar den om X% uppsnabbning inte X gånger. Att jämföra med den naiva C-koden på -O0, suck...

Tittar man på Intels nu rätt gamla paper för ISPC skriver de bl.a. detta

"the examples we’ve seen are an image downsampling kernel (ispc performance 0.99x of intrinsics), a collision detection computation (ispc 1.05x faster), a particle system rasterizer (ispc 1.01x faster)."

och det verkar vara rätt mycket vad många upplever med ISPC, man kommer väldigt nära den prestandan man får med handknackad assembler.

Stora skillnaden är att det som annars tar t.ex. 3 dagar tar betydligt mindre. Och det man fick efter 3 dagar med assembler stödjer en enda variant av SIMD medan man väldigt enkelt inte bara når SSE, AVX, AVX-512 och NEON (och numera även Intel GPU) med ISPC, det finns även varianter inom varje där man kan prioritera att använda fler register (ha en effektivt "bredare" antal samtida lanes) eller använda färre register. Vilket som är bäst varierar beroende på vad som är primär flaskhals.

Just flaskhalsen tenderas att ändras mellan SSE/AVX till AVX-512. I det förra fallet är man oftast begränsad av beräkningskapacitet, vilket om man helt är begränsad av bara detta ger nära x2 speedup att gå från SSE till AVX.

Med AVX-512 är man långt oftare också begränsad av bandbredd, vilket bl.a. manifesterar sig i att att speedup är väsentligt under x2 när man går från AVX.

Med ISPC kan man bygga bibliotek som stödjer en rad olika konfigurationer och valet vilken som ska användas görs runtime baserat på systemet man kör på. Går att göra samma sak direkt i assblemer, tar bara mycket längre tid och kommer sällan ge någon större vinst i prestanda. Utanför assembler-wizards lär det typiskt bli långsammare med assembler.

Och det ISPC gör är att likt CUDA beskriva jobbet för en enskild SIMD-lane. Sen finns en del inbyggda funktioner för att göra horisontella operationer över SIMD-lanes. Är därför en kompilator kan göra ett så bra jobb här, den har information som helt enkelt saknas i C och C++ utan för de mest simpla fallen.

Så det är bakgrunden till: varför assembler 2024? (sen kan man göra det för att det är roligt, har skrivit spel på nivå "super cars" och flipperspel i 100 % 68k assembler på Amiga, skulle inte vilja göra något sådant på en modern PC...)

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av alundberg:

Har svårt att tänka mig att SweClockers eller någon liknande webbplats har möjlighet att ta in verkliga experter inom varje ämne de skriver om, varken kostnadsmässigt eller praktiskt med så snabba ryck som krävs för nyhetsrapportering. Jag erkänner villigt att jag likt de flesta journalister är lite "jack of all trades, master of none", men jag gör mitt bästa för att läsa på om det är något jag skriver om och blir osäker på. När jag har tid läser jag gärna kommentarer med mer detaljerad insyn i ämnena

Helt ok