Ovvero, perchè compilare per i386 se in realtà ho Pentium Dual Core, nel dettaglio una CPU Intel T3200?
Non ho mai avuto sclerosi particolari sulla velocità del sistema, tipo overclocking e cose simili, al massimo dedico un pò di tempo al tuning delle applicazioni che uso più spesso, ma mi fermo lì.
La distribuzione Linux che uso sul sistema in questione, che è il mio portatile, è Ubuntu 8.10 (che tra poco verrà aggiornata alla 9.04, dove la prima cifra corrisponde all’anno, e le seconde due al mese, Ubuntu prevede un rilascio semestrale, quindi aprile e ottobre), e di conseguenza le applicazioni e le librerie installate sono precompilate, e per poter supportare il maggior numero di processori in una release sola non si sfruttano appieno le potenzialità disponibili nelle CPU di ultima generazione, da quì l’indicazione i386.
Ma questo è il sistema base e le applicazioni a corredo, mentre per quanto riguarda il DE (Desktop Environment) il discorso cambia, visto che uso E17 compilato dai sorgenti (ormai lo sanno anche i sassi…).
Mi sono informato, chiedendo sia a Google che ad altri amici in chat, e sono giunto alla conclusione che le opzioni da passare al compilatore potevano essere queste:

-g -O2 -march=nocona -pipe -fomit-frame-pointer

Qualche spiegazione.

-g : genera le informazioni di debugging, non ha quindi relazione con l’ottimizzazione, ma per me non può mancare;
-02 : indica al compilatore di eseguire le ottimizzazioni al livello 2;
-march=nocona : indica al compilatore di generare del codice ottimizzato per questa famiglia di processori, e in pratica abilita il supporto per i 64bit, MMX, SSE, SSE2 e SSE3;
-pipe : utilizza le pipe al posto dei file temporanei durante le varie fasi di compilazione;
-fomit-frame-pointer : rende disponibile un ulteriore registro per varie funzioni;

Prima di applicare le modifiche, ho lanciato per dieci volte una applicazione (expedite) che fornisce in output una informazione quantitativa sulle prestazioni, salvando l’output di ogni esecuzione in file di log. Una volta appliicate le modifiche, e ricompilato tutto l’albero dei sorgenti, ho eseguito di nuovo lo stesso procedimento, expedite per dieci volte con il salvataggio dei log.
Ho messo i numeri ottenuti un foglio elettronico (inizialmente OpenOffice, poi ho optato per Google Documents per avere i dati sempre disponibili) per elaborarli, e alla fine ho avuto come risultato il grafico qui sotto (click sopra per una verisone ingrandita).

Come si può vedere tutti i test hanno goduto di un sensibile miglioramento, e alla fine la colonna finale (EVAS SPEED) ha mostrato un incremento del 38%, mica poco!!
L’unica cosa della quale non sono certo è l’opzione -fomit-frame-pointer, devo verificare che non influisca negativamente sul debugging; ignorando però questa cosa, ad esempio per una utenza “normale”, non ci sono problemi.

Per i più curiosi, ecco il link allo spreadsheet contenente tutti i risultati.

Alla prox, e happy tuning :)

[tags]e17,enlightenment,optimization[/tags]