Quale codice è migliore per l'ottimizzazione della previsione delle filiali?

Question

Quale codice è migliore per l'ottimizzazione della previsione delle filiali?

#1 da (9 voti)
#2 da (9 voti)

10

Considerata la previsione dei rami e anche l'effetto delle ottimizzazioni del compilatore, quale codice tende ad offrire prestazioni superiori?

Si noti che bRareExceptionPresent rappresenta una condizione non comune. Non è il normale percorso della logica.

/* MOST COMMON path must branch around IF clause */

bool SomeFunction(bool bRareExceptionPresent)
{
  // abort before function
  if(bRareExceptionPresent)
  {
     return false;
  }    
  .. function primary body ..    
  return true;
}

/* MOST COMMON path does NOT branch */

bool SomeFunction(bool bRareExceptionPresent)
{
  if(!bRareExceptionPresent)
  {
    .. function primary body ..
  }
  else
  {
    return false;
  }
  return true;
}

theory optimization

posta dyasta 24.04.2013 - 17:48

fonte

2 risposte

9

La mia comprensione è che la prima volta che la CPU incontra un ramo, si prevede (se supportato) che le diramazioni non vengano prese e che i rami all'indietro siano. La logica per questo è che i loop (che tipicamente si diramano all'indietro) sono presupposti per essere presi.

Su alcuni processori, puoi dare un suggerimento nelle istruzioni di assemblaggio su quale sia il percorso più probabile. Dettagli di questo mi sfuggono al momento.

Inoltre, alcuni compilatori C supportano anche la previsione del ramo statico in modo da poter dire al compilatore quale ramo è più probabile. A sua volta può riorganizzare il codice generato, o usare le istruzioni modificate per sfruttare questa informazione (o anche solo pian piano ignorarlo).

__builtin_expect((long)!!(x), 1L)  /* GNU C to indicate that <x> will likely be TRUE */
__builtin_expect((long)!!(x), 0L)  /* GNU C to indicate that <x> will likely be FALSE */

Spero che questo aiuti.

risposta data 24.04.2013 - 19:05

fonte

Leggi altre domande sui tag theory optimization

Perché il compilatore di Scala non può fornire un avviso di corrispondenza del modello per classi / tratti non sigillati? Documentazione del codice: pubblico vs non pubblico?

score 9 · Accepted Answer

Nel mondo di oggi, non importa molto, se non del tutto.

Predizione di ramo dinamico (qualcosa di cui si è pensato per decenni (vedi Un'analisi dei carichi di lavoro del sistema di previsione dinamica dei modelli Schemaon pubblicata nel 1996)) è un luogo abbastanza comune.

Un esempio di questo può essere trovato nel processore ARM. Dal Centro informazioni arm su Previsione filiale

To improve the branch prediction accuracy, a combination of static and dynamic techniques is employed.

La domanda quindi è "qual è la previsione del ramo dinamico nel processore del braccio?" La lettura costante di previsione dinamica delle filiali mostra che utilizza uno schema di predizione a 2 bit (descritto nel documento) per creare informazioni su se il ramo è preso o meno con decisione o meno.

Nel tempo (e per tempo intendo alcuni passaggi attraverso quel blocco) questo costruisce informazioni sul modo in cui il codice andrà.

Per la previsione statica , sembra il modo in cui il codice guarda se stesso e in che modo il ramo viene eseguito sul test - con un'istruzione precedente o uno ulteriore nel codice:

The scheme used in the ARM1136JF-S processor predicts that all forward conditional branches are not taken and all backward branches are taken. Around 65% of all branches are preceded by enough non-branch cycles to be completely predicted.

Come accennato da Sparky, questo si basa sulla comprensione di loop più spesso, loop. Il loop si dirama all'indietro (ha un ramo alla fine del loop per riavviarlo in alto) - normalmente lo fa.

Il pericolo di provare a indovinare il compilatore è che non si sa come tale codice verrà effettivamente compilato (e ottimizzato). E per la maggior parte, non importa. Con la previsione dinamica, due volte attraverso la funzione si prevede di saltare l'istruzione guardia per un ritorno prematuro. Se le prestazioni di due condotte a filo sono di prestazioni critiche, ci sono altre cose di cui preoccuparsi.

Il tempo necessario per leggere uno stile piuttosto che altro è probabilmente di maggiore importanza - rendere il codice pulito in modo che un essere umano possa leggerlo, perché il compilatore sta andando a fare bene, non importa quanto sia disordinato o idealizzato scrivere il codice .