Newsgroup: it.comp.hardware.cpu
Titolo: Pipeline e MHz

Spero di non essere OT in i.c.h.cpu!
Qualcuno ha scritto : "Sarà difficle ihmo se non allungano un altro pò la 
pipeline...magari a 15
stadi" by Lorenz
Ma cosa sono le pipeline e che relazione c'è con i MHz?
Grazie a tutti! 

Mentre ero distratto, attraverso l'orologio K.I.T.T. mi ha avvisato che
Saldo mi ha cercato per dirmi:

Considera le istruzioni come un prodotto tipo un'automobile. Le pipeline
sono la catena di montaggio dell'istruzione.
+ sono lunghe e + è facile salire in frequeza.
Il problema è che quando una parte dell'istruzione (ad esempio istruzione 5)
lascia uno stadio per spostarsi a quello successivo, la parte
dell'istruzione successiva (in memoria, ad esempio la 6) prende il suo
posto. Se l'istruzione è un salto per esempio all'istruzione 12 tutto il
lavoro fatto fino a quel momento per tutte le istruzioni successive
all'attuale va a donnine, perdendo tempo prezioso
*************************************************************
Se la fortuna è cieca, ma tu hai scritto in fronte "sono sfigato" in
braille......
Solo i FESS tengono in ordine.... i GENI vivono nel CAOS!!! (Cattivik)
Solo i cretini sono sicuri al 100% di quello che dicono. Naturalmente potrei
sbagliarmi ...
*************************************************************

Mentre ero distratto, attraverso l'orologio K.I.T.T. mi ha avvisato che
Saldo mi ha cercato per dirmi:
Naturalmente a grandissime linee
*************************************************************
Se la fortuna č cieca, ma tu hai scritto in fronte "sono sfigato" in


 ha scritto nel messaggio
news:q7aed.19873$1q2...@tornado.fastwebnet.it...

Visto che mi hai tirato in ballo rispondo pure io...;-)
Prima di tutto la pipeline, come ha detto Cava la si può considerare
come una sorta di linea di assemblaggio dove l'elaborazione delle istruzioni
viene suddivisa in numerosi "gradini" minori oppure in diversi stadi e
ciascuno di questi viene affidato a un circuito a sé stante. Quando
l'istruzione completa uno stadio passa al successivo e lo stadio che si è
appena liberato inizia l'elaborazione dell'istruzione seguente. Ciascuna
istruzione spesso richiede diversi cicli di clock per giungere a
completamento, ma suddividendo il processo elaborativo in diversi stadi e
iniziando a elaborare il primo stadio della prossima istruzione non appena
quella corrente lo ha completato, si riesce a portare a compimento con
maggiore rapidità un'intera serie di operazioni. Tutto questo fa in modo di
poter salire più facilmente in frequenza maggiori stadi di pipeline vengono
utilizzati (fino ad un certo punto ovviamente).
Però l'avere una pipeline troppo profonda fa si che nel caso le unità
di branching della cpu non riescano a prevedere in anticipo
la direzione che prenderà l'istruzione caricata ad esempio nello stadio
19, bisognerà svuotare l'intera pipeline per poter ricaricare dati
"coerenti"; tutto questo porta via diversi cicli di clock, cicli che saranno
maggiori maggiori saranno gli stadi di pipeline utilizzati.
Tutto questo spiega tra l'altro il motivo per cui ad esempio un Athlon 64
3200+ (che funziona fisicamente a 2GHz e con pipeline da 12 stadi) abbia
delle prestazioni generali simili (e in qualche caso maggiori) rispetto ad
un P4 Prescott funzionante realmente a 3.2GHz (qui le pipeline sono infatti
ben 31).
Spero d'essere stato abbastanza chiaro ;-)


Grazie mille!Chiarissimo! 


Ti ringrazio ma non ho capito molto!Ho un CAOS in testa ma per FORTUNA tu mi 
hai illuminato....ma potrei SBAGLIARMI!
Grazie! :-) 


perdona l'intrusione: sei stato *chia-ri-ssi-mo*!
ti darei un corso di calcolatori elettronici... :-P
none

 maggiori maggiori saranno gli stadi di pipeline utilizzati.
È un po' come prendere una fabbrica della fiat dove fanno la multipla:
ci sono gli operai che montano il motore, quelli che montano le portiere, i 
sedili e così via...
immagina che il dirigente dica "la multipla non si fa' più, ora si fa' la 
panda", tutto il lavoro della catena di montaggio è stato inutile e bisogna 
ricominciare da capo. Quando questo accade (ed accade abbastanza spesso) i 
processori con pipeline più corte (Atlhon) sono favoriti rispetto a quelli 
con pipe più lunghe (P4 in generale).
D'altra parte una pipeline più lunga significa che ogni stadio della 
pipeline stessa può essere completato in meno tempo, e questo è il motivo 
principale per cui si può scalare in frequenza più facilmente. 


Esatto, anche l'esempio "automobilistico" rende bene il concetto...;-)

 principale per cui si può scalare in frequenza più facilmente.
Ma questo come si evidenzia nel processo di produzione di una cpu?
Ovvero, perchè è fisicamente più difficile produrre cpu con pipeline
corta rispetto a cpu con pipeline più lunga per ciò che concerne
l'aumento della frequenza di funzionamento?



per una questione di ritardi del propagazione del segnale di clock nel
circuito.
in una macchina con un singolo stadio esecutivo ogni impulso di clock
-deve- corrispondere al massimo ad una istruzione eseguita (visto che,
appunto, hai un singolo stadio per eseguirle - puoi richiedere piu' di
un ciclo di clock per eseguire una singola istruzione, mai meno) -
l'impulso di clock per attraversare ogni singolo transistor impiega un
certo lasso di tempo, di conseguenza per percorrere l'intera catena di
transistor necessaria ad eseguire una istruzione dal suo caricamento
fino al suo completamento di tempo ce ne vuole parecchio.
spezzando la pipeline esecutiva in tante sottounita' ognuna delle
quali si occupa di una piccolissima frazione dell'intera esecuzione di
una istruzione il tempo minimo che puoi assegnare ad ogni impulso di
clock e' quello di una di queste sottounita' invece di dover aspettare
l'intera pipeline.
se tu dovessi eseguire una singola istruzione non cambierebbe nulla,
ovviamente: invece di impiegare un singolo ciclo di clock -diciamo- da
10 ns ne impiegano venti (ipotizzando una macchina "perfetta" a venti
stadi) da 0,5 ns (in realta' sono di piu', non si ha mai efficienza al
100%, ma per semplicita' fingiamo che cosi' sia).
pero' quando inizi ad avere molte istruzioni in serie ti accorgi che
nel primo caso (singola unita' esecutiva) puoi eseguire -una-
istruzione da 10ns alla volta e devi attendere che sia completamente
conclusa prima di iniziare la seconda, nel secondo caso dopo i primi
0,5ns necessari per far processare l'istruzione al primo "spezzone"
questa istruzione passa al secondo spezzone e puoi gia' caricare la
seconda istruzione nel primo spezzone - e cosi' via.
il risultato e' che per eseguire dieci istruzioni la macchina ad
unita' esecutiva singola impiega 100ns, la macchina a pipeline da
venti stadi impiega 14,5ns.
noti una certa differenza? :)
esaminando un po' piu' approfonditamente le cifre saltano fuori i
problemi di questa soluzione:
14,5ns, con un ciclo di clock da 0,5ns vogliono dire che la prima
istruzione, da quando viene inziata a quando viene portata a termine,
impiega 10ns, le altre 9 le sussieguono ad un ciclo di 0,5ns ciascuna.
se per qualche motivo il ciclo si ferma e la pipeline si vuota vuol
dire che per ritornare "a regime" ti serviranno altri 10ns (20 cicli)
durante i quali non viene -completata- nessuna istruzione.
e questo succede ad ogni branch-miss (ovvero, semplificando, ogni
qualvolta che nelle cache non e' presente il prossimo dato da
elaborare e devi attendere l'accesso alla ram)
quindi piu' lunga e' la pipeline, piu' lungo e' questo tempo di attesa
per il riavvio.
(warning: messaggio in versione beta - oggi sono davvero troppo
distrutto per debuggarlo, domattina lo rileggo con gli occhi meno
appannati e se ci trovo qualche orrore posto la versione aggiornata ;)
-- 
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Il segreto per essere considerato un creativo sta nel non fare
    mai riconoscere le proprie fonti [A. Einstein]

 appannati e se ci trovo qualche orrore posto la versione aggiornata ;)
No, figurati, č una buona pre-release, altro che beta! 
Grazie :)

 appannati e se ci trovo qualche orrore posto la versione aggiornata ;)
Direi che il messaggio č buono, il vero orrore č vedere scritto "messaggio
in versione beta" e "debuggare un messaggio" :-D
MaxArt

 elaborare e devi attendere l'accesso alla ram)
Questo invece non è il branch-miss ma il cache-miss, che è una cosa 
differente.
E comunque un lapsus o un errore dovuto alla stanchezza è umano :)
Ciao! 

 istruzioni)
No, la tecnologia di incisione non c'entra.
I ritardi di propagazione si hanno all'interno di uno stadio perché tutti 
gli stadi lavorano contemporaneamente, e non all'interno della pipeline!
Ti faccio un esempio:
siamo in una fabbrica di panettoni e il lavoro di produzione di un panettone 
si compone di più operazioni: preparare la farina, operare sulle uova, 
impastare ed infornare.
Prendiamo il caso di operare sulle uova: questo è uno stadio.
Ammettiamo che questo stadio richieda 10 minuti di tempo in tutto per essere 
completato.
Possiamo a questo punto dire che "operare sulle uova" è piuttosto generico, 
e quindi immaginiamo di suddivere questo stadio in due, composto dai lavori 
di "rompere le uova" e "sbattere le uova".
Questi nuovi due stadi richiederanno 3 minuti uno e 7 minuti l'altro!
Se metti due persone a lavorare contemporaneamente, una a rompere e l'altra 
a sbattere le uova, avrai che alla fine l'intera operazione ti costa 7 
minuti e non più 10, a patto che quando un panettone è uscito dal forno, ce 
n'è già un altro pronto ad entrarci!
Portando questo esempio nel mondo dei processori:
hai un processore ipotetico ad un solo stadio che impiega un periodo 10 ns 
per completare una istruzione.
La sua frequenza (che è l'opposto del periodo) è 1s/10ns = 100 MHz.
Se suddividi questo stadio in due, uno da 3 ns e l'altro da 7 ns puoi 
intuire che il tempo di completamento per una istruzione ora è di 7 ns e non 
più dieci perché gli stadi lavorano CONTEMPORANEAMENTE e quindi quando lo 
stadio da 3ns ha finito, all'altro stadio mancano altri 4ns per terminare.
A questo punto si può alzare la frequenza da 1s/10ns a 1s/7ns, cioè circa 
140 MHz.
Quei 10, 7 e 3 ns sono i tempi di propagazione dei segnali all'interno dei 
transistor del processore, perché la corrente elettrica ha una velocità 
finita ed i transistor richiedono una quantità di tempo per mutare i loro 
stati. 

 critiche da fabbricare?
Ad ogni stadio della pipeline hai dei latch o circuiteria
equivalente che "risincronizza" i segnali arrivati che al ciclo di clock
successivo verranno passati all'unita seguente nella pipeline.
E' come nel giro d'Italia, ad ogni tappa i ciclisti arrivano al traguardo
in momenti diversi ma alla tappa successiva (il ciclo di clock
successivo nel caso delle pipeline) ripartono tutti insieme.
L. Micheletto

 140 MHz.
Ma in questo tuo esempio il processore ad un singolo stadio sarebbe un
Athlon con pipeline corta: in caso di branch-miss (come da tua
integrazione al post di MM) si svuota l'intera pipeline ma si attende
meno tempo per l'esecuzione dell'istruzione necessaria.
Mentre il processore a due stadi sarebbe un P4, dove l'esecuzione più
rapida di ogni singolo stadio permette di velocizzare il clock globale
della cpu ma dove il numero maggiore degli stadi da svuotare e poi
riempire con le istruzioni corrette si paga in termini di un maggiore
tempo necessario per avere il lavoro finito (sempre in caso di
branch-miss).
Percui ne deduco che gli Athlon faticano a salire in frequenza perchè i
pochi stadi della loro pipeline impiegano singolarmente più tempo per
eseguire le istruzioni mentre il numero superiore di stadi del P4
velocizza l'esecuzione di ogni singolo stadio permettendo velocità di
clock più elevate. Resta inteso che entrambe le soluzioni hanno pro e
contro.
Nel caso fosse il contrario, cosa altamente possibile visto che ho già
confessato che la cosa fatica ad entrare nella mia scatola cranica per
il verso giusto, siete anche legittimati a lasciarmi perdere, non voglio
abusare della vostra pazienza... :)

E comunque un lapsus o un errore dovuto alla stanchezza è umano :)
no, soltanto una semplificazione un po' eccessiva :)


istruzioni)
da un punto strettamente produttivo allungare le pipeline costa
un'enormita', sia in termini di complessita' di progetto sia in
termini di puro e semplice silicio.


in versione beta" e "debuggare un messaggio" :-D
ci volevo anche mettere uno stralcio della lgpl ma non l'avevo sotto
mano {evil grin}


 abusare della vostra pazienza... :)
Figurati, il ng esiste apposta! 

 Hai capito benissimo! Il senso č proprio quello.
Perfetto, grazie a te e a Maurizio Mugelli (che leggo su questo
newsgroup fin dal 1998) l'ho finalmente capita! :)

 impressionante, dopo dodici ore filate di lavoro....
Stacanovista...;))))

 newsgroup fin dal 1998) l'ho finalmente capita! :)
Beh, meglio tardi che mai... ;))

non un messaggetto. 
Su questo perň mi piacerebbe sapere qualcosa in piů... come funziona,
a grandi linee?
E' legato alla supposta architettura VLIW del P-M?
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG#008,DPPSJ#000,BAT#013,TFC#012,GAM#026,ZZZZ#027,CID#027,PAN#015
"Aspettare non č mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffč"