Latence des instructions CPU sur les processeurs x86 et x64

Je recherche un tableau ou quelque chose de similaire qui pourrait m'aider à calculer l'efficacité du code d'assemblage.

Comme je sais, le décalage de bits prend 1 horloge CPU, mais je regarde vraiment combien prend l'addition (la soustraction devrait prendre la même chose), la multiplication et comment calculer vraisemblablement le temps de division si je connais des valeurs qui divisent.

J'ai vraiment besoin d'informations sur les valeurs entières, mais les temps d'exécution flottants sont également les bienvenus.

— ST3
source

Même chose possible sur SO: stackoverflow.com/questions/692718/…

— Ciro Santilli 冠状病毒审查六四事件法轮功

Réponses:

En général, chacune de ces opérations prend également un seul cycle d'horloge à exécuter si les arguments sont dans des registres aux différentes étapes du pipeline.

Qu'entendez-vous par latence? Combien de cycles une opération passe-t-elle dans l'ALU?

Vous pourriez trouver ce tableau utile: http://www.agner.org/optimize/instruction_tables.pdf

Étant donné que les processeurs modernes sont super scalaires et peuvent s'exécuter dans le désordre, vous pouvez souvent obtenir un nombre total d'instructions par cycle supérieur à 1. Les arguments de la macro-commande sont les plus importants, mais l'opération est également importante car les divisions prennent plus de temps que XOR (<1 latence du cycle).

De nombreuses instructions x86 peuvent prendre plusieurs cycles pour terminer certaines étapes si elles sont complexes (commandes REP ou pire MWAIT par exemple).

— Jon Brauer
source

La multiplication des nombres entiers est d'au moins 3c de latence sur tous les CPU x86 récents (et plus élevée sur certains CPU plus anciens). Sur de nombreux processeurs, il est entièrement canalisé, donc le débit est de 1 par horloge, mais vous ne pouvez y parvenir que si vous avez trois multiplications indépendantes en vol. (La multiplication FP sur Haswell est une latence de 5c, un débit de 0,5c, vous avez donc besoin de 10 en vol pour saturer le débit). La division ( divet idiv) est encore pire: elle est microcodée, et la latence est beaucoup plus élevée que addou shr, et n'est même pas entièrement canalisée sur n'importe quel CPU. Tout cela provient directement des tableaux d'instructions d'Agner Fog, c'est donc une bonne chose que vous ayez lié cela.

— Peter Cordes

Voir aussi Pourquoi ce code C ++ est-il plus rapide que mon assemblage manuscrit pour tester la conjecture Collatz? pour en savoir plus sur l'optimisation de asm.

— Peter Cordes

Le calcul de l'efficacité du code d'assemblage n'est pas la meilleure façon de procéder de nos jours avec les pipelines Super Scalar d'exécution hors service. Cela variera selon le type de processeur. Cela variera selon les instructions avant et après (vous pouvez ajouter du code supplémentaire et le faire exécuter plus rapidement parfois!). Certaines opérations (division notamment) peuvent avoir une plage de temps d'exécution même sur des puces plus anciennes et plus prévisibles. En fait, le chronométrage de nombreuses itérations est la seule façon de procéder.

— Brian Knoblauch
source

Je le sais, mais j'en ai besoin non pas dans un vrai projet mais dans un genre un projet de programmation amusant .

— ST3 du

Que vous en ayez besoin pour de vrai ou pour le plaisir ne change pas la réponse pour cette gamme de processeurs. Avez-vous envisagé de passer à un processeur plus déterministe, comme une puce Propeller, à la place?

— Brian Knoblauch

Même avec un scalaire, les erreurs de prédiction de branche d'implémentation dans l'ordre et les échecs de cache peuvent entraîner des variations dans le temps d'exécution.

— Paul A. Clayton

Pour les éléments purement liés au CPU (pas de cache manquant, pas de mauvaise prévision de branche), le comportement du CPU est compris suffisamment en détail pour que l'analyse statique puisse souvent prédire presque exactement combien de cycles par itération une boucle prendra sur un CPU spécifique (par exemple Intel Haswell). Par exemple, voyez cette réponse SO où, en regardant l'asm généré par le compilateur, permettez-moi d'expliquer pourquoi la version branchée a fonctionné presque exactement 1,5 fois plus vite que la version CMOV sur le processeur Sandybridge de l'OP, mais beaucoup plus près sur mon Skylake.

— Peter Cordes

Si vous écrivez asm à la main pour des raisons de performances, il est en fait utile de rechercher les goulots d'étranglement de latence et de débit sur les processeurs Intel et AMD. C'est difficile, cependant, et parfois ce qui est optimal pour AMD n'est pas ce qui est optimal pour Intel.

— Peter Cordes

Vous pouvez trouver des informations sur Intel CPU dans les manuels des développeurs de logiciels Intel . Par exemple, la latence est de 1 cycle pour une addition entière et de 3 cycles pour une multiplication entière.

Je ne connais pas la multiplication, mais je m'attends à ce que l'addition prenne toujours un cycle.

— UmNyobe
source

Un cycle, sauf lorsqu'il est "gratuit" (en parallèle lorsque les pipelines s'alignent correctement) ou prend plus de temps en raison d'un cache manquant. :-)

— Brian Knoblauch

Actuellement (2018), ces informations sont disponibles dans l'annexe C intitulée «Instruction Latency and Throughput» du document 248966 «Intel® 64 and IA-32 Architectures Optimization Reference Manual» également disponible sur la page liée dans la réponse

— stefanct