Come dice la gente, cicli per istruzione. Il fatto è che è una cifra di merito di una microarchitettura quando esegue un particolare carico di lavoro. Non è appropriato parlare di CPI senza parlare anche del programma che lo raggiunge.
Un piccolo valore di CPI è buono, e di conseguenza molti ingegneri delle prestazioni preferiscono usare "IPC" o istruzioni per ciclo. Un grande IPC è buono.
IPC è calcolato prendendo il numero totale di istruzioni eseguite (misurato dai contatori di prestazioni come linux perf o PAPI o VTune di Intel o simili) diviso per il numero totale di cicli impiegati. Poiché le frequenze di clock variano di volta in volta, dovete fare attenzione ad usare anche i clock di riferimento, piuttosto che il core clock, a meno che non spieghiate anche cosa state facendo.
Questo semplice calcolo include sia il tipo di cose che girano molto velocemente, come l'aritmetica da registro a registro (IPC di forse 4 o più su un chip moderno?) e le cose che funzionano molto lentamente, come le missioni di cache che richiedono 150 cicli per essere risolte.
Non si può confrontare molto bene l'IPC di diverse architetture di set di istruzioni perché le istruzioni in una possono fare più lavoro per istruzione che in un'altra. L'IPC nasconde anche ogni sorta di cose interessanti, come l'uso di istruzioni vettoriali per fare 16 volte il lavoro ma che contano solo come un'istruzione.
Di conseguenza, l'IPC è un confronto mela a mela solo quando si esegue lo stesso programma con gli stessi set di dati su diverse implementazioni della stessa architettura. Quindi potrebbe accadere che un Intel Skylake raggiunga 1,7 IPC su qualche programma ma un Kaby Lake ottenga 1,9 . I miglioramenti sono dovuti ai miglioramenti della microarchitettura, non al compilatore e non al programmatore.
Posto in questo modo, si comincia a vedere perché forse CPI e IPC non sono metriche molto buone. Se un nuovo modello di chip permette nuove ottimizzazioni del compilatore, forse posso eseguire lo stesso programma con molte meno istruzioni, anche se l'IPC è peggiore. L'informatica è un'impresa cooperativa tra hardware, compilatori e programmatori, e l'IPC guarda solo una gamba, e nemmeno tutta, perché non può prendere in considerazione, per esempio, nuove istruzioni.
Ancora, se avete un programma, potete guardare un IPC di 0,5 e pensare, "che schifo". Scavando nei dati sulle prestazioni e guardando le dichiarazioni a caldo, potreste capire che avete un sacco di cache miss causate da una struttura dati scadente. Sistemando questo, forse l'IPC sarà 1, che in realtà è abbastanza decente. Così a volte, un po' di esperienza con gli IPC raggiunti da diversi programmi con diverse impostazioni del compilatore, si può riconoscere un outlier e scavarne le ragioni. Quando questo accade, l'IPC è stato utile in quanto ti ha portato a chiederti se potevi accelerare il codice. I numeri esatti non erano così utili, ma il calcio nei pantaloni sì.
Per gli architetti di chip, il valore dell'IPC è che si potrebbe essere in grado di identificare una classe di applicazioni che hanno un IPC basso, il che porta a scavare in quello che stanno facendo, il che porta ad alcune idee architettoniche per rendere un'intera classe di programmi più veloce. Di nuovo, non sono i valori esatti, ma i valori anomali che sono interessanti.