Newsgroup: it.comp.hardware.cpu
Titolo: Pipeline di qualsivoglia lunghezza?

L'Athlon ha un pipeline (con gli interi) a 12 stadi. Il Northwood a 20. Il
Prescott a 31.
Le pipeline di un processore si possono allungare quanto si vuole o c'è un
limite allo "spezzettamento" delle istruzioni?
MaxArt

 ha scritto nel messaggio
news:2u06mbF...@uni-berlin.de...

Se non vuoi che la cpu "collassi" su se stessa ci deve essere un limite
all'aumento di profondità di pipeline...;-))

 limite all'aumento di profondità di pipeline...;-))
Ehm, di che collasso parli? ^__^
Mi chiedevo appunto da cosa dipende questo limite.
MaxArt


con le semplificazioni del caso dico che: l'impostazione della pipeline
parte da un numero di stadi pari ad uno e arriva al punto in cui non c'e piu
convenienza
questo ti fa pensare che la la lunghezza della catena di istruzioni trova un
limite in se stessa: c'e un rapporto benefici/lunghezza_pipeline che e tende
a diventare nullo (e addirittura negativo) all'auementare nel numero di
stadi
ad esempio due limiti (di carattere generale) si presentano all'allungamento
della pipeline (poi ve ne sono un altra miriade di carattere piu specifico):
l'aumento della latenza di ogni singola istruzione (essa cresce al crescere
della pipeline) e l'impossibilita di diminiuire oltre un certo valore il clk
(e influenzato dal ritardo degli elementi di memoria per ogni stadio di
pipeline e sfasamento del clk)


Già, senza contare che ci vorrebbero anche delle unità di branching
estremamente
"raffinate" per fare in modo di riuscire a prevedere nel miglior modo
possibile le diramazioni che subirebbe il codice con delle pipeline
troppo lunghe... ihmo già avere 31 stadi come nel Prescott è una cosa
assurda; almeno scalasse bene in frequenza (i 4GHz previsti all'inizio
infatti se li sognano questo giro).


La regola fondamentale e' che se devi implementare un unita funzionale
(che sia un ALU o un decoder delle istruzioni non importa)
che ad una frequenza di lavoro X esegue un istruzione ogni N cicli
di clock, la puoi spezzare in N sotto-unita in pipeline da 1 ciclo
di clock per operazione.
La cosa ha naturalmente un costo in termine di complessita
e numero di componenti elementari necessari, sia perche
bisogna aggiungere qualcosa che interconnetta e sincronizzi
le varie unita, sia perche l'unita ad N cicli poteva
memorizzare e rielaborare "risultati parziali" che nella
struttura ad N sotto-unita vanno rappresentati/implementati
in modo diverso.
Se ad un certo punto anche salendo di frequenza hai tutti
elementi che operano in un singolo ciclo di clock non ha
piu senso spezzettare la struttura (anche perche non sapresti
dove farlo).
Quindi la risposta alla tua domanda e' che il limite e' la mancanza
di elementi da "velocizzare" o la mancanza di risorse libere sul
chip per implementare la versione "migliorata".
Questo ovviamente se si mantiene la stessa "struttura generale"
del sistema e ci si limita a scomporlo in sotto-pipeline, se
si attua una "ristrutturazione globale" si riparte da capo.
Nota anche che all'inizio ho scritto "se devi implementare", non
"se hai gia implementato", ad esempio nei K8 sono stati aggiunti
stadi di pipeline rispetto ai K7 perche altrimenti
il "decoder migliorato" che si voleva implementare al posto
di quello dei K7 avrebbe richiesto piu cicli per operazione
se fosse stato implementato come un unico stadio "migliorato".
L. Micheletto

 ha scritto nel messaggio
news:25Oed.56679$H11.1...@twister1.libero.it...

Bel post. Aggiungo una piccola postilla. Aumentando gli stadi aumentano i
transistor, ma aumenta anche la superficie del die dedicata alla logica. I
gruppi di transistor più critici, più caldi, possono essere divisi e
allontanati tra loro migliorando la dissipazione del calore. E' la densita
di calore generata che ha spinto Intel a passare ai 31 stadi di Prescott,
altrimenti sarebbe rimasta ai 20 stadi del Northwood, optando per un
semplice shrink, magari con solo la cache L1-2 raddoppiata. Purtroppo, per i
tecnici Intel responsabili dello sviluppo del P4, questo non ha comportato
miglioramenti pratici sostanziali, dovuto al fatto che il processo
produttivo a 90 nm e i successivi non permettono (non permetteranno) di
tirare troppo la frequenza di commutazione dei singoli transistor oltre i
propri normali limiti strutturali, pena una eccessiva produzione di calore
per singolo transistor. I transistor con nodo a 90 nm (con un gate lenght di
45-50 nm, rispettivamente per i 2 transistor NMOS e PMOS, che formano il
singolo transistor CMOS) funzionano bene a 2 Ghz, oltre si parla sempre di
overclock, più o meno leggero. I processori che rispettano o superano di
poco questo limite funzionano senza problemi (vedi Dothan 2, 2.1, 2.13 Ghz e
il futuro Montecito 1.8-2 Ghz), gli altri avranno sempre più problemi a
salire di frequenza passando a processi produttivi più miniaturizzati.
Morale: rispettare il processo produttivo, senza "stuprarlo" in nome della
concorrenza, per dichiarare frequenze più elevate. Il futuro processo
produttivo a 65 nm permetterà frequenze di circa 2.7-2.9 Ghz senza
particolari problemi, con una stima di oltre 5 Ghz per il 32 nm.

 ...
Grazie mille a tutti delle risposte.
L'idea della domanda mi era venuta in mente ripensando ai nomi dei vari
stadi della pipeline, tipo Fetch 1 e Fetch 2... mi chiedevo quale fosse il
limite di questo spezzettamento!
MaxArt