Ottimizzare C++/Scrivere codice C++ efficiente: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica |
Nessun oggetto della modifica |
||
Riga 100:
<source lang=cpp>
case 10:
case 13:
break;
case 11:
break;
}
Riga 158:
Se il compilatore non generasse la jump-table, i casi verrebbero confrontati in ordine di comparizione, per cui nei casi più tipici verrebbero fatti meno confronti.
=== Raggruppamento di più array in un array di strutture ===
'''Invece di elaborare in parallelo due o più array della stessa lunghezza, elabora un solo array di oggetti compositi. Esempio: Invece del seguente codice:
<source lang=cpp>
const int n = 10000;
Line 168 ⟶ 171:
}
</source>
scrivi il seguente codice:
<source lang=cpp>
const int n = 10000;
Line 176 ⟶ 181:
}
</source>
In tal modo, i dati da elaborare insieme sono più vicini tra di loro in memoria, e questo permette di ottimizzare l'uso della cache dei dati, e di indirizzare tali dati con istruzioni più compatte, che quindi ottimizzano l'uso della cache del codice.
=== Raggruppamento di argomenti di funzione ===
'''Se una funzione riceve almeno sei argomenti, e viene chiamata spesso con gli stessi valori tranne eventualmente uno o due, crea un oggetto che contiene tutti gli argomenti, e passa alla funzione tale oggetto per puntatore a costante o riferimento a costante.'''
Se una funzione riceve pochi argomenti, questi vengono posti direttamente nei registri e quindi il passaggio è molto veloce; ma se non sono pochi, gli argomenti devono essere posti nello stack, anche se sono gli stessi della precedente chiamata alla stessa funzione.
Se invece si passa solo
Per esempio, rispetto al seguente codice:
<source lang=cpp>
for (int i = 0; i < 1000; ++i) {
Line 190 ⟶ 199:
}
</source>
il seguente codice è probabilmente più efficiente:
<source lang=cpp>
struct {
Line 203 ⟶ 214:
}
</source>
=== Uso dei tipi più efficienti ===
'''Per memorizzare in un oggetto dei numeri interi, usa il tipo ''int'' o il tipo ''unsigned int'', a meno che sia necessario un tipo più lungo; e per memorizzare dei numeri a virgola mobile, usa il tipo ''double'', a meno che sia necessario il tipo ''long double''. Se l’oggetto risultante è medio o grande, sostituisci i tipi interi con il tipo intero più piccolo in grado di contenerlo, ma senza usare i bit-field, e sostituisci i tipi a virgola mobile con il tipo ''float'', a meno che sia necessaria maggiore precisione.'''
I tipi ''int'' e ''unsigned int'' sono per definizione quelli più efficienti su qualunque piattaforma.
I tipi ''double'' sono efficienti quanto i ''float'', ma sono più precisi.
Tuttavia, nel caso di interi contenuti in array medi o grandi, è meglio minimizzare la dimensione in byte dell’array.
Per esempio, per memorizzare un numero intero che può essere compreso tra -1000 e 1000, si può usare uno ''short'', mentre per memorizzare un numero intero che può essere compreso tra 0 e 200, si può usare un ''unsigned char''.
I bit-field contribuirebbero a minimizzare la dimensione in byte dell'array, ma la loro elaborazione introduce un rallentamento che potrebbe essere eccessivo, per cui andrebbero eventualmente introdotti solo in fase di ottimizzazione.
=== Uso di funzioni membro di contenitori ===
'''Per cercare un elemento in un contenitore, usa una funzione membro del contenitore, invece di un algoritmo STL.'''
Se è stata creata una tale funzione membro specifica quando esisteva già un algoritmo STL generico, è solo perché tale funzione membro è più efficiente.
Per esempio, per cercare in un oggetto ''std::set'' si può usare l'algoritmo generico ''find'', o la funzione membro ''find''; ma il primo ha complessità lineare (O(n)), mentre la seconda ha complessità logaritmica (O(log(n))).
=== Ricerca in sequenze ordinate ===
'''Per cercare un elemento in una sequenza ordinata, usa gli algoritmi ''lower_bound'', ''upper_bound'', ''equal_range'', o ''binary_search''.'''
Dato che tutti i citati algoritmi usano la ricerca binaria di complessità logaritmica (O(log(n))), sono più veloci dell'algoritmo ''find'', che usa la ricerca sequenziale di complessità lineare (O(n)).
== Come evitare i costi di costrutti C++ che peggiorano le prestazioni ==
Line 225 ⟶ 248:
Altri costrutti sono alquanto inefficienti, e devono quindi essere usati con grande parsimonia.
=== Uso di ''throw'' ===
'''Chiama ''throw'' solamente quando si dovrà avvisare l'utente del fallimento del comando corrente.'''
Il sollevamento di una eccezione ha un costo molto elevato, dell'ordine dei 10000 cicli di processore.
Se tale operazione viene effettuata solamente ogni volta che un messaggio viene mostrato all'utente o scritto in un file di log, si ha la garanzia che non verrà eseguita troppo spesso.
Se invece la si effettua come operazione algoritmica, anche se pensata inizialmente per essere eseguita raramente, potrebbe finire per essere eseguita frequentemente.
=== Derivazione ''virtual'' ===
Le funzioni membro delle classi base derivate in modo ''virtual'' sono un
Per esempio, considera le seguenti definizioni di classe:
Line 240 ⟶ 269:
class C: public B1, public B2 { ... };
</source>
Con tali definizioni, ogni oggetto di classe C contiene due oggetti distinti di classe A, uno facente parte della classe base B1, e l'altro facente parte della classe base B2.
Line 245 ⟶ 275:
Se invece tale oggetto di classe A contiene qualche variabile membro, e si intende che debba essere unico per ogni oggetto di classe C, si deve usare la derivazione virtual, nel seguente modo:
<source lang=cpp>
class A { ... };
Line 251 ⟶ 282:
class C: public B1, public B2 { ... };
</source>
Questa situazione è l'unica in cui è necessaria la derivazione ''virtual''.
=== Funzioni membro ''virtual'' ===
'''In ogni classe, non definire sistematicamente ''virtual'' tutte le funzioni membro, ma solo le funzioni membro di cui prevedi la necessità di una ridefinizione, a parte il distruttore, il quale deve essere definito ''virtual'' se e solo se la classe contiene almeno un'altra funzione membro ''virtual''.'''
A parità di condizioni, le classi che contengono almeno una funzione membro ''virtual'' occupano un po' più spazio delle classi che non ne contengono, e gli oggetti delle classi che contengono almeno una funzione membro ''virtual'' occupano un po' più spazio e la loro costruzione richiede un po' più di tempo rispetto agli oggetti di classi che non contengono funzioni membro ''virtual''.
Le funzioni membro ''virtual'' occupano po' più spazio e sono un po' più lente da chiamare delle funzioni membro non-''virtual''.
=== Funzioni membro ''static'' ===
'''In ogni classe, dichiara ''static'' ogni funzione membro che non accede ai membri ''non-static'' di tale classe.'''
In altre parole, dichiara ''static'' tutte le funzioni membro che puoi.
In questo modo, non viene passato l’argomento implicito ''this''.
=== Template di classi polimorfiche ===
'''Non definire template di classi polimorfiche.'''
I template di classe, ogni volta che vengono istanziati, producono una copia del codice oggetto, e se contengono funzioni virtuali producono una copia della ''vtable'' e della ''RTTI''. Questi dati ingrandiscono eccessivamente il programma.
=== Annullamento dell'argomento di delete ===
'''Non annullare un puntatore dopo aver chiamato ''delete'' su di esso, se sei sicuro che tale puntatore non verrà più usato.'''
L'uso più tipico dell'operatore ''delete'' si ha quando in un distruttore si dealloca un oggetto posseduto dall'oggetto in corso di distruzione; in tale contesto, si chiama ''delete'' su una variabile membro di tipo puntatore.
Dato che solitamente un distruttore non è così complicato da faticare a capire quali parti dell'oggetto corrente sono già state distrutte e quali non ancora, e dato che il puntatore usato per la chiamata a ''delete'' cesserà di esistere alla fine del distruttore stesso, anche se si lascia il valore corrente del puntatore non più valido, non si corre il rischio di usarlo accidentalmente.
D'altra parte, annullare il puntatore richiede una seppur piccolissima quantità di tempo.
Come tecnica di collaudo o di debugging, si puo' adottare la regola di annullare sempre il puntatore a cui è stato applicato l'operatore ''delete'' nella generazione di una versione finalizzata al collaudo o debugging, ma farlo anche nella generazione del codice di produzione è un'inutile inefficienza.
=== Uso di deallocatori automatici ===
La garbage collection, cioè il recupero automatico della memoria non più referenziata, fornisce la comodità di non doversi occupare della deallocazione della memoria, e previene i ''memory leak''. Tale funzionalità non viene fornita dalla libreria standard, ma viene fornita da librerie non-standard. Tuttavia, tale tecnica di gestione della memoria offre prestazioni peggiori della deallocazione esplicita.
La libreria standard del C++98 contiene un solo smart-pointer,
Normalmente bisognerebbe, in fase di progettazione, cercare di assegnare ogni oggetto ad un proprietario, che avrà la responsabilità di distruggerlo.
Solo == Come evitare inutili costruzioni e le distruzioni di oggetti ==
===
'''Dichiara le variabili il più tardi possibile.'''
Dichiarare una variabile il più tardi possibile, significa sia dichiararla nell'ambito più stretto possibile, sia dichiararla il più avanti possibile entro quell'ambito.
Essere nell'ambito più stretto possibile comporta che se tale ambito non viene mai eseguito, l'oggetto associato alla variabile non viene mai costruito né distrutto.
Essere il più avanti possibile all’interno di un ambito comporta che se prima di tale dichiarazione c'è un'uscita prematura, tramite ''return'' o ''break'' o ''continue'', l’oggetto associato alla variabile non viene mai costruito né distrutto.
Inoltre, spesso all'inizio di una routine non si ha un valore appropriato per inizializzare l'oggetto associato alla variabile, e quindi si è costretti a inizializzarla con un valore di default, e poi assegnarle il valore appropriato.
Se invece la si dichiara quando si ha a disposizione il valore appropriato, la si può inizializzare con tale valore senza bisogno di fare un successivo assegnamento.
=== Inizializzazioni ===
'''Usa inizializzazioni invece di assegnamenti. In particolare, nei costruttori usa le liste di inizializzazione.'''
Se un oggetto di classe non viene inizializzato esplicitamente, viene comunque inizializzato automaticamente dal costruttore di default.
In generale, chiamare il costruttore di default seguito da un assegnamento di un valore è meno efficiente o ugualmene efficiente che chiamare solo un costruttore con tale valore.
=== Operatori di incremento/decremento ===
'''Usa gli operatori prefissi di incremento (++) e decremento (--) invece dei corrispondenti operatori postfissi, se il valore dell'espressione non viene usato.'''
Se l'oggetto incrementato è di un tipo fondamentale, non ci sono differenze tra le due forme, ma se si tratta di un tipo composito, l'operatore postfisso comporta la creazione di un inutile oggetto temporaneo, mentre l'operatore prefisso no.
Siccome ogni oggetto che è attualmente di un tipo fondamentale potrebbe diventare in futuro di una classe, è bene usare sempre quell'operatore che in quest'ultimo caso è più efficiente.
Se invece il valore dell'espressione formata dall’operatore di incremento o decremento viene usata in un'espressione più grande, potrebbe essere opportuno usare l'operatore postfisso.
=== Operatori compositi di assegnamento ===
'''Usa gli operatori compositi di assegnamento (come in ''a += b'') invece degli operatori semplici combinati con operatori di assegnamento (come in ''a = a + b'').'''
Tipicamente un operatore semplice, come nell'espressione ''a + b'', crea un oggetto temporaneo.
Per esempio, nel seguente codice, gli operatori ''+'' creano stringhe temporanee, la cui creazione e distruzione richiede tempo:
<source lang=cpp>
</source>
Il seguente codice, equivalente al precedente, risulta più efficiente, in quanto l'operatore ''+='' non crea oggetti temporanei:
<source lang=cpp>
</source>
===
'''Quando devi passare un argomento ''x'' di tipo ''T'' a una funzione, usa il seguente criterio:'''
Se ''x'' è un argomento di solo input,
se ''x'' può essere
passalo per puntatore a costante (''const T* x Il passaggio per riferimento è più efficiente del passaggio per puntatore in quanto facilita al compilatore l’eliminazione della variabile, e in quanto il chiamato non deve verificare se il riferimento è valido o nullo; tuttavia, il puntatore ha il pregio di poter rappresentare un valore nullo, ed è più efficiente passare solo un puntatore, che un riferimento a un oggetto insieme a un booleano che indica se tale riferimento è valido.
Line 336 ⟶ 402:
Un oggetto composito veloce da copiare potrebbe essere efficientemente passato per valore, ma, a meno che si tratti di un iteratore o di un oggetto-funzione, per i quali si assume l’efficienza della copia, tale tecnica è rischiosa, in quanto l’oggetto potrebbe diventare in futuro più lento da copiare. Per esempio, se un oggetto di classe Point contiene solo due float, potrebbe essere efficientemente passato per valore; ma se in futuro si aggiunge un terzo float, o se i float diventano double, potrebbe diventare più efficiente il passaggio per riferimento.
=== Diciarazione ''explicit'' ===
'''Dichiara ''explicit'' tutti i costruttori che possono ricevere un solo argomento, eccetto i costruttori di copia delle classi concrete. I costruttori impliciti possono essere chiamati automaticamente dal compilatore che esegue una conversione automatica. A seconda della complessità del costruttore, tale chiamata può richiedere molto più tempo del necessario. Rendendo obbligatoriamente esplicita tale conversione, il compilatore potrebbe scegliere un’altra funzione in overload, evitando così di chiamare il costruttore, oppure segnalare errore e costringere il programmatore a scegliere un’altra strada per evitare la chiamata al costruttore.
Per i costruttori di copia delle classi concrete si deve fare eccezione, per consentirne il passaggio per valore. Per le classi astratte, anche i costruttori di copia possono essere dichiarati ''explicit'', in quanto, per definizione, le classi astratte non si possono istanziare, e quindi gli oggetti di tale tipo non dovrebbero mai essere passati per valore.
=== Operatori di conversione ===
'''Non dichiarare operatori di conversione (in C++0x, dichiarali explicit). Gli operatori di conversioni consentono conversioni implicite, e quandi incorrono nello stesso problema dei costruttori impliciti.
Line 348 ⟶ 418:
Se tali conversioni sono necessarie, fornisci invece una funzione membro equivalente, che può essere chiamata solo esplicitamente.
=== Idioma ''Pimpl'' ===
'''Non usare sistematicamente l'idioma ''Pimpl'', ma solo quando vuoi rendere il resto del programma indipendente dall'implementazione di una classe. L'idioma Pimpl consiste nel memorizzare nell'oggetto solamente un puntatore alla struttura che contiene tutte le informazioni utili di tale oggetto.
Line 354 ⟶ 426:
Il vantaggio principale di tale idioma è che velocizza la compilazione incrementale del codice, cioè rende meno probabile che una piccola modifica ai sorgenti comporti la necessità di ricompilare grandi quantità di codice.
Tale idioma consente anche di velocizzare alcune operazioni, come lo swap tra due oggetti, ma in generale rallenta gli accessi ai dati dell'oggetto a causa del livello di indirettezza, e provoca un'allocazione aggiuntiva per ogni creazione e copia di tale oggetto.
Quindi non dovrebbe essere usato per classi le cui funzioni membro === Iteratori e oggetti_funzione ===
'''Nelle classi di iteratori o di oggetti-funzione, fa' in modo che tali oggetti siano piccolissimi e che non allochino memoria dinamica.'''
Gli algoritmi di STL passano tali oggetti per valore.
Pertanto, se la loro copia non è estremamente efficiente, gli algoritmi STL diventano lenti.
== Come evitare inutili allocazioni e deallocazioni di memoria ==
Line 372 ⟶ 448:
Tuttavia, qui si presenteranno regole per ridurre il numero di allocazioni di memoria per un dato numero di chiamate all'operatore new.
=== Array di lunghezza fissa ===
'''Se un array statico o non grande ha lunghezza costante, non usare un oggetto vector, ma usa un array del C, o un oggetto boost:array.'''
I vector memorizzano i dati in un buffer allocato dinamicamente, mentre le altre soluzioni proposte allocano i dati nell'oggetto stesso.
Questo consente di evitare allocazioni/deallocazioni di memoria dinamica e di favorire la località dei dati.
Se l'array è medio o grande, tali vantaggi diminuiscono, e invece risulta più importante evitare di usare troppo spazio sullo stack.
=== Allocatore a blocchi ===
'''Se devi allocare numerosi blocchi di memoria della stessa dimensione, assicurati di usare un allocatore a blocchi.'''
Un ''allocatore a blocchi'' (detto anche ''allocatore a pool'') alloca blocchi di memoria medi o grandi, e fornisce servizi di allocazione/deallocazione di blocchi più piccoli di dimensione costante, offrendo alta velocità di allocazione/deallocazione, bassa frammentazione della memoria, uso efficiente delle cache dei dati e della memoria virtuale.
In particolare, un allocatore di questo tipo migliora notevolmente le prestazioni dei contenitori ''std::list'', ''std::set'', ''std::multi_set'', ''std::map'', e ''std::multi_map''.
Se la tua implementazione della libreria standard non usa già un allocatore a blocchi per questi contenitori, dovresti procurartene uno (per esempio, questo: http://www.codeproject.com/KB/stl/blockallocator.aspx), e specificarlo come parametro di template per le istanze di tali template di contenitori.
=== Aggiunta di elementi a collezione ===
'''Per aggiungere elementi in fondo a una collezione, usa ''push_back'' per aggiungere un singolo elemento, ''back_inserter'' per far aggiungere elementi a un algoritmo STL, ''insert'' per inserire una sequenza.'''
La funzione ''push_back'' garantisce un tempo lineare ammortizzato, in quanto, nel caso del ''vector'', ingrandisce esponenzialmente la capacità.
La classe ''back_inserter'' chiama internamente la funzione ''push_back''.
La funzione ''insert'' permette di inserire in modo ottimizzato un'intera sequenza, e quindi una chiamata di questo tipo è più veloce di numerose chiamate a ''push_back''.
== Come velocizzare l’accesso alla memoria principale ==
=== Ordine di accesso alla memoria ===
'''Accedi alla memoria in ordine crescente; in particolare, scandisci gli array in ordine crescente, scandisci gli array multidimensionali usando gli indice più a destra per i cicli più interni, nei costruttori delle classi e negli operatori di assegnamento (operator=) accedi alle variabili membro nell’ordine in cui sono dichiarate nella classe.'''
La cache dei dati ottimizza gli accessi alla memoria in ordine sequenziale crescente. Quando si itera su un array multidimensionale, il loop più interno deve iterare sull'ultimo indice. In tal modo, è garantito che le celle vengono elaborate nell’ordine in cui si trovano in memoria. Per esempio:
<source lang=cpp>
float a[num_livelli][num_righe][num_colonne];
Line 403 ⟶ 495:
}
</source>
=== Allineamento di memoria ===
'''Lascia l'allineamento di memoria suggerito dal compilatore.'''
I compilatori attivano di default un criterio di allineamento dei tipi fondamentali, per cui le variabili di ogni tipo possono iniziare solo a determinati indirizzi di memoria. Tale criterio solitamente garantisce le massime prestazioni, ma può introdurre degli spazi inutilizzati tra le variabili. Se per alcune strutture è necessario eliminare tali spazi, usa le direttiva ''pragma'' per confinare tale impaccamento alle sole strutture per cui è necessario.
=== Raggruppamento di funzioni in unità di compilazione ===
'''Definisci nella stessa unità di compilazione tutte le funzioni membro di una classe, le funzioni ''friend'' di tale classe e le funzioni delle classi ''friend'' di tale classe, a meno che il file risultante diventi scomodo da gestire per la sua dimensione eccessiva.'''
In tal modo, il codice macchina prodotto compilando tali routine e i dati statici a cui accederà avranno indirizzi vicini tra loro.
Line 413 ⟶ 510:
== Quando usare i thread ==
=== Thread di lavoro ===
In tal modo, il thread principale si occupa solo di gestire l'interfaccia utente, ed è pronto a rispondere ad altri comandi.
Assegnando al thread di calcolo priorità più bassa del normale, l'interfaccia utente rimane veloce quasi come se non ci fosse un’elaborazione in corso.
Questa linea-guida in realtà non aiuta a migliorare la velocità dell'applicazione, ma solo la sua responsività.
Tuttavia, questo è percepito dagli utenti come un aumento di velocità.
=== Thread di lavoro multipli ===
'''In un sistema multicore, se riesci a suddividere un’elaborazione in più thread, usa tanti thread di calcolo quanti sono i core di processore.'''
In tal modo ogni core può elaborare un thread. Se i thread di calcolo fossero più dei processori, ci sarebbe contesa tra i thread, e questo rallenterebbe l’elaborazione. Il thread di interfaccia utente non rallenta, in quanto è pressoché inattivo.
=== Uso di librerie multi-threaded ===
'''Se sviluppi un'applicazione single-threaded non usare librerie progettate per applicazioni multi-threaded. Le tecniche per rendere thread-safe una libreria possono dover usare memoria e tempo. Se non usi i thread, evita di pagarne il costo.
=== Creazione di librerie multi-threaded ===
'''Se sviluppi una libreria, gestisci correttamente il caso in cui sia usata da applicazioni multi-threaded, ma ottimizza anche il caso in cui sia usata da applicazioni single-threaded. Le tecniche per rendere thread-safe una libreria possono dover usare memoria e tempo. Se gli utenti della tua libreria non usano i thread, evita di fargliene pagare il costo.
=== Mutua esclusione ===
'''Usa primitive di mutua esclusione solo quando più thread accedono contemporaneamente agli stessi dati, e almeno uno degli accessi è in scrittura. Le primitive di mutua esclusione richiedono tempo.
Line 436 ⟶ 547:
Se sei sicuro che in un dato periodo di tempo nessun thread scrive in un'area di memoria, non c'è bisogno di sincronizzare gli accessi in lettura a tale area.
[[Categoria:Ottimizzare C++|Scrivere codice C++ efficiente]]
| |||