L'utilisation de xor reg, reg donne-t-elle un avantage par rapport à mov reg, 0 ?

Question

Il y a deux façons bien connues de mettre un registre entier à zéro sur x86.

Soit

mov reg, 0

ou

xor reg, reg

Certains pensent que la deuxième variante est meilleure car la valeur 0 n'est pas stockée dans le code, ce qui permet d'économiser plusieurs octets de code machine produit. C'est certainement une bonne chose - moins de cache d'instructions est utilisé et cela peut parfois permettre une exécution plus rapide du code. De nombreux compilateurs produisent ce type de code.

Cependant, il existe officiellement une dépendance inter-instruction entre l'instruction xor et toute instruction antérieure qui modifie le même registre. Comme il y a une dépendance, la dernière instruction doit attendre que la première soit terminée, ce qui peut réduire la charge des unités du processeur et nuire aux performances.

add reg, 17
;do something else with reg here
xor reg, reg

Il est évident que le résultat de xor sera exactement le même quelle que soit la valeur initiale du registre. Mais le processeur est-il capable de le reconnaître ?

J'ai essayé le test suivant en VC++7 :

const int Count = 10 * 1000 * 1000 * 1000;
int _tmain(int argc, _TCHAR* argv[])
{
    int i;
    DWORD start = GetTickCount();
    for( i = 0; i < Count ; i++ ) {
        __asm {
            mov eax, 10
            xor eax, eax
        };
    }
    DWORD diff = GetTickCount() - start;
    start = GetTickCount();
    for( i = 0; i < Count ; i++ ) {
        __asm {
            mov eax, 10
            mov eax, 0
        };
    }
    diff = GetTickCount() - start;
    return 0;
}

Avec les optimisations désactivées, les deux boucles prennent exactement le même temps. Est-ce que cela prouve raisonnablement que le processeur reconnaît qu'il n'y a pas de dépendance de xor reg, reg l'instruction sur l'ancien mov eax, 0 instruction ? Quel pourrait être un meilleur test pour vérifier cela ?

Answer 1

Une vraie réponse pour vous :

Manuel de référence sur l'optimisation des architectures Intel 64 et IA-32

La section 3.5.1.8 est l'endroit où vous devez regarder.

En bref, il y a des situations où un xor ou un mov peut être préféré. Les problèmes concernent les chaînes de dépendance et la préservation des codes de condition.

Answer 2

Le x86 a des instructions de longueur variable. MOV EAX, 0 nécessite un ou deux octets de plus dans l'espace de code que XOR EAX, EAX.

Answer 3

J'ai cessé d'être capable de réparer mes propres voitures après avoir vendu mon break HR de 1966. Je suis dans une situation similaire avec les processeurs modernes :-)

Cela dépendra vraiment du microcode ou du circuit sous-jacent. Il est tout à fait possible que le CPU puisse reconnaître "XOR Rn,Rn" et mettre simplement à zéro tous les bits sans se soucier du contenu. Mais bien sûr, il peut faire la même chose avec un fichier "MOV Rn, 0" . Un bon compilateur choisira de toute façon la meilleure variante pour la plate-forme cible, ce qui ne pose généralement problème que si vous codez en assembleur.

Si le CPU est assez intelligent, votre XOR La dépendance disparaît puisqu'elle connaît la valeur n'est pas pertinente et sera mise à zéro de toute façon (encore une fois, cela dépend de l'unité centrale utilisée).

Cependant, je ne me soucie plus depuis longtemps de quelques octets ou de quelques cycles d'horloge dans mon code - cela ressemble à une micro-optimisation devenue folle.

Answer 4

Je pense que sur les architectures précédentes, le mov eax, 0 prenait un peu plus de temps que l'instruction xor eax, eax également... je ne me souviens pas exactement pourquoi. A moins que vous n'ayez beaucoup plus mov Cependant, j'imagine que vous n'êtes pas susceptible de provoquer des manques dans la mémoire cache en raison de ce seul littéral stocké dans le code.

Notez également que, de mémoire, le statut des drapeaux n'est pas identique entre ces méthodes, mais il se peut que je me souvienne mal de cela.

Answer 5

Vous écrivez un compilateur ?

D'autre part, votre analyse comparative ne fonctionnera probablement pas, puisque vous avez une branche qui prend probablement tout le temps de toute façon. (sauf si votre compilateur déroule la boucle pour vous)

Une autre raison pour laquelle vous ne pouvez pas évaluer une instruction unique dans une boucle est que tout votre code sera mis en cache (contrairement au code réel). Vous avez donc éliminé une grande partie de la différence de taille entre mov eax,0 et xor eax,eax en l'ayant tout le temps dans le cache L1.

Je pense que toute différence de performance mesurable dans le monde réel serait due à la différence de taille qui consomme le cache, et non au temps d'exécution des deux options.