C'è un suggerimento per il compilatore per GCC di forzare la predizione dei rami ad andare sempre in un certo modo?

Per le architetture Intel, esiste un modo per istruire il compilatore GCC a generare codice che imponga sempre la previsione dei rami in un modo particolare nel mio codice? L'hardware Intel supporta anche questo? E gli altri compilatori o hardware?

Lo userei nel codice C ++ dove conosco il caso in cui desidero correre velocemente e non mi interessa il rallentamento quando è necessario prendere l'altro ramo anche quando ha recentemente preso quel ramo.

for (;;) {
  if (normal) { // How to tell compiler to always branch predict true value?
    doSomethingNormal();
  } else {
    exceptionalCase();
  }
}

Come domanda successiva per Evdzhan Mustafa, il suggerimento può semplicemente specificare un suggerimento per la prima volta che il processore incontra l'istruzione, tutte le successive predizione dei rami, funzionando normalmente?

A partire da C ++ 20, gli attributi probabile e improbabile dovrebbero essere standardizzati e sono già supportati in g ++ 9 . Quindi, come discusso qui , puoi scrivere

if (a>b) {
  /* code you expect to run often */
  [[likely]] /* last statement */
}

ad esempio nel codice seguente il blocco else viene inline grazie al [[unlikely]]blocco if

int oftendone( int a, int b );
int rarelydone( int a, int b );
int finaltrafo( int );

int divides( int number, int prime ) {
  int almostreturnvalue;
  if ( ( number % prime ) == 0 ) {
    auto k                         = rarelydone( number, prime );
    auto l                         = rarelydone( number, k );
    [[unlikely]] almostreturnvalue = rarelydone( k, l );
  } else {
    auto a            = oftendone( number, prime );
    almostreturnvalue = oftendone( a, a );
  }
  return finaltrafo( almostreturnvalue );
}

collegamento godbolt che confronta la presenza / assenza dell'attributo

GCC supporta la funzione __builtin_expect(long exp, long c)per fornire questo tipo di funzionalità. Puoi controllare la documentazione qui .

Dov'è expla condizione utilizzata ed cè il valore atteso. Ad esempio nel tuo caso vorresti

if (__builtin_expect(normal, 1))

A causa della sintassi scomoda, questo viene solitamente utilizzato definendo due macro personalizzate come

#define likely(x)    __builtin_expect (!!(x), 1)
#define unlikely(x)  __builtin_expect (!!(x), 0)

solo per facilitare il compito.

Ricorda che:

1. questo non è standard
2. un predittore di ramo compilatore / cpu è probabilmente più abile di te nel decidere cose del genere quindi questa potrebbe essere una microottimizzazione prematura

gcc ha long __builtin_expect (long exp, long c) ( enfasi mia ):

È possibile utilizzare __builtin_expect per fornire al compilatore le informazioni sulla previsione dei rami. In generale, dovresti preferire utilizzare il feedback del profilo effettivo per questo (-fprofile-arcs), poiché i programmatori sono notoriamente pessimi nel prevedere come funzionano effettivamente i loro programmi . Tuttavia, ci sono applicazioni in cui questi dati sono difficili da raccogliere.

Il valore restituito è il valore di exp, che dovrebbe essere un'espressione integrale. La semantica dell'integrato è che ci si aspetta che exp == c. Per esempio:

if (__builtin_expect (x, 0))
   foo ();

indica che non ci aspettiamo di chiamare foo, poiché ci aspettiamo che x sia zero. Poiché sei limitato alle espressioni integrali per exp, dovresti usare costruzioni come

if (__builtin_expect (ptr != NULL, 1))
   foo (*ptr);

durante il test di puntatori o valori a virgola mobile.

Come osserva la documentazione, dovresti preferire utilizzare il feedback del profilo effettivo e questo articolo mostra un esempio pratico di questo e come nel loro caso almeno finisce per essere un miglioramento rispetto all'uso __builtin_expect. Vedi anche Come utilizzare le ottimizzazioni guidate dal profilo in g ++? .

Possiamo anche trovare un articolo per i neofiti del kernel Linux sulle macro kernal probabili () e improbabili () che utilizzano questa caratteristica:

#define likely(x)       __builtin_expect(!!(x), 1)
#define unlikely(x)     __builtin_expect(!!(x), 0)

Nota l' !!usato nella macro, possiamo trovare la spiegazione in Perché usare !! (condizione) invece di (condizione)? .

Solo perché questa tecnica è usata nel kernel Linux non significa che abbia sempre senso usarla. Possiamo vedere da questa domanda che ho recentemente risposto alla differenza tra le prestazioni della funzione quando si passa il parametro come costante di tempo di compilazione o variabile che molte tecniche di ottimizzazione manuale non funzionano nel caso generale. Abbiamo bisogno di profilare il codice con attenzione per capire se una tecnica è efficace. Molte vecchie tecniche potrebbero non essere nemmeno rilevanti con le moderne ottimizzazioni del compilatore.

Nota, sebbene i builtin non siano portabili, clang supporta anche __builtin_expect .

Anche su alcune architetture potrebbe non fare la differenza .

No non c'è. (Almeno sui moderni processori x86.)

__builtin_expectmenzionato in altre risposte influenza il modo in cui gcc organizza il codice assembly. Non influenza direttamente il predittore di ramo della CPU. Naturalmente, ci saranno effetti indiretti sulla previsione dei rami causati dal riordino del codice. Ma sui moderni processori x86 non ci sono istruzioni che dica alla CPU "presumere che questo ramo sia / non sia preso".

Vedere questa domanda per maggiori dettagli: Intel x86 0x2E / 0x3E Prefix Branch Prediction effettivamente utilizzato?

Per essere chiari, __builtin_expecte / o l'uso di -fprofile-arcs può migliorare le prestazioni del tuo codice, sia dando suggerimenti al predittore di ramo attraverso il layout del codice (vedi Ottimizzazione delle prestazioni dell'assembly x86-64 - Allineamento e previsione dei rami ), sia migliorando anche il comportamento della cache mantenendo il codice "improbabile" lontano dal codice "probabile".

Il modo corretto per definire le macro probabili / improbabili in C ++ 11 è il seguente:

#define LIKELY(condition) __builtin_expect(static_cast<bool>(condition), 1)
#define UNLIKELY(condition) __builtin_expect(static_cast<bool>(condition), 0)

Questo metodo è compatibile con tutte le versioni C ++, a differenza [[likely]], ma si basa su un'estensione non standard __builtin_expect.

Quando queste macro vengono definite in questo modo:

#define LIKELY(condition) __builtin_expect(!!(condition), 1)

Ciò potrebbe cambiare il significato delle ifdichiarazioni e rompere il codice. Considera il codice seguente:

#include <iostream>

struct A
{
    explicit operator bool() const { return true; }
    operator int() const { return 0; }
};

#define LIKELY(condition) __builtin_expect((condition), 1)

int main() {
    A a;
    if(a)
        std::cout << "if(a) is true\n";
    if(LIKELY(a))
        std::cout << "if(LIKELY(a)) is true\n";
    else
        std::cout << "if(LIKELY(a)) is false\n";
}

E la sua uscita:

if(a) is true
if(LIKELY(a)) is false

Come puoi vedere, la definizione di LIKELY using !!as a cast boolrompe la semantica di if.

Il punto qui non è quello operator int()e operator bool()dovrebbe essere correlato. Che è una buona pratica.

Piuttosto che usare !!(x)invece di static_cast<bool>(x)perdere il contesto per le conversioni contestuali C ++ 11 .

Come le altre risposte hanno tutte adeguatamente suggerito, puoi usare __builtin_expectper dare al compilatore un suggerimento su come organizzare il codice dell'assembly. Come sottolineano i documenti ufficiali , nella maggior parte dei casi, l'assemblatore integrato nel tuo cervello non sarà buono come quello creato dal team di GCC. È sempre meglio utilizzare i dati del profilo effettivo per ottimizzare il codice, piuttosto che indovinare.

Lungo linee simili, ma non ancora menzionate, è un modo specifico di GCC per forzare il compilatore a generare codice su un percorso "freddo". Ciò implica l'uso degli attributi noinlinee cold, che fanno esattamente quello che suonano come fanno. Questi attributi possono essere applicati solo alle funzioni, ma con C ++ 11 è possibile dichiarare funzioni lambda inline e questi due attributi possono essere applicati anche alle funzioni lambda.

Anche se questo rientra ancora nella categoria generale di una microottimizzazione, e quindi si applica il consiglio standard - test non indovinare - penso che sia più generalmente utile di __builtin_expect. Quasi nessuna generazione del processore x86 utilizza i suggerimenti di previsione dei rami ( riferimento ), quindi l'unica cosa che sarai in grado di influenzare comunque è l'ordine del codice assembly. Dato che sai cos'è il codice di gestione degli errori o "caso limite", puoi usare questa annotazione per assicurarti che il compilatore non preveda mai un ramo ad esso e lo colleghi lontano dal codice "caldo" durante l'ottimizzazione per le dimensioni.

Utilizzo del campione:

void FooTheBar(void* pFoo)
{
    if (pFoo == nullptr)
    {
        // Oh no! A null pointer is an error, but maybe this is a public-facing
        // function, so we have to be prepared for anything. Yet, we don't want
        // the error-handling code to fill up the instruction cache, so we will
        // force it out-of-line and onto a "cold" path.
        [&]() __attribute__((noinline,cold)) {
            HandleError(...);
        }();
    }

    // Do normal stuff
    ⋮
}

Ancora meglio, GCC lo ignorerà automaticamente a favore del feedback del profilo quando è disponibile (ad esempio, durante la compilazione con -fprofile-use).

Consulta la documentazione ufficiale qui: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

__builtin_expect può essere usato per dire al compilatore in che direzione ti aspetti che vada un ramo. Questo può influenzare il modo in cui viene generato il codice. I processori tipici eseguono il codice più velocemente in sequenza. Quindi se scrivi

if (__builtin_expect (x == 0, 0)) ++count;
if (__builtin_expect (y == 0, 0)) ++count;
if (__builtin_expect (z == 0, 0)) ++count;

il compilatore genererà codice come

if (x == 0) goto if1;
back1: if (y == 0) goto if2;
back2: if (z == 0) goto if3;
back3: ;
...
if1: ++count; goto back1;
if2: ++count; goto back2;
if3: ++count; goto back3;

Se il tuo suggerimento è corretto, questo eseguirà il codice senza alcun ramo effettivamente eseguito. Verrà eseguito più velocemente della sequenza normale, in cui ogni istruzione if si ramificherà attorno al codice condizionale ed eseguirà tre rami.

I processori x86 più recenti hanno istruzioni per i rami che dovrebbero essere presi, o per i rami che dovrebbero non essere presi (c'è un prefisso di istruzione; non sono sicuro dei dettagli). Non sono sicuro che il processore lo usi. Non è molto utile, perché la previsione dei rami lo gestirà perfettamente. Quindi non penso che tu possa effettivamente influenzare la previsione del ramo .

Per quanto riguarda l'OP, no, non c'è modo in GCC di dire al processore di presumere sempre che il ramo sia o non sia preso. Quello che hai è __builtin_expect, che fa quello che dicono gli altri. Inoltre, penso che tu non voglia dire al processore se il ramo è preso o meno sempre . I processori odierni, come l'architettura Intel, possono riconoscere modelli abbastanza complessi e adattarsi in modo efficace.

Tuttavia, ci sono volte in cui vuoi assumere il controllo se per impostazione predefinita un ramo è previsto o meno: quando sai il codice verrà chiamato "freddo" rispetto alle statistiche di ramificazione.

Un esempio concreto: il codice di gestione delle eccezioni. Per definizione il codice di gestione avverrà eccezionalmente, ma forse quando si verifica si desidera il massimo delle prestazioni (potrebbe esserci un errore critico da togliere il prima possibile), quindi potresti voler controllare la previsione predefinita.

Un altro esempio: puoi classificare il tuo input e saltare nel codice che gestisce il risultato della tua classificazione. Se ci sono molte classificazioni, il processore può raccogliere statistiche ma perderle perché la stessa classificazione non avviene abbastanza presto e le risorse di previsione sono dedicate al codice chiamato di recente. Vorrei che ci fosse una primitiva per dire al processore "per favore non dedicare risorse di previsione a questo codice" nel modo in cui a volte puoi dire "non memorizzare nella cache".