Perché GCC non ottimizza a * a * a * a * a * a a (a * a * a) * (a * a * a)?

Sto facendo qualche ottimizzazione numerica su un'applicazione scientifica. Una cosa che ho notato è che GCC ottimizzerà la chiamata pow(a,2)compilandola a*a, ma la chiamata pow(a,6)non è ottimizzata e chiamerà effettivamente la funzione di libreria pow, che rallenta notevolmente le prestazioni. (Al contrario, il compilatore Intel C ++ , eseguibile icc, eliminerà la richiesta della libreria pow(a,6).)

Ciò di cui sono curioso è che quando ho sostituito pow(a,6)con l' a*a*a*a*a*autilizzo di GCC 4.5.1 e le opzioni " -O3 -lm -funroll-loops -msse4", utilizza 5 mulsdistruzioni:

movapd  %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13

mentre se scrivo (a*a*a)*(a*a*a), produrrà

movapd  %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm13, %xmm13

che riduce il numero di istruzioni di moltiplicazione a 3. iccha un comportamento simile.

Perché i compilatori non riconoscono questo trucco di ottimizzazione?

Perché la matematica a virgola mobile non è associativa . Il modo in cui raggruppate gli operandi nella moltiplicazione in virgola mobile ha un effetto sull'accuratezza numerica della risposta.

Di conseguenza, la maggior parte dei compilatori è molto prudente riguardo al riordino dei calcoli in virgola mobile a meno che non possano essere sicuri che la risposta rimanga invariata o a meno che non dite loro che non vi interessa l'accuratezza numerica. Ad esempio: l' -fassociative-mathopzione di gcc che consente a gcc di riassociare le operazioni in virgola mobile, o anche l' -ffast-mathopzione che consente compromessi ancora più aggressivi di precisione rispetto alla velocità.

Lambdageek sottolinea correttamente che, poiché l'associatività non vale per i numeri in virgola mobile, l '"ottimizzazione" dia*a*a*a*a*ato(a*a*a)*(a*a*a)può modificare il valore. Questo è il motivo per cui è vietato da C99 (a meno che non sia espressamente consentito dall'utente, tramite flag di compilazione o pragma). Generalmente, il presupposto è che il programmatore abbia scritto ciò che ha fatto per una ragione, e il compilatore dovrebbe rispettarlo. Se vuoi(a*a*a)*(a*a*a), scrivilo.

Questo può essere un dolore da scrivere, però; perché il compilatore non può semplicemente fare ciò che consideri giusto quando lo usi pow(a,6)? Perché sarebbe la cosa sbagliata da fare. Su una piattaforma con una buona libreria matematica, pow(a,6)è significativamente più preciso di uno a*a*a*a*a*ao (a*a*a)*(a*a*a). Solo per fornire alcuni dati, ho eseguito un piccolo esperimento sul mio Mac Pro, misurando l'errore peggiore nel valutare un ^ 6 per tutti i numeri fluttuanti a precisione singola tra [1,2):

worst relative error using    powf(a, 6.f): 5.96e-08
worst relative error using (a*a*a)*(a*a*a): 2.94e-07
worst relative error using     a*a*a*a*a*a: 2.58e-07

L'uso powinvece di un albero di moltiplicazione riduce l'errore associato di un fattore 4 . I compilatori non dovrebbero (e in genere non lo fanno) fare "ottimizzazioni" che aumentano l'errore a meno che non siano autorizzati dall'utente a farlo (ad es. Via -ffast-math).

Si noti che GCC fornisce __builtin_powi(x,n)un'alternativa a pow( ), che dovrebbe generare un albero di moltiplicazione in linea. Usalo se vuoi compromettere la precisione per le prestazioni, ma non vuoi abilitare la matematica veloce.

Un altro caso simile: maggior parte dei compilatori non sarà ottimizzare a + b + c + da (a + b) + (c + d)(questo è un'ottimizzazione a partire dalla seconda espressione può essere pipeline meglio) e valutare come data (cioè come (((a + b) + c) + d)). Anche questo è dovuto a casi angolari:

float a = 1e35, b = 1e-5, c = -1e35, d = 1e-5;
printf("%e %e\n", a + b + c + d, (a + b) + (c + d));

Questo produce 1.000000e-05 0.000000e+00

Fortran (progettato per il calcolo scientifico) ha un operatore di potenza integrato e, per quanto ne so, i compilatori di Fortran ottimizzano comunemente l'innalzamento a potenze intere in modo simile a quello che descrivi. C / C ++ purtroppo non ha un operatore di potenza, solo la funzione di libreria pow(). Ciò non impedisce ai compilatori intelligenti di trattare in modo powspeciale e di elaborarlo in modo più rapido per casi speciali, ma sembra che lo facciano meno comunemente ...

Alcuni anni fa stavo cercando di rendere più conveniente il calcolo di potenze intere in modo ottimale, e ho trovato quanto segue. È C ++, non C, e dipende ancora dal fatto che il compilatore sia in qualche modo intelligente su come ottimizzare / incorporare le cose. Comunque, spero che potresti trovarlo utile in pratica:

template<unsigned N> struct power_impl;

template<unsigned N> struct power_impl {
    template<typename T>
    static T calc(const T &x) {
        if (N%2 == 0)
            return power_impl<N/2>::calc(x*x);
        else if (N%3 == 0)
            return power_impl<N/3>::calc(x*x*x);
        return power_impl<N-1>::calc(x)*x;
    }
};

template<> struct power_impl<0> {
    template<typename T>
    static T calc(const T &) { return 1; }
};

template<unsigned N, typename T>
inline T power(const T &x) {
    return power_impl<N>::calc(x);
}

_{Chiarimento per i curiosi: questo non trova il modo ottimale per calcolare i poteri, ma dal momento che trovare la soluzione ottimale è un problema NP-completo e questo vale la pena fare comunque solo per piccoli poteri (al contrario dell'uso pow), non c'è motivo di agitarsi con il dettaglio.}

Quindi usalo come power<6>(a).

Ciò semplifica la digitazione dei poteri (non è necessario precisare 6 as con parentesi) e consente di avere questo tipo di ottimizzazione senza -ffast-mathnel caso in cui si abbia qualcosa che dipende dalla precisione come la somma compensata (un esempio in cui l'ordine delle operazioni è essenziale) .

Probabilmente puoi anche dimenticare che questo è C ++ e usarlo nel programma C (se si compila con un compilatore C ++).

Spero che questo possa essere utile.

MODIFICARE:

Questo è ciò che ottengo dal mio compilatore:

Per a*a*a*a*a*a,

    movapd  %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0

Per (a*a*a)*(a*a*a),

    movapd  %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm0, %xmm0

Per power<6>(a),

    mulsd   %xmm0, %xmm0
    movapd  %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
    mulsd   %xmm0, %xmm1

GCC realtà non ottimizzare a*a*a*a*a*aper (a*a*a)*(a*a*a)quando a è un numero intero. Ho provato con questo comando:

$ echo 'int f(int x) { return x*x*x*x*x*x; }' | gcc -o - -O2 -S -masm=intel -x c -

Ci sono molte bandiere gcc ma niente di speciale. Significano: leggi da stdin; utilizzare il livello di ottimizzazione O2; elenco delle lingue dell'assembly di output anziché binario; l'elenco deve utilizzare la sintassi del linguaggio assembly Intel; l'input è in linguaggio C (di solito il linguaggio viene dedotto dall'estensione del file di input, ma non c'è estensione del file durante la lettura da stdin); e scrivi a stdout.

Ecco la parte importante dell'output. L'ho annotato con alcuni commenti che indicano cosa sta succedendo nella lingua dell'assembly:

; x is in edi to begin with.  eax will be used as a temporary register.
mov  eax, edi  ; temp = x
imul eax, edi  ; temp = x * temp
imul eax, edi  ; temp = x * temp
imul eax, eax  ; temp = temp * temp

Sto usando il sistema GCC su Linux Mint 16 Petra, un derivato di Ubuntu. Ecco la versione di gcc:

$ gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1

Come hanno notato altri poster, questa opzione non è possibile in virgola mobile, poiché l'aritmetica in virgola mobile non è associativa.

Perché un numero a virgola mobile a 32 bit, ad esempio 1.024, non è 1.024. In un computer, 1.024 è un intervallo: da (1.024-e) a (1.024 + e), dove "e" rappresenta un errore. Alcune persone non riescono a rendersene conto e credono anche che * in a * a rappresenti la moltiplicazione di numeri di precisione arbitraria senza che vi siano errori associati a tali numeri. Il motivo per cui alcune persone non riescono a rendersene conto sono forse i calcoli matematici che hanno esercitato nelle scuole elementari: lavorare solo con numeri ideali senza errori associati e credere che sia OK ignorare semplicemente "e" durante l'esecuzione della moltiplicazione. Non vedono la "e" implicita in "float a = 1.2", "a * a * a" e codici C simili.

Se la maggior parte dei programmatori dovesse riconoscere (ed essere in grado di eseguire) l'idea che l'espressione C a * a * a * a * a * a non stia effettivamente lavorando con numeri ideali, il compilatore GCC sarebbe quindi LIBERO per ottimizzare "a * a * a * a * a * a "in dire" t = (a * a); t * t * t "che richiede un numero minore di moltiplicazioni. Ma sfortunatamente, il compilatore GCC non sa se il programmatore che scrive il codice pensa che "a" sia un numero con o senza errore. E così GCC farà solo quello che sembra il codice sorgente - perché è quello che vede GCC a occhio nudo.

... una volta che sai che tipo di programmatore sei , puoi usare l'interruttore "-ffast-math" per dire a GCC che "Ehi, GCC, so cosa sto facendo!". Ciò consentirà a GCC di convertire un * a * a * a * a * a in un diverso testo - sembra diverso da un * a * a * a * a * a - ma calcola comunque un numero nell'intervallo di errore di a * a * a * a * a * a. Va bene, dato che sai già che stai lavorando con intervalli, non con numeri ideali.

Nessun poster ha ancora menzionato la contrazione delle espressioni fluttuanti (standard ISO C, 6.5p8 e 7.12.2). Se il FP_CONTRACTpragma è impostato su ON, al compilatore è consentito considerare un'espressione a*a*a*a*a*acome una singola operazione, come se fosse valutata esattamente con un singolo arrotondamento. Ad esempio, un compilatore può sostituirlo con una funzione di alimentazione interna che è sia più veloce che più accurata. Ciò è particolarmente interessante in quanto il comportamento è parzialmente controllato dal programmatore direttamente nel codice sorgente, mentre le opzioni del compilatore fornite dall'utente finale possono talvolta essere utilizzate in modo errato.

Lo stato predefinito del FP_CONTRACTpragma è definito dall'implementazione, in modo che un compilatore possa eseguire tali ottimizzazioni per impostazione predefinita. Pertanto, il codice portatile che deve seguire rigorosamente le regole IEEE 754 dovrebbe impostarlo esplicitamente su OFF.

Se un compilatore non supporta questo pragma, deve essere prudente evitando tale ottimizzazione, nel caso in cui lo sviluppatore abbia scelto di impostarlo su OFF.

GCC non supporta questo pragma, ma con le opzioni predefinite, presuppone che sia ON; quindi per gli obiettivi con un FMA hardware, se si desidera impedire la trasformazione a*b+cin fma (a, b, c), è necessario fornire un'opzione come -ffp-contract=off(per impostare esplicitamente il pragma su OFF) o -std=c99(per dire a GCC di conformarsi ad alcuni Versione standard C, qui C99, quindi seguire il paragrafo precedente). In passato, quest'ultima opzione non impediva la trasformazione, il che significa che GCC non era conforme su questo punto: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845

Come ha sottolineato Lambdageek, la moltiplicazione float non è associativa e puoi ottenere meno accuratezza, ma anche quando ottieni una maggiore precisione puoi contestare l'ottimizzazione, perché vuoi un'applicazione deterministica. Ad esempio nella simulazione di gioco client / server, in cui ogni client deve simulare lo stesso mondo in cui si desidera che i calcoli in virgola mobile siano deterministici.

Le funzioni di libreria come "pow" sono di solito realizzate con cura per produrre il minimo errore possibile (nel caso generico). Questo di solito si ottiene approssimando le funzioni con le spline (secondo il commento di Pascal l'implementazione più comune sembra usare l' algoritmo Remez )

fondamentalmente la seguente operazione:

pow(x,y);

ha un errore intrinseco approssimativamente della stessa entità dell'errore in ogni singola moltiplicazione o divisione .

Durante la seguente operazione:

float a=someValue;
float b=a*a*a*a*a*a;

ha un errore intrinseco che è maggiore di oltre 5 volte l'errore di una singola moltiplicazione o divisione (perché si stanno combinando 5 moltiplicazioni).

Il compilatore dovrebbe essere molto attento al tipo di ottimizzazione che sta facendo:

1. se l'ottimizzazione pow(a,6)di a*a*a*a*a*aesso può migliorare le prestazioni, ma riducono drasticamente la precisione di numeri in virgola mobile.
2. se l'ottimizzazione a*a*a*a*a*a di pow(a,6)esso può effettivamente ridurre la precisione perché "a" è stata un valore speciale che permette la moltiplicazione senza errori (una potenza di 2 o qualche piccolo numero intero)
3. se l'ottimizzazione pow(a,6)di (a*a*a)*(a*a*a)o (a*a)*(a*a)*(a*a)c'è ancora può essere una perdita di precisione rispetto alla powfunzione.

In generale, sai che per valori in virgola mobile arbitrari "pow" ha una precisione maggiore rispetto a qualsiasi funzione che potresti eventualmente scrivere, ma in alcuni casi speciali moltiplicazioni multiple possono avere una precisione e prestazioni migliori, spetta allo sviluppatore scegliere ciò che è più appropriato, eventualmente commentando il codice in modo che nessun altro "ottimizzasse" quel codice.

L'unica cosa che ha senso (opinione personale, e apparentemente una scelta in GCC senza alcuna particolare ottimizzazione o flag del compilatore) da ottimizzare dovrebbe essere la sostituzione di "pow (a, 2)" con "a * a". Sarebbe l'unica cosa sensata che un venditore di compilatori dovrebbe fare.

Non mi sarei aspettato che questo caso fosse ottimizzato. Non può essere molto spesso dove un'espressione contiene sottoespressioni che possono essere raggruppate per rimuovere intere operazioni. Mi aspetto che gli autori di compilatori investano il loro tempo in aree che avrebbero maggiori probabilità di portare a notevoli miglioramenti, piuttosto che coprire un caso limite riscontrato di rado.

Sono stato sorpreso di apprendere dalle altre risposte che questa espressione poteva davvero essere ottimizzata con gli switch del compilatore appropriati. O l'ottimizzazione è banale, oppure è un caso limite di un'ottimizzazione molto più comune, oppure gli autori del compilatore sono stati estremamente accurati.

Non c'è niente di sbagliato nel fornire suggerimenti al compilatore come hai fatto qui. È una parte normale e attesa del processo di micro-ottimizzazione per riorganizzare le dichiarazioni e le espressioni per vedere quali differenze porteranno.

Sebbene il compilatore possa essere giustificato nel considerare le due espressioni per fornire risultati incoerenti (senza gli interruttori appropriati), non è necessario che tu sia vincolato da tale restrizione. La differenza sarà incredibilmente minuscola, al punto che se la differenza conta per te, non dovresti usare l'aritmetica in virgola mobile standard in primo luogo.

Ci sono già alcune buone risposte a questa domanda, ma per completezza ho voluto sottolineare che la sezione applicabile della norma C è 5.1.2.2.3 / 15 (che è la stessa sezione 1.9 / 9 nella Standard C ++ 11). Questa sezione afferma che gli operatori possono essere raggruppati solo se sono realmente associativi o commutativi.

gcc attualmente può fare questa ottimizzazione, anche per numeri in virgola mobile. Per esempio,

double foo(double a) {
  return a*a*a*a*a*a;
}

diventa

foo(double):
    mulsd   %xmm0, %xmm0
    movapd  %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
    mulsd   %xmm1, %xmm0
    ret

con -O -funsafe-math-optimizations. Questo riordino viola IEEE-754, tuttavia, quindi richiede la bandiera.

I numeri interi firmati, come ha sottolineato Peter Cordes in un commento, possono eseguire questa ottimizzazione senza -funsafe-math-optimizationspoiché mantengono esattamente quando non c'è overflow e se c'è overflow si ottiene un comportamento indefinito. Quindi ottieni

foo(long):
    movq    %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rax, %rax
    ret

con solo -O. Per numeri interi senza segno, è ancora più semplice poiché funzionano con potenze mod di 2 e quindi possono essere riordinati liberamente anche in caso di overflow.