Comme on dit, cycles par instruction. Le truc, c'est que c'est un chiffre de mérite pour une microarchitecture lorsqu'elle exécute une charge de travail particulière. Il n'est pas approprié de parler de CPI sans parler également du programme qui l'atteint.
Une petite valeur de CPI est bonne, et par conséquent de nombreux ingénieurs de performance préfèrent utiliser "IPC" ou instructions par cycle. Un grand IPC est bon.
L'IPC est calculé en prenant le nombre total d'instructions exécutées (mesuré par les compteurs de performance comme linux perf ou PAPI ou VTune d'Intel ou autre) divisé par le nombre total de cycles pris. Comme les fréquences d'horloge varient de temps en temps, vous devez faire attention à utiliser des horloges de référence également, plutôt que l'horloge centrale, à moins que vous n'expliquiez également ce que vous faites.
Ce calcul simple inclut à la fois les sortes de choses qui s'exécutent très rapidement, comme l'arithmétique registre à registre (IPC de peut-être 4 ou plus sur une puce moderne ?) et les choses qui s'exécutent très lentement, comme les manques de cache qui prennent 150 cycles à résoudre.
On ne peut pas très bien comparer l'IPC de différentes architectures de jeu d'instructions parce que les instructions de l'une peuvent faire plus de travail par instruction que dans une autre. L'IPC cache également toutes sortes de choses intéressantes, comme l'utilisation d'instructions vectorielles pour faire 16x le travail mais ne comptant que pour une seule instruction.
En conséquence, l'IPC n'est une comparaison pomme à pomme que lorsque vous exécutez le même programme avec les mêmes jeux de données sur différentes implémentations de la même architecture. Il peut donc arriver qu'un Intel Skylake atteigne 1,7 IPC sur un certain programme mais qu'un Kaby Lake obtienne 1,9 . Les améliorations sont dues aux améliorations microarchitecturales, pas au compilateur et pas au programmeur.
Plus loin, vous commencez à voir pourquoi peut-être le CPI et l'IPC ne sont pas de très bonnes métriques. Si un nouveau modèle de puce permet de nouvelles optimisations du compilateur, peut-être que je peux exécuter le même programme en beaucoup moins d'instructions, même si l'IPC est moins bon. L'informatique est une entreprise coopérative entre le matériel, les compilateurs et les programmeurs, et l'IPC ne regarde qu'une jambe, et même pas la totalité, car elle ne peut pas prendre en compte, par exemple, de nouvelles instructions.
Pour autant, si vous avez un programme, vous pouvez regarder un IPC de 0,5 et penser "ça craint". En creusant dans les données de performance et en regardant les déclarations chaudes, vous pourriez découvrir que vous avez beaucoup de manques de cache causés par une mauvaise structure de données. En corrigeant cela, l'IPC sera peut-être de 1, ce qui est vraiment très correct. Parfois, avec une certaine expérience des IPC obtenus par différents programmes avec différents paramètres de compilation, vous pouvez reconnaître une valeur aberrante et en chercher les raisons. Lorsque cela se produit, l'IPC est utile dans la mesure où il vous amène à vous demander si vous pouvez accélérer le code. Les chiffres exacts n'étaient pas si utiles, mais le coup de pied dans le pantalon l'était.
Pour les architectes de puces, la valeur de l'IPC est que vous pourriez être en mesure d'identifier une classe d'applications qui ont un faible IPC, ce qui vous conduit à creuser dans ce qu'ils font, ce qui vous conduit à quelques idées architecturales pour rendre toute une classe de programmes plus rapides. Encore une fois, ce ne sont pas les valeurs exactes, mais les valeurs aberrantes qui sont intéressantes.