Conseils de prédiction de branchement portable

Question

Existe-t-il un moyen portable de faire des conseils de prédiction de branchement? Prenons l'exemple suivant:

if (unlikely_condition) { 
    /* ..A.. */ 
    } else { 
    /* ..B.. */ 
    } 

Est-ce différent que de le faire:

if (!unlikely_condition) { 
    /* ..B.. */ 
    } else { 
    /* ..A.. */ 
    } 

Ou est la seule façon d'utiliser des notes spécifiques du compilateur? (par exemple __builtin_expect on GCC)

Les compilateurs traiteront-ils les conditions if différemment en fonction de l'ordre des conditions?

Answer 1

La forme canonique pour faire une prédiction de branchement statique est que if est prédits non ramifié (par exemple toutes les clauses if est exécutée, non else), et boucles et en arrière-goto s sont prises. Donc, ne mettez pas le cas courant dans else si vous prévoyez une prédiction statique significative. Se déplacer dans une boucle inachevée n'est pas aussi facile. Je n'ai jamais essayé, mais je suppose que mettre une clause else devrait fonctionner de manière assez portable.

De nombreux compilateurs prennent en charge une forme de , mais il sera toujours nécessaire de le protéger avec une sorte de #if pour protéger les autres compilateurs.

Les conseils de prédiction de branchement peuvent théoriquement exprimer une description complète de la transformation du graphe de contrôle de flux d'un programme et organiser les blocs de base dans la mémoire exécutable ... il y a donc une variété de choses à exprimer .

Comme le recommande GNU dans la documentation de __builtin_expect, l'optimisation guidée par le profil est supérieure aux conseils et avec moins d'effort.

Answer 2

Soyez cohérent avec ce que vous faites. J'aime utiliser

if (!(someExpression)) 

Mais le compilateur devrait traiter cela également.

Answer 3

L'optimisation est intrinsèquement une chose de compilateur, vous devez donc utiliser la fonctionnalité du compilateur pour l'aider. Le langage lui-même ne se soucie pas (ou mandat) des optimisations.

Alors le mieux que vous pouvez faire sans extensions spécifiques au compilateur est organiser votre code de telle sorte que vos compilateurs vont "faire le bon choix" sans aide. Mais si vous voulez être sûr, tapez sur les extensions du compilateur. (Vous pouvez essayer les abstraire derrière le préprocesseur, de sorte que votre code reste portable.)

Answer 4

Dans la plupart des cas, le code suivant

if (a) 
{ 
    ... 
} 
else 
{ 
    ... 
} 

est en fait

evaluate(A) 

if (!A) 
{ 
    jmp p1 
} 

... code A 

    jmp p2 

p1: 

... code !A 

p2: 

Notez que si A est vrai, "code A" est déjà en cours. Le processeur verra la commande "jmp p2" en avant, et chargera le code p2 dans le pipeline.

Si A est faux, le "code! A" peut ne pas être dans le pipleline, donc il peut être plus lent.

Conclusions:

1. do Si (X) si X est plus probable que X
2. d'essayer d'évaluer un plus tôt possible, afin que la CPU peut dynmically optimiser le pipeline!.

:

evaluate(A) 

do more stuff 

if (A) 
    ... 

Answer 5

Quel est le problème avec la vérification d'un compilateur spécifique via #ifdef et cacher ces choses derrière une macro personnalisée? Vous pouvez #define pour étendre à l'expression simple dans les cas où vous n'avez pas un compilateur qui prend en charge ces conseils d'optimisation. J'ai récemment fait quelque chose de similaire avec des préfixes de cache explicites que GCC supporte via une fonction intrinsèque.