# Ottimizzare C++/Ottimizzazione del codice C++/Numero di istruzioni

Ottimizzare C++
Copertina Tutti i moduli · Sviluppo
    CopertinaOttimizzare C++/Copertina
* IntroduzioneOttimizzare C++/Introduzione
* Ciclo di vita dell’ottimizzazioneOttimizzare C++/Ciclo di vita dell’ottimizzazione
* Scrivere codice C++ efficienteOttimizzare C++/Scrivere codice C++ efficiente
** Costrutti che migliorano le prestazioniOttimizzare C++/Scrivere codice C++ efficiente/Costrutti che migliorano le prestazioni
** Costrutti che peggiorano le prestazioniOttimizzare C++/Scrivere codice C++ efficiente/Costrutti che peggiorano le prestazioni
** Costruzioni e distruzioniOttimizzare C++/Scrivere codice C++ efficiente/Costruzioni e distruzioni
** Allocazioni e deallocazioniOttimizzare C++/Scrivere codice C++ efficiente/Allocazioni e deallocazioni
** Accesso alla memoriaOttimizzare C++/Scrivere codice C++ efficiente/Accesso alla memoria
** Uso dei threadOttimizzare C++/Scrivere codice C++ efficiente/Uso dei thread
* Tecniche generali di ottimizzazioneOttimizzare C++/Tecniche generali di ottimizzazione
** Input/OutputOttimizzare C++/Tecniche generali di ottimizzazione/Input/Output
** CachingOttimizzare C++/Tecniche generali di ottimizzazione/Caching
** OrdinamentoOttimizzare C++/Tecniche generali di ottimizzazione/Ordinamento
** Altre tecnicheOttimizzare C++/Tecniche generali di ottimizzazione/Altre tecniche
* Ottimizzazione del codice C++Ottimizzare C++/Ottimizzazione del codice C++
** Allocazione e deallocazioneOttimizzare C++/Ottimizzazione del codice C++/Allocazione e deallocazione
** Supporto run-timeOttimizzare C++/Ottimizzazione del codice C++/Supporto run-time
** Numero di istruzioniOttimizzare C++/Ottimizzazione del codice C++/Numero di istruzioni
** Costruzioni e distruzioniOttimizzare C++/Ottimizzazione del codice C++/Costruzioni e distruzioni
** PipelineOttimizzare C++/Ottimizzazione del codice C++/Pipeline
** Accesso alla memoriaOttimizzare C++/Ottimizzazione del codice C++/Accesso alla memoria
** Operazioni velociOttimizzare C++/Ottimizzazione del codice C++/Operazioni veloci
Modifica il sommario
Anche i costrutti che generano del codice espanso inline possono avere un costo significativo, in quanto tali istruzioni devono pur essere eseguite.
In questa sezione si descrivono le tecniche per ridurre il numero complessivo di istruzioni che il processore dovrà eseguire per compiere una data operazione.

### Ordine dei casi in istruzioni switch

Nelle istruzioni switch, poni i casi in ordine di probabilità decrescente.
Nella linea-guida "Ordine dei casi dell'istruzione switch" del capitolo 3.1, si consigliava già di porre prima di casi più tipici, cioè quelli che si presume siano più probabili. Come ulteriore ottimizzazione, si potrebbe contare, in esecuzioni tipiche, il numero di volte in cui viene eseguito ognuno dei singoli casi, e porre i casi in ordine da quello eseguito più volte a quello eseguito meno volte.

### Parametri interi di template

Se un certo valore intero è una costante nel codice applicativo, ma è una variabile nel codice di libreria, rendilo un parametro di template.
Supponi che stai scrivendo la seguente funzione di libreria, in cui sia x che y non hanno un valore definito in fase di sviluppo della libreria:
Tale funzione può essere chiamata dal seguente codice applicativo, nel quale x non ha un valore costante, ma y è la costante 4:
Se, mentre scrivi la libreria, sai che il chiamante ti passerà sicuramente una costante intera come argomento y, puoi trasformare la tua funzione nel seguente template di funzione:
Tale funzione può essere chiamata dal seguente codice applicativo:
Tale chiamata istanzia automaticamente la seguente funzione:
Quest'ultima funzione è più veloce della precedente funzione f1, per i seguenti motivi:
* Viene passato un solo parametro alla funzione (x) invece di due (x e y).
* La moltiplicazione per una costante intera (4) è più veloce della moltiplicazione per una variabile intera (y).
* Dato che il valore costante (4) è una potenza di due, il compilatore, invece di eseguire una moltiplicazione intera, esegue uno scorrimento di bit.
In generale, i parametri di template interi sono delle costanti per chi istanzia il template e quindi per il compilatore, e le costanti sono gestite in modo più efficiente delle variabili. Inoltre, alcune operazioni su costanti vengono pre-calcolate in fase di compilazione.
Se invece di avere una funzione avevi già un template di funzione, basta aggiungere un ulteriore parametro a tale template.

### Il Curiously Recurring Template Pattern

Se devi scrivere una classe base astratta di libreria tale che in ogni algoritmo nel codice applicativo si userà una sola classe derivata da tale classe base, usa il Curiously Recurring Template Pattern.
Supponi che stai scrivendo la seguente classe base di libreria:
In questa classe, la funzione g esegue un algoritmo che chiama la funzione f come operazione astratta per l'algoritmo. Nella terminologia dei design pattern, g è un template method, ossia un algoritmo astratto con uno o più punti di personalizzazione. Lo scopo di questa classe è consentire di scrivere il seguente codice applicativo:
In tal caso, è possibile convertire il precedente codice di libreria nel seguente:
Il codice applicativo, di conseguenza, diventerà il seguente:
In tal modo, si ha binding statico alla funzione membro Derivata1::f della chiamata a f fatta all'interno della funzione membro Base<Derivata1>::g, cioè la chiamata a tale funzione non è più di tipo virtual, e può essere espansa inline.
Tuttavia, supponiamo che si volesse aggiungere la seguente definizione:
Con questa soluzione non sarebbe più possibile definire un puntatore o riferimento a una classe base comune sia a Derivata1 che a Derivata2, in quanto tali classi risultano due tipi senza alcuna relazione; di conseguenza, questa soluzione non è applicabile se si vuole permettere al codice applicativo di definire un contenitore di oggetti arbitrari derivati dalla classe Base.
Altre limitazioni sono le seguenti:
* Base è necessariamente un tipo astratto;
* un oggetto di tipo Derivata1 non può essere convertito in un oggetto di tipo Derivata2 o viceversa;
* per ogni derivazione di Base, tutto il codice macchina di Base viene duplicato.

### Il pattern Strategy

Se un oggetto che implementa il design pattern Strategy (noto anche come design pattern Policy) è una costante in ogni algoritmo nel codice applicativo, elimina tale oggetto, rendi static tutti i suoi membri, e aggiungi tale classe come parametro di template.
Supponi che stai scrivendo il seguente codice di libreria, che implementa il design pattern Strategy:
Questo codice di libreria ha lo scopo di consentire il seguente codice applicativo:
In tal caso, è possibile convertire il precedente codice di libreria nel seguente:
Il codice applicativo, di conseguenza, diventerà il seguente:
In tal modo, si evita l'oggetto-strategia, e si ha il binding statico delle funzioni membro MyStrategy::is_valid e MyStrategy::run, cioè si evitano chiamate a funzioni virtual.
Tuttavia, tale soluzione non consente di decidere la strategia in fase di esecuzione, e tanto meno di cambiarla durante la vita dell'oggetto. Inoltre, il codice dell'algoritmo astratto viene duplicato ogni volta che viene personalizzato.

### Operatori bit-a-bit

Dovendo eseguire operazioni booleane su un insieme di singoli bit, affianca tali bit in un oggetto di tipo unsigned int, e usa gli operatori bit-a-bit su tale oggetto.
Gli operatori bit-a-bit (&, |, ^, <<, e >>) sono tradotti in singole istruzioni veloci, e operano su tutti i bit di un registro in una sola istruzione.