Como dice la gente, ciclos por instrucción. Lo que ocurre es que es una cifra de mérito de una microarquitectura al ejecutar una carga de trabajo concreta. No es apropiado hablar de IPC sin hablar también del programa que lo consigue.
Un valor pequeño de IPC es bueno, y en consecuencia muchos ingenieros de rendimiento prefieren usar "IPC" o instrucciones por ciclo. Un gran IPC es bueno.
El IPC se calcula tomando el número total de instrucciones ejecutadas (medido por los contadores de rendimiento como el linux perf o PAPI o el VTune de Intel o similares) dividido por el número total de ciclos tomados. Debido a que las velocidades de reloj varían de vez en cuando hay que tener cuidado de utilizar también los relojes de referencia, en lugar del reloj del núcleo, a menos que también se explique lo que se está haciendo.
Este sencillo cálculo incluye tanto el tipo de cosas que se ejecutan muy rápido, como la aritmética de registro a registro (¿IPC de quizás 4 o más en un chip moderno?) y cosas que se ejecutan muy lentamente, como las pérdidas de caché que tardan 150 ciclos en resolverse.
No se puede comparar muy bien el IPC de diferentes arquitecturas de conjuntos de instrucciones porque las instrucciones en una pueden hacer más trabajo por instrucción que en otra. El IPC también oculta todo tipo de cosas interesantes, como el uso de instrucciones vectoriales para hacer 16 veces el trabajo pero que sólo cuentan como una instrucción.
En consecuencia, el IPC sólo es una comparación de manzana a manzana cuando se ejecuta el mismo programa con los mismos conjuntos de datos en diferentes implementaciones de la misma arquitectura. Así, puede ocurrir que un Intel Skylake consiga 1,7 de IPC en algún programa pero un Kaby Lake consiga 1,9 . Las mejoras se deben a las mejoras microarquitectónicas, no al compilador ni al programador.
Puesto así, se empieza a ver por qué quizá el IPC y el IPC no son muy buenas métricas. Si un nuevo modelo de chip permite nuevas optimizaciones del compilador, quizá pueda ejecutar el mismo programa en muchas menos instrucciones, aunque el IPC sea peor. La computación es una empresa cooperativa entre el hardware, los compiladores y los programadores, y el IPC sólo mira una pata, y ni siquiera toda, porque no puede tener en cuenta, por ejemplo, las nuevas instrucciones.
Aún así, si tienes un programa, puedes mirar un IPC de 0,5 y pensar: "eso apesta". Al escarbar en los datos de rendimiento y mirar las declaraciones calientes, podrías descubrir que tienes un montón de pérdidas de caché causadas por una estructura de datos pobre. Arreglando eso, tal vez el IPC sea 1, que realmente, es bastante decente. Así que a veces, algo de experiencia con los IPCs logrados por diferentes programas con diferentes configuraciones del compilador, puedes reconocer un valor atípico y escarbar en las razones para ello. Cuando esto sucede, el IPC era útil en el sentido de que te hacía preguntarte si podías acelerar el código. Para los arquitectos de chips, el valor del IPC es que puedes identificar una clase de aplicaciones que tienen un IPC bajo, lo que te lleva a indagar en lo que están haciendo, lo que te lleva a algunas ideas de arquitectura para hacer que toda una clase de programas se ejecute más rápido. De nuevo, no son los valores exactos, sino los valores atípicos los que son interesantes.