Il progetto FFmpeg, alla base di molti strumenti e software per il montaggio video e la gestione di contenuti multimediali, torna sotto i riflettori per un risultato tecnico notevole.
Gli sviluppatori affermano di aver ottenuto un miglioramento delle prestazioni fino a 100 volte rispetto alla versione precedente, definendolo “il più grande incremento di sempre”.
C'è però un dettaglio importante: l’ottimizzazione riguarda una sola funzione, poco nota e di utilizzo molto limitato. Inoltre, il metodo utilizzato per raggiungere questo risultato sta facendo discutere: si tratta di codice Assembly scritto a mano, una tecnica ormai considerata superata dalla maggior parte degli sviluppatori moderni.
Nonostante l’impatto pratico sia contenuto, l’esperimento dimostra come ottimizzazioni mirate e “vecchio stile” possano ancora portare risultati estremi in termini di performance.
FFmpeg riscopre l’Assembly: ottimizzazioni estreme, ma con riserva
Il ritorno al linguaggio Assembly, una tecnica simbolo degli anni ’80 e ’90 per spremere ogni ciclo di clock dall’hardware, sta generando nostalgia e scetticismo nella comunità di sviluppatori. Sebbene oggi sia una pratica di nicchia, il team di FFmpeg continua a farne uso per ottenere ottimizzazioni estreme, definendosi apertamente “evangelisti dell’Assembly”.
Nella loro ultima patch, gli sviluppatori hanno riscritto il filtro rangedetect8_avx512 utilizzando le istruzioni AVX512, parte del toolkit SIMD (Single Instruction, Multiple Data), che consente alla CPU di eseguire più operazioni in parallelo. Il risultato è un’accelerazione fino a 100 volte superiore rispetto alla versione originale, anche se limitata a una singola funzione. Nei sistemi che non supportano AVX512, la variante AVX2 garantisce comunque un miglioramento del 65,63%.
Il team sottolinea chiaramente che non è FFmpeg nel suo complesso a essere 100 volte più veloce, ma solo quella funzione specifica. Una precisazione importante, soprattutto considerando che un risultato simile era stato annunciato già nel novembre 2024, quando una patch aveva portato alcune operazioni fino a 94 volte più rapide. In quel caso, parte del divario era dovuto a una disparità nel livello di complessità dei filtri: la versione generica in C utilizzava una convoluzione a 8 tap, mentre quella SIMD ne impiegava solo 6. Inoltre, compilare la versione C in release mode con un compilatore più efficiente come Clang riduceva del 50% il gap prestazionale, suggerendo che alcuni dei guadagni dichiarati fossero enfatizzati da confronti tra condizioni limite.
“Il gestore dei registri fa schifo nei compilatori,” hanno ironizzato i dev sui social, evidenziando le inefficienze dei compilatori moderni nella gestione dell’ottimizzazione a basso livello.
Nonostante le limitazioni, questo ritorno all’Assembly ha riacceso il dibattito sull’ottimizzazione estrema delle performance. FFmpeg è alla base di strumenti come VLC Media Player, YouTube downloader, software di transcodifica, compressione e streaming: anche miglioramenti minimi in singole funzioni possono avere effetti a catena su milioni di utenti.
Detto questo, ottenere risultati simili su larga scala è tutt’altro che semplice. Molte di queste ottimizzazioni sono difficili da replicare in altre parti del codice e potrebbero non tradursi in vantaggi concreti per gli utenti finali, soprattutto nel contesto reale di un software di montaggio video. Finché le funzioni principali non riceveranno lo stesso trattamento, l’idea di un FFmpeg significativamente più veloce potrebbe restare confinata ai benchmark tecnici.
Via TomsHardware