GCC 17 sta per portarsi dietro una novità che, vista da fuori, sembra quasi nulla. Una riga sola nel codice del compilatore. Eppure quella riga, modificata da un ingegnere Intel, fa salire le prestazioni delle CPU x86 oltre il 12% in un test di SPEC CPU 2017, sia su Intel Granite Rapids sia su AMD Zen 5. Niente trucchi, niente magia del compilatore. Solo un vecchio parametro che finalmente torna a parlare la lingua dei processori di oggi.
La storia di GCC è lunga. Nasce come compilatore C dentro il progetto GNU e col tempo diventa qualcosa di molto più ampio, una raccolta di frontend e backend capace di gestire tanti linguaggi e tante architetture diverse. Sulla piattaforma x86 convive da decenni con processori che non hanno quasi nulla in comune tra loro. Si va dal codice pensato per girare ovunque fino a target ben precisi come gli Intel Xeon Granite Rapids o gli AMD Zen 5. Il problema, però, è che gran parte del software in circolazione non viene compilato pensando a una singola CPU. Molti pacchetti Linux, librerie distribuite già pronte in forma binaria, container e build generiche usano ancora un profilo x86-64 costruito per funzionare bene un po’ su tutto, non per spremere fino all’ultimo una microarchitettura specifica.
Perché sbagliare un salto costa così caro
Le CPU x86 lavorano in modo speculativo. Quando incontrano un salto, provano a indovinare quale sia il percorso più probabile e iniziano a riempire la catena di esecuzione con le istruzioni di quel ramo. Questo meccanismo si chiama branch prediction ed è roba nota da tempo. Se la previsione è giusta, il programma va avanti liscio e nessuno se ne accorge. Se invece il processore ha puntato sul ramo sbagliato, deve buttare via tutto il lavoro già avviato, ripulire lo stato e ripartire dal percorso corretto.
Su processori ad alte prestazioni questo errore non equivale a una sola istruzione persa. Significa cicli di clock buttati, meno parallelismo utile, ritardi nel caricamento dei dati e unità di esecuzione che lavorano peggio. Un conto che, sommato, pesa parecchio.
Come una sola riga cambia tutto
A scoprire la cosa è stata Lili Cui, ingegnere software di Intel. L’idea di fondo è semplice. Le CPU moderne hanno pipeline più profonde, e questo rende le errate predizioni dei salti molto più costose di un tempo. Aumentando il peso assegnato a questa penalizzazione nella tabella di ottimizzazione generica del compilatore, si riesce a evitare buona parte dei blocchi della pipeline causati dai salti sbagliati.
Il dettaglio tecnico è quasi banale. Alzando di un valore pari a 3 la penalizzazione applicata dopo un errore di predizione, le prestazioni su Granite Rapids sono cresciute del 12,7% e quelle su Zen 5 del 12,1%. Numeri grossi, soprattutto se si pensa che dietro c’è una singola riga di codice cambiata con un intervento elementare.