Quando, se mai, lo srotolamento del ciclo è ancora utile?

Ho cercato di ottimizzare un codice estremamente critico per le prestazioni (un algoritmo di ordinamento rapido che viene chiamato milioni e milioni di volte all'interno di una simulazione di Monte Carlo) eseguendo il looping. Ecco il ciclo interno che sto cercando di accelerare:

// Search for elements to swap.
while(myArray[++index1] < pivot) {}
while(pivot < myArray[--index2]) {}

Ho provato a srotolare qualcosa come:

while(true) {
    if(myArray[++index1] < pivot) break;
    if(myArray[++index1] < pivot) break;
    // More unrolling
}


while(true) {
    if(pivot < myArray[--index2]) break;
    if(pivot < myArray[--index2]) break;
    // More unrolling
}

Questo non ha fatto alcuna differenza, quindi l'ho cambiato di nuovo in una forma più leggibile. Ho avuto esperienze simili altre volte in cui ho provato lo srotolamento del loop. Data la qualità dei predittori di branch sull'hardware moderno, quando, se mai, lo srotolamento del loop è ancora un'ottimizzazione utile?

Lo srotolamento del ciclo ha senso se è possibile interrompere le catene di dipendenze. Questo dà a una CPU fuori servizio o super scalare la possibilità di programmare meglio le cose e quindi funzionare più velocemente.

Un semplice esempio:

for (int i=0; i<n; i++)
{
  sum += data[i];
}

Qui la catena di dipendenza degli argomenti è molto breve. Se si verifica uno stallo perché si ha una mancanza di cache sull'array di dati, la cpu non può fare altro che aspettare.

D'altra parte questo codice:

for (int i=0; i<n; i+=4)
{
  sum1 += data[i+0];
  sum2 += data[i+1];
  sum3 += data[i+2];
  sum4 += data[i+3];
}
sum = sum1 + sum2 + sum3 + sum4;

potrebbe correre più velocemente. Se si ottiene un errore di cache o un altro stallo in un calcolo, ci sono ancora altre tre catene di dipendenze che non dipendono dallo stallo. Una CPU fuori servizio può eseguirli.

Quelle non farebbero alcuna differenza perché stai facendo lo stesso numero di confronti. Ecco un esempio migliore. Invece di:

for (int i=0; i<200; i++) {
  doStuff();
}

Scrivi:

for (int i=0; i<50; i++) {
  doStuff();
  doStuff();
  doStuff();
  doStuff();
}

Anche allora quasi certamente non avrà importanza, ma ora stai facendo 50 confronti invece di 200 (immagina che il confronto sia più complesso).

Tuttavia, lo srotolamento manuale del ciclo in generale è in gran parte un artefatto della storia. È un'altra della lista crescente di cose che un buon compilatore farà per te quando è importante. Ad esempio, la maggior parte delle persone non si preoccupa di scrivere x <<= 1o x += xinvece di x *= 2. Devi solo scrivere x *= 2e il compilatore lo ottimizzerà per te al meglio.

Fondamentalmente c'è sempre meno bisogno di indovinare il tuo compilatore.

Indipendentemente dalla previsione del ramo sull'hardware moderno, la maggior parte dei compilatori esegue comunque lo srotolamento del ciclo per te.

Sarebbe utile scoprire quante ottimizzazioni fa per te il tuo compilatore.

Ho trovato la presentazione di Felix von Leitner molto illuminante sull'argomento. Ti consiglio di leggerlo. Riepilogo: i compilatori moderni sono MOLTO intelligenti, quindi le ottimizzazioni manuali non sono quasi mai efficaci.

Per quanto ne so, i compilatori moderni già srotolano i loop dove appropriato - un esempio è gcc, se vengono passati i flag di ottimizzazione, il manuale dice che:

Svolgi loop il cui numero di iterazioni può essere determinato in fase di compilazione o all'ingresso nel loop.

Quindi, in pratica, è probabile che il tuo compilatore faccia i casi banali per te. Sta a te quindi assicurarti che il maggior numero possibile dei tuoi cicli sia facile per il compilatore determinare quante iterazioni saranno necessarie.

Lo srotolamento del loop, che si tratti di srotolamento manuale o di compilazione, può spesso essere controproducente, in particolare con le CPU x86 più recenti (Core 2, Core i7). In conclusione: confronta il tuo codice con e senza loop srotolato su qualunque CPU prevedi di distribuire questo codice.

Provare senza sapere non è il modo per farlo.
Questo tipo richiede un'alta percentuale di tempo complessivo?

Tutto ciò che fa lo srotolamento del ciclo è ridurre il sovraccarico del ciclo di incremento / decremento, confronto per la condizione di arresto e salto. Se quello che stai facendo nel ciclo richiede più cicli di istruzione rispetto al sovraccarico del ciclo stesso, non vedrai molti miglioramenti in percentuale.

Ecco un esempio di come ottenere le massime prestazioni.

Lo srotolamento del loop può essere utile in casi specifici. L'unico vantaggio non è saltare alcuni test!

Ad esempio, può consentire la sostituzione scalare, l'inserimento efficiente del prefetch del software ... Saresti sorpreso di quanto possa essere utile (puoi facilmente ottenere il 10% di velocità sulla maggior parte dei loop anche con -O3) srotolando in modo aggressivo.

Come è stato detto prima, però, dipende molto dal ciclo e il compilatore e l'esperimento sono necessari. È difficile stabilire una regola (o l'euristica del compilatore per lo srotolamento sarebbe perfetta)

Lo svolgimento del ciclo dipende interamente dalla dimensione del problema. Dipende interamente dalla capacità del tuo algoritmo di ridurre le dimensioni in gruppi di lavoro più piccoli. Quello che hai fatto sopra non sembra così. Non sono sicuro che una simulazione di Monte Carlo possa essere srotolata.

Un buon scenario per lo svolgimento del ciclo sarebbe la rotazione di un'immagine. Dal momento che potresti ruotare gruppi di lavoro separati. Per farlo funzionare, dovresti ridurre il numero di iterazioni.

Lo srotolamento del ciclo è ancora utile se ci sono molte variabili locali sia dentro che con il ciclo. Per riutilizzare di più quei registri invece di salvarne uno per l'indice del ciclo.

Nel tuo esempio, usi una piccola quantità di variabili locali, senza esagerare con i registri.

Anche il confronto (alla fine del ciclo) è un grave inconveniente se il confronto è pesante (cioè nontest istruzioni), specialmente se dipende da una funzione esterna.

Lo srotolamento del loop aiuta anche ad aumentare la consapevolezza della CPU per la previsione dei rami, ma si verificano comunque.