tempi di esecuzione di una istruzione elementare per una CPU

[Marcoxxx]

Sono piuttosto "out of date" sull'argomento.
Qualcuno sa quale e' il tempo per una istruzione in oggetto (ad esempio
per eseguire una somma tra interi) per un PC attuale di medie capacita'
(diciamo frequenza di clock 2-3 Ghz, Ram 4-8 Gb) ?

Quando mi sono laureato io si diceva che era dell'ordine di 10 alla -7
secondi ma all'epoca una buona macchina aveva 64-128 MB di RAM e non
ricordo quale fosse la frequenza di clock (probabilmente non si arrivava
a 1 Ghz).


Avevo trovato questa cosa in rete


https://www.mat.unical.it/didattica/clinfor/IntrInfoWeb/materiale_didattico/lucidi_teoria/Lezione5.pdf

che parla di tempi di accesso alla RAM di 10 nanosecondi o 1 nanosecondo
per l'accesso in cache per cui
mi verrebbe da dire che, considerando il fetch di due parametri piu'
l'esecuzione dell'operazione i tempi dovrebbero essere dell'ordine
delle poche decine di nanosecondi, quindi dell'ordine di 10 alla -8.

Pero' il pdf di cui sopra pare essere del 2006-2007 (e non so nemmeno se
i contenuti fossero aggiornati per l'epoca). Oggi non so quali
siano i tempi di riferimento. E non so nemmeno se in qualche modo
il tempo di esecuzione possa essere influenzato dall'architettura
multiprocessore (per la singola operazione elementare direi di no, ma
non saprei con certezza).


Ciao,
Marco

[enoquick]

Li istruzioni si misurano in clock, cioe quanti clock ci vogliono per
eseguire una istruzione presa cosi da sola
Nei processori moderni che usano le pipeline interne poi i tempi della
singola istruzione e relativo rispetto alle prestazioni
Questo perchè il tempo dipende dalla sequenza delle istruzioni eseguite

[enoquick]

Dimenticavo:

http://en.wikipedia.org/wiki/Instructions_per_second


Qui puoi farti una idea

[MS64]

Se stiamo parlando di tempo di elaborazione di una singola istruzione
aggiungo che dipende anche da dove si trovano le istruzioni e dalla
lunghezza del pipeline.

Il tempo di servizio di un'istruzione (che e' il parametro target sulle
cpu moderne) si misura in frazioni di cicli ci clock :)

[enoquick]

Certamente

> Il tempo di servizio di un'istruzione (che e' il parametro target sulle
> cpu moderne) si misura in frazioni di cicli ci clock :)

Quello è un trucco
La cpu non puo eseguire istruzioni in meno di un ciclo di clock
Ma grazie alle pipeline questo trucco è fattibile

http://it.wikipedia.org/wiki/Istruzioni_Per_Ciclo

[Marcoxxx]

>
> Se stiamo parlando di tempo di elaborazione di una singola istruzione
> aggiungo che dipende anche da dove si trovano le istruzioni e dalla
> lunghezza del pipeline.

supponiamo un'istruzione di addizione tra due interi che si trova in RAM
(sia l'istruzione che gli operandi). quindi fetch dell'iustruzione (e
degli operandi), eventuale decodifica dell'istruzione e sua esecuzione.

Non so esattamente come funziona la pipeline ma immagino che se anche il
fetch dei due operandi potesse essere contemporaneo e anche ammettendo
che i tempi di decodifica ed esecuzione dell'istruzione
siano trascurabili
(magari ammettendo che il risultato possa restare nei registri senza
dover essere scritto in RAM) si dovrebbe avere che almeno un paio di
accessi in RAM sono necessari (almeno uno per il fetch dell'istruzione e
uno per il fetch degli operandi, [ammesso che sia possible prenderli
entrambi con un solo fetch]).
Ora nel documento che avevo linkato io, il tempo per un fetch in RAM
veniva dato pari a 10 nanosecondi, come ordine di grandezza. Quindi il
tempo per due fetch dovrebbe essere ancora dell'ordine dei 10
nanosecondi, come ordine di grandezza.

Pero' non so se questi tempi di accesso (10 nanosecondi) siano
attendibili per le CPU/RAM attuali.

> Il tempo di servizio di un'istruzione (che e' il parametro target sulle
> cpu moderne) si misura in frazioni di cicli ci clock :)

posso anche capirlo, ma mi sa che e' vero se si hanno 10 milioni di
istruzioni da eseguire;
se le parallelizzi, magari mediamente in un unico ciclo di clock esegui
piu' di una istruzione, pero' se hai una sola istruzione da eseguire,
mi sa che in meno di un ciclo di clock non esegui niente (*).
Poi mi sa che se devi fare un accesso in RAM per prendere un parametro
un ciclo di clock non basta.

In ogni caso se devo prendere un dato in RAM per eseguirci
sopra delle elaborazioni devo sapere quale e' il tempo di accesso alla RAM.

Poi puo' darsi che non sia molto significativo per valutare
l'architettura della macchina, come dice enoquick ma magari puo' esserlo
per valutare la bonta' della RAM, almeno immagino che sia ancora cosi'.
E credo che anche la velocita' della pura esecuzione
dell'operazione (senza considerare il fetch e la decodifica) abbia un
peso, perche' se la/le CPU sono in grado di eseguire l'operazione
a 10 picosecondi magari i 10 milioni di operazioni parallele
riesco a terminarli prima che non nel caso in cui l'esecuzione avvenga
in 100 picosecondi (va beh, si puo' sempre dire che e' piu' facile
aumentare di 10 volte il grado di parallelismo che non diminuire
di 10 volte il tempo di esecuzione della singola istruzione, non lo
so.).

Ciao,
Marco.

(*)anzi, ai miei tempi si diceva che se il tempo di propagazione
del segnale di clock a tutte le componenti dell'architettura non e'
trascurabile rispetto al periodo di clock, praticamente non funziona
niente, perche' operazioni che teoricamente dovrebbero essere
contemporanee in corrispondenza dell'arrivo del segnale di clock
sarebbero in realta' "sfasate" nel tempo. E per dimensioni
caratteristiche dei transistor dell'ordine dei micron [che erano
le dimensioni della base dei transistor dell'epoca] si diceva che
gia' frequenze di 1 Ghz potevano dar luogo a problemi di questo
tipo. Se oggi esistono clock a 3-4 Ghz, probabilmente significa che
sono anche diminuite le dimensioni caratteristiche dei transistor
[immagino che oggi la lunghezza della base di un transistor non
sia piu' di 1 micron ma che sia di decine o al massimo centinaia di
nanometri, ma anche su questo non sono aggiornato. Tra l'altro per
dimensioni cosi ridotte potrebbero non essere trascurabili effetti
quantistici come l'effetto tunnel.

[MS64]

On 22/12/2014 21:43, Marcoxxx wrote:
> (magari ammettendo che il risultato possa restare nei registri senza
> dover essere scritto in RAM) si dovrebbe avere che almeno un paio di
> accessi in RAM sono necessari (almeno uno per il fetch dell'istruzione e
> uno per il fetch degli operandi, [ammesso che sia possible prenderli
> entrambi con un solo fetch]).

Le cpu hanno la cache che viene riempita a blocchi. Con cache vuota
avrai due fault di cache (una istruzioni e una dati) che domineranno il
tempo di completamento.

>
>> Il tempo di servizio di un'istruzione (che e' il parametro target sulle
>> cpu moderne) si misura in frazioni di cicli ci clock :)
>
> posso anche capirlo, ma mi sa che e' vero se si hanno 10 milioni di
> istruzioni da eseguire;
> se le parallelizzi, magari mediamente in un unico ciclo di clock esegui
> piu' di una istruzione, pero' se hai una sola istruzione da eseguire,
> mi sa che in meno di un ciclo di clock non esegui niente (*).

Il tempo di servizio di una singola istruzione e' dato dal tempo di
servizio massimo tra tutti gli stadi del pipeline. Le architetture
superscalari portano avanti piu' istruzioni in parallelo e questo e' il
motivo per cui puoi avere tempo di servizio inferiore al ciclo di clock.

Usando come forma di parallelismo il solo pipeline non scenderesti
comunque sono i due cicli di clock (per via del protocollo di
comunicazione tra gli stadi).