Barrapunto

CPI*I*Tc
donde:
CPI=Ciclos por instrucción (inversa de IPC)
I=Número de instrucciones del programa
Tc=Tiempo de ciclo (Inversa de los Hz)

El problema es que el CPI puede variar mucho dependiendo de cada programa. Y las empresas, en caso de facilitar ese dato, solo facilitan la cota optimista (que lógicamente no es significativa).

La memoria no va tan rápida como el procesador. Éste leería una palabra en un sólo ciclo, teóricamente, pero la memoria puede necesitar dos o más (depende) para tener listo el dato en el bus correspondiente. Otro tanto pasa con la escritura. Para acelerar esto se usan las caches, con lo cual lo hace todo menos predecible con precisión.
Bueno, tengo entendido que en procesadores modernos más de un 90% son aciertos en cache. No obstante, la memoria y su bus son muy influyentes no hay duda.

La pipeline son los diferentes estados en que están las instrucciones. En un procesador moderno se termina de ejecutar una instrucción (o más, depende) por cada ciclo de reloj, pero una instrucción individual puede tardar varios ciclos, por lo que siempre hay varias instrucciones simultáneas en diferente fase de ejecución, cuando se produce una bifurcación de la ejecución, la pipeline hay que vaciarla y hasta que no está llena no vuelve a 'coger velocidad'. Para minimizar esto hay varias estrategias conocidas como predicción de salto.
Si, por lo que se la predicción dinamica también funciona muy bien, los saltos debidos a los bucles ya no deberian ser problema, los if dependiendo de las veces que se ejecuten supongo.

Hay más consideraciones a tener en cuenta, como la eficiencia de las extensiones (mmx, se, 3dnow, altivec, etc.) y cómo se integran en el core del procesador. Pero no quiero extenderme más. Y tambien si lo que hace es una multiplicación o una suma...
De todas formas, esa formula que he escrito es la elemental y lo que queria demostrar es que la velocidad de ejecución no depende de un solo parámetro.
El fallo ha sido mio por meterlo todo en el saco de los CPI/IPC.

Saludos