Forum Övrigt Nyhetskommentarer Tråd Inlägg

Viktigt videoprogram blir 94 gånger snabbare

1 2 3
Skriv svar
Permalänk
Medlem ★
●
Skrivet av Aleshi:

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.

Gå till inlägget

Mjo, "den stora problematiken" med SIMD/AVX är just att få kompilatorn att förstå att nyttja den parallella möjligheten.

Passus: har programmerat i C* för Thinking Machines Connection Machine en gång i tiden, en superdator med 16384 små CPU:er som kunde göra sina beräkningar på sina lokala värden samtidigt. Nyckeln här var parallella datatyper där man kunde ladda dessa med värden i varje processors lokala minne och sedan utföra +, * och andra operationer på hela vektorn UTAN loopar. Kompilatorn kunde dessutom "abstrahera" så vektor med 65536 värden utfördes med loop till 4 över 16384 CPU:er, tills maskinen uppgraderades till 32768 CPU:er och då räckte 2 varv. Hittade en gammal dammig PDF från 1991 (!), huh:
https://people.csail.mit.edu/bradley/cm5docs/CStarUsersGuide....

Åter till AVX: assemblerkodar man AVX512 och slår kompilatorn väsentligt, torde i stort sett samma handkodning med AVX2-instruktioner få samma effekt/2 mot kompilatorn:s AVX2-kod - skillnaden är huvudsakligen "bredden" 512 eller 256 bitar som motsvarar ett antal värden medan addition, multiplikation och sånt utförs på dessa värden "in parallell" - men dubbelt så många värden i 512-fallet då avx2=avx256 typ.

Så kan förstås 512-utökningen tillföra MER än ENBART ökad bredd, som fler register och någon ny instruktion som saknats i AVX2 för FP16 eller BFLOAT16-datatypen som verkar "duga" för AI, men vet inte detaljerna där. När jag laddar ner källkoden för ffmpeg 7.1 och kompilerar skall jag kika efter avx-assembler-koden 😊

Visa signatur

MSI Prestige 16 Ryzen 9 AI 4K OLED (tidigare Dell XPS 17, MSI GS73VR)
Byggen: White Dream (2025) - Simply Red (2015) - Liten Lian Li (2011)

Redigera
Citera flera Citera
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

Gå till inlägget

Hade vi fått stå ut med aftonbladet's nivå så hade det säkert stått "programerare skriver om kod och får blabla resultat" så din artikel som är lite mer ingående och nämner ord som assembler osv är klart uppskattad (Y). Som artikel är det också intressant vad som kan kanske inväntas p.g.a av ökningen intressant.
Så slappna av, du gjorde ett bra jobb

Visa signatur

Cogito ergo sum ego, vos non

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Undrar om det spelar någon roll för mina kodi mediaspelare

Visa signatur

CPU: 5800x3d
GPU: 3080
RAM: 32GB

Sluta gömma din identitet, skaffa en till istället

Redigera
Citera flera Citera
Permalänk
99:e percentilen ★
●
Skrivet av 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.

Gå till inlägget

Tack för snabbt svar! Då ska jag framförallt adressera frågan till redaktionschef @Enviro och nyhetsredaktör @Edin_II istället.

Förvisso lämnar artikelns brödtext möjligen visst utrymme för missförstånd:

Tom's Hardware rapporterar att utvecklare på projektet har experimenterat med delar av koden, som de har skrivit om för hand i assembler med AVX-512-instruktioner. Resultatet blev en uppsnabbning med mellan 200 och 9 300 procent.

Det stycket kan, menar jag, definitivt läsas som att omskrivning av delar av koden resulterade i "en uppsnabbning med mellan 200 och 9 300 procent" av programmet som helhet, åtminstone i något scenario.

Citat:

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.

Håller verkligen med om att det är intressant om det är så! Är däremot inte övertygad om att det verkligen stämmer att det kan göra så stor nytta (antar att du menar 3–94 gånger så snabbt) för någon, baserat på vad som framkommit i tråden.

Visa signatur

Skrivet med hjälp av Better SweClockers

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av ErikLtz:

Mjo, "den stora problematiken" med SIMD/AVX är just att få kompilatorn att förstå att nyttja den parallella möjligheten.

Passus: har programmerat i C* för Thinking Machines Connection Machine en gång i tiden, en superdator med 16384 små CPU:er som kunde göra sina beräkningar på sina lokala värden samtidigt. Nyckeln här var parallella datatyper där man kunde ladda dessa med värden i varje processors lokala minne och sedan utföra +, * och andra operationer på hela vektorn UTAN loopar. Kompilatorn kunde dessutom "abstrahera" så vektor med 65536 värden utfördes med loop till 4 över 16384 CPU:er, tills maskinen uppgraderades till 32768 CPU:er och då räckte 2 varv. Hittade en gammal dammig PDF från 1991 (!), huh:
https://people.csail.mit.edu/bradley/cm5docs/CStarUsersGuide....

Åter till AVX: assemblerkodar man AVX512 och slår kompilatorn väsentligt, torde i stort sett samma handkodning med AVX2-instruktioner få samma effekt/2 mot kompilatorn:s AVX2-kod - skillnaden är huvudsakligen "bredden" 512 eller 256 bitar som motsvarar ett antal värden medan addition, multiplikation och sånt utförs på dessa värden "in parallell" - men dubbelt så många värden i 512-fallet då avx2=avx256 typ.

Så kan förstås 512-utökningen tillföra MER än ENBART ökad bredd, som fler register och någon ny instruktion som saknats i AVX2 för FP16 eller BFLOAT16-datatypen som verkar "duga" för AI, men vet inte detaljerna där. När jag laddar ner källkoden för ffmpeg 7.1 och kompilerar skall jag kika efter avx-assembler-koden 😊

Gå till inlägget

Ja, men vad är poängen med att dra upp AVX2 då? Nyheten handlar ju just om hur mycket handkodning kan hjälpa prestandan i specifika instruktioner. Att då försöka påskina att man fått det mesta av den prestandaökningen med att bara köra AVX2, som inte finns som handkodad, är ju direkt vilseledande.
Jämförelsen AVX2 mot AVX512 är irrelevant när nyheten främst gäller prestandaökning från handkodat, och det inte finns någon handkodad AVX2 variant.

Alltså, nyhetsvärdet är att vi potentiellt kan få ordentlig prestandaskjuts framöver med handkodade instruktioner för encodern.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Enligt den bilden

Så ger även AVX2 eller SSSE3 stora förbättringar jämfört med basnivån.

Enligt Wikipedia;
CPUs with AVX2
Intel

Haswell processors (Q2 2013) and newer, except models branded as Celeron and Pentium.
Celeron and Pentium branded processors starting with Tiger Lake (Q3 2020) and newer.[10]

AMD

Excavator processors (Q2 2015) and newer.

SSSE3 verkar finnas i redan i Core 2 hos Intel och Bulldozer hos AMD.

Så det verkar som det mesta som är nyare än Pentium 4 får betydande prestandaökning tack vare stöd för instruktionsuppsättningar som SSSE3, AVX2 jämfört med basnivån att inte ha dessa instruktionsuppsättningar.

Exempelvis;

Där kan vi se stöd för SSSE3.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Aleshi:

Ja, men vad är poängen med att dra upp AVX2 då? Nyheten handlar ju just om hur mycket handkodning kan hjälpa prestandan i specifika instruktioner. Att då försöka påskina att man fått det mesta av den prestandaökningen med att bara köra AVX2, som inte finns som handkodad, är ju direkt vilseledande.
Jämförelsen AVX2 mot AVX512 är irrelevant när nyheten främst gäller prestandaökning från handkodat, och det inte finns någon handkodad AVX2 variant.

Alltså, nyhetsvärdet är att vi potentiellt kan få ordentlig prestandaskjuts framöver med handkodade instruktioner för encodern.

Gå till inlägget

Det verkar vara ett fall av att om du ändrar på många saker så kan den totala skillnaden bli stor.

Som i FFmpeg's X inlägg;

...

mc_8tap_regular_w64_v_8bpc_c:		20660.6	( 1.00x)
mc_8tap_regular_w64_v_8bpc_ssse3:	512.8	(40.29x)
mc_8tap_regular_w64_v_8bpc_avx2:	305.6	(67.61x)
mc_8tap_regular_w64_v_8bpc_avx512icl:	218.0	(94.78x)

De här 93 gånger snabbare är bara om du jämför de bästa resultatet mot basnivån.
Jämför du med att köra AVX2 mot AVX512 är skillnaden inte alls lika stor.
Även om den fortfarande är ganska stor.
Sen hur stor del av den skillnaden beror på handskriven assembler och hur stor del är på grund av olika instruktionsuppsättningar framgår inte.

Lite som att om du tar en otränad person och tar tiden hur fort den personen kan "springa" (gå) 1 mil (10 km).
Sen får personen ett år på sig att träna.
Sen jämför du hur snabbt personen kan cykla 1 mil.

Hur stor del av skillnaden beror på att personen efter ett år är mer vältränad?
Hur stor del av skillnaden är att personen ett år senare använder cykel istället för att springa/gå ?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av GuessWho:

...
Hur stor del av skillnaden beror på att personen efter ett år är mer vältränad?
Hur stor del av skillnaden är att personen ett år senare använder cykel istället för att springa/gå ?

Gå till inlägget

Skrattar 😊 😊 😊 och rubriksättningen syftar ju på typ nåt sånt 😊 😊 😊

Visa signatur

MSI Prestige 16 Ryzen 9 AI 4K OLED (tidigare Dell XPS 17, MSI GS73VR)
Byggen: White Dream (2025) - Simply Red (2015) - Liten Lian Li (2011)

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av ErikLtz:

Åter till AVX: assemblerkodar man AVX512 och slår kompilatorn väsentligt, torde i stort sett samma handkodning med AVX2-instruktioner få samma effekt/2 mot kompilatorn:s AVX2-kod - skillnaden är huvudsakligen "bredden" 512 eller 256 bitar som motsvarar ett antal värden medan addition, multiplikation och sånt utförs på dessa värden "in parallell" - men dubbelt så många värden i 512-fallet då avx2=avx256 typ.

Gå till inlägget

Nja, i steget från AVX2 till AVX512 får du dubbel bredd på operationerna, dubbelt så många register, k-registren (maskregistren är faktiskt användbara till mycket och det blir mycket smidigare att köra villkorlig kod) så du skulle rent teoretiskt kunna få en uppsnabbning större än 2X, men i praktiken kommer man inte i närheten av det. Så länge som din workload inte enbart består av compute så lider AVX512 av samma minnesbandbreddsbegränsningar som AVX2. Samma data skall in och ut och det tar precis lika lång tid oavsett om det sker med AVX2 eller AVX512.

Kikar man på skärmdumpen så ser det ut som att AVX512 är runt 30% snabbare än AVX2-koden och det verkar helt rimligt. Huruvida AVX2-koden är handskriven eller kompilatorgenererad förtäljer väl inte historien. Någon som vet?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Yoshman:

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

Gå till inlägget

Jag kan bara hålla med om allt du skriver. Nej, det är varken portabelt eller tidseffektivt att skriva saker i assembler, men i vissa nischfall kan det vara motiverat även 2024.

Och nej, man skriver ju inte hela applikationer i assembler. Om man upptäcker att kompilatorn inte har gjort ett bra jobb i de tidskritiska looparna, exempelvis inte har använt en (ny) instruktion som är som klippt och skuren för att göra beräkningen i loopen, kan man klämma in lite AVX-intrinsics, inline assembler eller ta den genererade koden från kompilatorn som en startpunkt och modifiera. Att skriva från scratch vore ren galenskap.

I just det här fallet kan vi gissa det mest handlar om "för att det var roligt". Om de ser en 40% speedup jämfört med motsvarande AVX2-kod så är det väl tveksamt om de gjort ett så mycket bättre jobb än vad kompilatorn skulle göra.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Tankade ner källkoden för ffmpeg 7.1, kikade runt lite, kompilerade och testade, men njae lixom...

[ Gör inte anspråk på heltäckande analys - det kräver mycket mer och fler tester ]

Är det omkodning av mp4 till ny mp4 (skala upplösning, skala datamängd, ...) så använder ffmpeg libx264 för det tyngre jobbet. Argument som -vf scale=1920x1080 utförs av ffmpeg men är sannolikt en mindre del av jobbet mot decode och framförallt (re)encode i libx264 - så "handkodad assembler" för AVX512 i libx264 (och "inte bara" i ffmpeg) skulle göra mer för prestandan.

Test med den nykompilerade 7.1:an mot Ubuntu 24.4:ans inkluderade 6.1.1:a med

ffmpeg -i org.mp4 -c:v libx264 -vf scale=1280:720 -crf 25 -preset slow -an out1.mp4

tog 30 sekunder med bägge (182 mb 1920x1080 ca 112 sek klipp till 66 mb 1280x720). Bägge nämner AVX512 vid exekvering på Epyc-maskinen jag testar på:

libx264 @ ... using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 AVX512

men verkar som det är libx264 som berättar det i båda fallen.

Kollar man runt i koden finns 162 st .asm-filer i kataloger som libavfilter, libavcodec och libavutil. Av dessa nämner 53 st avx2 och endast 7 st avx512. Kikar i libavfilter/x86/vf_convolution.asm där funktionen filter_sobel_avx512 verkar använda avx512. sobel verkar vara något input-filter som den enkla omkodningen ovan inte använde.

Så man kan väl säga att de möjligheter AVX2 och AVX512 ger verkar användas "här och där" men skall man se stor prestandaskillnad borde det vara optimeringar i libx264 eller libopenh264 som skulle göra större skillnad - och som @Ingetledigtnamn skriver är det mycket mer än bara möjliga avx-beräkningar som sker.

Senast redigerat
Visa signatur

MSI Prestige 16 Ryzen 9 AI 4K OLED (tidigare Dell XPS 17, MSI GS73VR)
Byggen: White Dream (2025) - Simply Red (2015) - Liten Lian Li (2011)

Redigera
Citera flera Citera
1 2 3
Skriv svar