[HACK] Microprocessors, pipelines and clock speeds

[Jesus Cea]

David A. Pérez wrote:
> Supongamos que las otras 4 etapas tardan 2ns, y ahora hemos conseguido
> segmentar la ALU en otras 3 etapas. Tenemos 7 etapas, 6 de las cuales
> son de 2ns y otra de 1ns. Tendriamos que la velocidad maxima serian
> 500 MHz (1/2ns). Lo cual no implica que las instrucciones se ejecuten
> mas rapido porque a pesar de que el reloj va mas rapido, tenemos mas
> etapas (no estoy teniendo en cuenta los registros entre etapas para
> simplificar).

Cada instrucción individual tarda lo mismo, pero usando "pipelining" se 
tienen varias instrucciones simultaneas en ejecución.

> Si no me equivoco, lo ideal seria que todas las etapas duraran lo
> mismo, asi que segumimos segmentando y las 6 etapas de 2ns las
> convertimos en 12 etapas de 1ns, mas la otra que teniamos tenemos 13
> etapas de 1ns. Velocidad? 1 Ghz (otra vez, teoricamente, soy
> consciente de que no estamos teniendo en cuenta muchos otros
> factores).

Correcto. En un mundo ideal, es así.

En la práctica influjen muchos otros factores, como el consumo de 
energía, la "sobrecarga" que implica la segmentación, las ineficiencias 
debido a los saltos en la ejecución de código y en la velocidad de 
acceso a la memoria, interdependencia entre instrucciones, etc.

En teoría, se podrían usar infinitos segmentos, pero dado que cada 
segmento impone una sobrecarga, y que los lenguajes de programación 
actuales no exponen suficiente paralelismo para llenar una "pipeline" 
"larga", una "pipeline" excesivamente larga es contraproducente.

> Segun tu ejemplo, partiamos de 5 etapas, la ALU necesitaba 5 ns, las
> otras 2ns (mi ejemplo), total 5ns+(4x2ns) = 13ns. Ahora tenemos 13
> etapas de 1ns, seguimos necesitando 13 ns para ejecutar la
> instruccion. Y no estoy afirmando... pregunto, es correcto elo
> planteamiento?

Teóricamente sí. En la práctica, tener 13 etapas no supondría 1 ns por 
etapa sino, debido a la sobrecarga, digamos que 1.2 ns por etapa. 
Además, el consumo de energía se multiplica casi por tres (al igual que 
el rendimiento). Por último, si la operación en un segmento invalida los 
anteriores (por ejemplo, hay un cambio de flujo), en vez de perder el 
trabajo de 4 etapas, perdemos el de 12, por ejemplo.

> Lo cual puede producir una perdida de rendimiento si el branch
> prediction unit se equivoca no?

En las CPUs actuales, y con los lenguajes de programación "normales", la 
predicción de saltos tiene una importancia crítica. Y cuantas más 
"pipelines" haya, más importante es, porque el trabajo "perdido" en una 
equivocación es mucho mayor.

Por eso un Pentium 4 tiene un predictor de saltos mucho más avanzado que 
un PowerPC. No porque en Intel sean más listos, sino que PowerPC no 
necesita invertir recursos en esa area de su CPU para obtener unos 
resultados "comparables".

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                       _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz