BOLT, l’ottimizzatore di codice di Facebook, è ufficialmente parte della collezione di tool LLVM

L’ottimizzazione del codice esistente, sia esso sorgente o binario, è una delle attività più frequenti e diffuse: migliorare anche solo di qualche punto percentuale può sembrare poca cosa, ma fatto in tanti punti e/o varie volte le prestazioni totali del software possono crescere davvero molto.

Raccontandovi di MOLD, e di come migliori i tempi per ottenere dal codice sorgente un eseguibile, abbiamo accennato al fatto che i passaggi sono molti. Ne consegue che i punti in cui poter intervenire sono almeno altrettanti, ovvero prima e dopo ciascuno di quei passaggi.
L’ottimizzazione del codice del Kernel (specie con LLVM) è un esempio di come si possa intervenire con risultati sbalorditivi direttamente sul codice sorgente, sebbene anche in questo caso per migliorare i tempi di compilazione e non le prestazioni del software prodotto.

Esistono strumenti appositi di analisi per “aggiustare” il codice prodotto, che sacrifichi un poco di pulizia nel codice stesso per ottenere delle performance migliori – come tempi di caricamento o velocità di esecuzione.
Potrebbe essere il riordinare l’elenco delle funzioni presenti, mettendo in testa (e quindi letta prima) quella usata più di frequente, o quella usata prima anche nel codice; oppure ripetere in vari punti del codice per evitare di dover saltare tra un punto e l’altro del codice. Sono cose che aiutano a guadagnare microsecondi ciascuna, ma se quel codice è chiamato varie migliaia di volte al secondo il miglioramento totale risulta essere apprezzabile.

Questi strumenti possono analizzare al volo i file (come fa l’opzione “-O” di GCC), ma per ottenere un miglioramento maggiore si può analizzare l’esecuzione del codice (sotto particolari condizioni, controllate) e compilare un profilo. Questo procedimento si chiama Profile Guided Optimization (GPO), e di solito avviene dopo la fase di compilazione ma prima del link (quello che fa MOLD).
Esiste anche il Link Time Optimization (LTO), ovvero dire al compilatore di aspettare il momento del link per applicare quelle ottimizzazioni calcolate al volo. Questo perché al momento del link si ha visibilità su tutto il codice, ed alcune ottimizzazioni potrebbero risultare in realtà nocive, o altre apparire solo perché in relazione con altri file.

Facebook da qualche anno sta sviluppando un tool per ottimizzare i binari dopo il link, quindi il risultato finale. Questo tool si chiama BOLT, e da subito è apparso molto promettente, tanto da essere adottato anche da Google.
Anche BOLT (Binary Optimization and Layout Tool, strumento di ottimizzazione del binario e del layout) si basa sull’uso di un profilo per poter fare la sua magia, e riesce ad operare insieme a GPO e/o LTO. Quindi, grandi possibilità
BOLT sovraintende ed analizza ogni passaggio della compilazione, ma interviene solo alla fine, per ottimizzare direttamente il prodotto finale.

Le potenzialità sembrano molto alte, soprattutto seguendo la presentazione fatta al Linux Plumbers Conference del settembre scorso, fatta da Maksim Panchenko, e che spiega nel dettaglio anche il funzionamento.

Dalle slide estraiamo il seguente grafico, che mostra il miglioramento nei tempi nella compilazione di LLVM e GCC – indice di prestazione dei compilatori stessi.

Si vede come BOLT lavori meglio di PGO, inteso come alternativa, ma si comporti ancora meglio se usati assieme (anche se è attivo anche LTO, in questo caso, non segnato).

BOLT usa molte librerie di LLVM, il compilatore concorrente di GCC, tanto da essere nato nel 2018 come uno degli strumenti da integrare in esso. A ottobre 2020 era quasi riuscito in quest’impresa: aveva ottenuto lo status di sotto-progetto. Con la merge dell’11 gennaio il processo si è completato: ora LLVM ha anche BOLT ufficialmente.

Pur ricordando che qualsiasi software ha bug più o meno problematici – e i tool di ottimizzazione si sono dimostrati spesso forieri di comportamenti molto strani – auguriamo una buona ottimizzazione a tutti!