Capitolo 2 - Siti personali

Transcript

Capitolo 2 - Siti personali
Ap p u n t i d i Ca lco la to ri E lettro nici
C a p i t o l o 2 – L e p r e s t a zi o n i
Introduzione .................................................................................................................. 1
Concetti generali............................................................................................................ 1
Le prestazioni della CPU ................................................................................................ 3
MIPS (milione di istruzioni al secondo) ........................................................................... 5
MFLOPS (milione di operazioni in virgola mobile al secondo) .......................................... 7
Scelta dei programmi per valutare le prestazioni .............................................................. 7
Come porre in relazione le prestazioni............................................................................. 9
Tempo totale di esecuzione ........................................................................................... 10
Tempo pesato di esecuzione .......................................................................................... 10
Tempo di esecuzione normalizzato ................................................................................. 11
Pro e contro della media geometrica ........................................................................... 12
Introduzione
Per i progettisti di calcolatori, così come ad esempio per quelli di automobili, non
esiste un unico obiettivo da raggiungere:
•
ad un estremo, troviamo i progetti ad elevate prestazioni, che non badano
a spese pur di raggiungere il proprio obiettivo (lo stesso accade, ad esempio,
per le Ferrari);
•
all’estremo opposto troviamo invece i progetti a basso costo, dove le
prestazioni vengono sacrificate per raggiungere costi contenuti;
•
una via di mezzo è costituita dai cosiddetti progetti costo/prestazioni, nei
quali il progettista effettua un bilancio appunto tra costi e prestazioni.
Concetti
Concett i generali
Il tempo è la misura delle prestazioni di un calcolatore : questo significa, in
parole povere, che il calcolatore che svolge la stessa quantità di lavoro impiegando il
minor tempo è il più veloce. Due esempi banali sono i seguenti:
•
il tempo di esecuzione di un programma si misura in secondi per
programma;
•
la prestazione viene spesso misurata come il tasso di un certo numero di
eventi per secondo, in modo tale che bassi tempi significano prestazioni più
elevate.
Appunti di “Calcolatori Elettronici” – Capitolo 2
In questi documenti, al posto di usare gli aggettivi “elevato” (per i tassi) oppure
“basso” (per i tempi), parleremo sempre di miglioramento delle prestazioni.
Il tempo può del resto essere definito in vari modi, a seconda di come lo si
conteggia; volendo usare la sua definizione più semplice, parliamo di tempo assoluto
o tempo di risposta o tempo trascorso (elapsed time): esso rappresenta la latenza per
il completamento di un dato lavoro, includendo tutti i fattori necessari per svolgere
tale lavoro, come ad esempio gli accessi a disco, gli accessi a memoria, le attività di
I/O, il sovraccarico dovuto al sistema operativo e altro. Tuttavia, quando ci riferiamo
ad un ambiente di multiprogrammazione, è noto che la CPU si dedica
contemporaneamente a più programmi, che si alternano nel suo utilizzo: ad esempio,
mentre attende le operazioni di I/O per un dato programma, si dedica all’esecuzione
di un altro programma; di conseguenza, il tempo trascorso non necessariamente
risulta minimizzato, il che ci costringe a trovare altri termini più efficaci. Ci viene
incontro, allora, il cosiddetto tempo di CPU, il quale coglie la “distinzione” citata
poco fa, non includendo il tempo di attesa per l’I/O ed il tempo per l’esecuzione di
altri programmi ( 1).
Il tempo di CPU può essere ulteriormente suddiviso in due componenti:
•
tempo utente di CPU: è il tempo di CPU dedicato al programma;
•
tempo CPU di sistema: è il tempo speso dal sistema operativo per effettuare
i compiti richiesti dal programma.
Quest’ultima distinzione si può apprezzare in modo particolarmente intuitivo
tramite un apposito comando previsto dal sistema operativo UNIX: si tratta del
comando “time”, il quale restituisce una sequenza di valori del tipo seguente:
90.7u 12.9s 2:39 65%
Questa sequenza dice che il tempo utente di CPU, per il programma desiderato, è
complessivamente di 90.7 secondi, mentre 12.9 secondi costituiscono il tempo CPU di
sistema; il tempo impiegato dal programma è di 2 minuti e 39 secondi (cioè
159 secondi), mentre invece la percentuale di tale tempo rappresentativa del tempo
di CPU vale
90.7 + 12.9
*100 = 65% . Quindi, poco meno dei 2/3 del tempo totale sono
159
spesi per l’esecuzione del programma in questione, mentre poco più di 1/3 del tempo
è usato per attese legate sia all’I/O sia all’esecuzione di altri programmi.
Segnaliamo, comunque, che molte misure ignorano il tempo CPU di sistema,
sostanzialmente per due motivi:
•
in primo luogo, si è verificato che l’accuratezza con cui il sistema operativo
effettua rilievi su stesso è generalmente molto bassa;
•
in secondo luogo, dato che il tempo CPU di sistema cambia da macchina a
macchina (dato che cambia il codice di sistema), questa misura non è
assolutamente valida per confrontare le prestazioni tra due macchine
diverse.
Tuttavia, a fronte di quest’ultima osservazione c’è da considerare quanto segue: il
codice che su alcune macchine è di sistema, su altre è invece codice utente; dato
allora che i programmi non si possono eseguire senza la presenza di un sistema
1
Ovviamente, dal punto di vista dell’utente, il tempo che conta è il tempo di risposta del programma e non certo il tempo
di CPU; quest’ultimo è invece una buona misura di prestazione per il progettista e/o l’analista.
Autore: Sandro Petrizzelli
2
aggiornamento: 7 luglio 2001
Le prestazioni
operativo in esecuzione sulla macchina, si può comunque pensare di fare una
casistica usando la somma del tempo utente di CPU e del tempo CPU di sistema.
Nei nostri discorsi, manterremo sempre la distinzione tra le prestazioni basate sul
tempo di risposta del programma e prestazioni basate sul tempo di CPU. Non solo, ma
useremo il termine prestazioni del sistema con riferimento ad un sistema non
caricato, mentre invece prestazioni della CPU sono quelle riferite al tempo utente di
CPU.
In questo capitolo, ci concentreremo sulle prestazioni della CPU .
Le prestazioni della CPU
E’ noto che la maggior parte dei calcolatori viene realizzata usando un clock di
frequenza fissa. Tale clock fornisce dunque degli “eventi” che discretizzano il tempo,
ai quali vengono dati svariati nomi: si parla di tick, clock tick, clock, cicli o cicli di
clock. Noi useremo quest’ultima terminologia.
Si può far riferimento alla durata dei cicli di clock sia mediante la loro lunghezza,
detta periodo di clock (ad esempio 10 ns), sia mediante il suo inverso, ossia la
frequenza di clock (ad esempio 100 MHz). In base a questa distinzione, è possibile
esprimere il tempo di CPU per un programma in due modi perfettamente equivalenti:
Tempo di CPU = Cicli di clock della CPU per un programma × Periodo di clock =
Cicli di clock della CPU per un programma
=
frequenza di clock
Oltre al numero dei cicli di clock necessari per eseguire un programma, si può
anche contare il numero di istruzioni eseguite, che prende il nome di conto
istruzioni (brevemente CI). Questo numero, unito al numero di cicli di clock
necessari per l’esecuzione, permette a sua volta di calcolare il numero medio di cicli
di clock per istruzione (brevemente CPI):
CPI =
Cicli di clock della CPU per un programma
Conto istruzioni
In generale, questo è un numero frazionario, dato che numeratore e denominatore
sono numeri interi non necessariamente multiplo uno dell’altro.
Da quest’ultima formula possiamo ricavare due espressioni alternative per il
tempo di CPU: portando infatti a numeratore il conto istruzioni e riprendendo le
precedenti formule per il calcolo del tempo di CPU, otteniamo che
Tempo di CPU = CI × CPI × Periodo di clock =
CI × CPI
frequenza di clock
Possiamo ulteriormente dettagliare queste formule introducendo le unità di
misura: ad esempio, tenendo conto che il CI si misura in istruzioni/programma, che
il CPI si misura in cicli di clock/istruzione e che il periodo di clock si misura in
secondi/ciclo di clock, otteniamo che il tempo di CPU si misura in
secondi/programma:
aggiornamento: 7 luglio 2001
3
Autore: Sandro Petrizzelli
Appunti di “Calcolatori Elettronici” – Capitolo 2
 secondi 
 istruzioni
 cicli di clock
 secondi 
= CI 
× CPI
× Periododi clock
Tempodi CPU




 istruzione 
ciclo di clock
 programma

 programma

Osserviamo dunque che la prestazione della CPU dipende da tre caratteristiche:
•
il periodo di clock (o la frequenza di clock);
•
i cicli di clock per istruzione (CPI);
•
il conto istruzioni (CI).
Non è possibile modificare separatamente una di queste tre caratteristiche, dato
che le tecnologie di base che le riguardano singolarmente sono interdipendenti tra
loro:
•
il periodo di clock
dall’organizzazione;
•
il CPI dipende a sua volta dall’organizzazione ed anche dall’architettura
dell’insieme di istruzioni;
•
il CI dipende infine dall’architettura dell’insieme di istruzioni nonché dalla
tecnologia dei compilatori ( 2).
dipende
sia
dalla
tecnologia
dell’hardware
sia
Talvolta, risulta anche utile calcolare il numero totale di cicli di clock della CPU
ripartendo il numero medio di cicli di clock per ciascuna istruzione del programma:
N
cicli di clock della CPU = ∑ (CPI i × I i )
i =1
In questa formula, il pedice i indica l’ i-esima istruzione del programma in
questione, I i indica il numero di volte che tale istruzione viene eseguita in un
programma, mentre CPI i indica il numero medio di cicli di clock per eseguire
l’istruzione.
Moltiplicando quella formula per il periodo di clock, si ottiene evidentemente
ancora una volta il tempo di CPU:
N
tempo di CPU = ∑ (CPI i × I i ) × periodo di clock
i =1
Se invece dividiamo per il conto istruzioni, otteniamo il CPI:
N
cicli di clock della CPU
CPI =
=
conto istruzioni
∑ (CPI
i =1
i
CI
× Ii )
N
I 

= ∑  CPI i × i 
CI 
i =1 
Con l’ultimo passaggio, abbiamo voluto esprimere il CPI in funzione del tasso di
occorrenza (I i /CI) della generica istruzione nel programma in questione.
2
Ad esempio, una stessa operazione potrebbe essere realizzata tramite un diverso numero di istruzioni su una
macchina rispetto ad un’altra
Autore: Sandro Petrizzelli
4
aggiornamento: 7 luglio 2001
Le prestazioni
In tutto questo discorso, si tenga sempre conto che il pedice i può rappresentare
sia una singola istruzione sia una tipologia di istruzioni sia addirittura un singolo
spezzone del programma.
In generale, si ricordi infine che la misura reale delle prestazioni di un
calcolatore è sempre il tempo , anche perché si tratta dell’unica grandezza
facilmente misurabile (tramite lettura del clock).
MIPS (milione di istruzioni al secondo)
Una ferma convinzione di molti esperti del settore è quella per cui la sola misura
uniforme ed affidabile delle prestazioni di un calcolatore è il tempo di esecuzione di
programmi reali, ossia programmi di utilizzo comune presso gli utenti. Qualunque
proposta alternativa, sia al parametro temporale sia all’uso dei programmi reali come
elementi di misura, è ritenuta poco consona alle esigenze della progettazione dei
calcolatori e/o addirittura foriera di errori nella progettazione stessa. Di seguito
vogliamo allora esaminare le proposte alternative più diffuse ed i pericoli insiti in
esse.
Una prima importante alternativa all’uso del tempo come metro di prestazione è il
cosiddetto MIPS, che sta per milioni di istruzioni al secondo. Per un dato programma,
il MIPS è semplicemente definito nel modo seguente:
MIPS =
Conto istruzioni
Frequenza di clock
=
6
Tempo di esecuzione × 10
CPI × 10 6
Le macchine più veloci sono evidentemente quelle con il MIPS più alto.
E’ subito importante sottolineare che il MIPS dipende strettamente dal programma
usato: infatti, esistono programmi che sfruttano le “parti” più complicate di un
processore ed altri che invece sfruttano solo le funzioni più semplici, per cui il CPI è
legato a tali programmi e quindi varia da uno all’altro.
Tra le due forme alternative del MIPS proposte, la seconda è quella più apprezzata,
dato che la frequenza di clock è fissa per una data macchina ed il CPI è normalmente
un numero piccolo, a differenza di quanto accade invece per il conto istruzioni e/o il
tempo di esecuzione.
Portando il tempo di esecuzione al primo membro ed il MIPS a secondo membro,
si ottiene
Tempo di esecuzione =
Conto istruzioni
MIPS × 10 6
Questa espressione è utile in quanto, essendo il MIPS nient’altro che la frequenza
delle operazioni per unità temporale, le prestazioni delle macchine più veloci (cioè
con MIPS più alto) sono evidenziabili tramite i tempi di esecuzione più bassi.
Il pregio fondamentale del MIPS è che si tratta di una figura di merito facilmente
comprensibile per l’acquirente: quest’ultimo sarà infatti tentato di acquistare la
macchina con il MIPS più alto. A fronte di questo, però, ci sono da considerare tre
problemi fondamentali:
•
il MIPS dipende dall’insieme di istruzioni della macchina, il che rende
difficile confrontare, tramite il MIPS appunto, calcolatori con diversi insiemi
di istruzioni;
aggiornamento: 7 luglio 2001
5
Autore: Sandro Petrizzelli
Appunti di “Calcolatori Elettronici” – Capitolo 2
•
il MIPS può variare, sullo stesso calcolatore, al variare del programma
considerato (perché varia il CI e quindi il CPI): si può perciò avere un MIPS
molto alto per un dato programma ed un MIPS molto più basso per un altro
programma;
•
infine, il MIPS può variare in modo inversamente proporzionale alle
prestazioni, il che rappresenta il principale difetto di questo indice di
prestazione. Un classico esempio per evidenziare questo concetto è quello di
una macchina che possiede hardware opzionale per le operazioni in virgola
mobile: in condizioni normali, le operazioni in virgola mobile hanno bisogno
di più cicli di clock rispetto a quelle che lavorano con numeri interi; di
conseguenza, i programmi usano, per la virgola mobile, non le apposite
routine software, ma l’hardware opzionale, il che garantisce tempi minori di
esecuzione ma anche un MIPS più basso (vengono eseguite meno istruzioni);
al contrario, se le operazioni in virgola mobile vengono effettuate via
software (tramite l’uso di istruzioni semplici), il MIPS sale ma sale anche il
numero di istruzioni da eseguire e anche il tempo di esecuzione.
In base a questi discorsi, si comprende come il MIPS possa non dare una
immagine veritiera delle prestazioni, proprio perché non considera il tempo di
esecuzione. Per compensare questa “debolezza”, si può pensare di introdurre un
MIPS di riferimento, ossia un MIPS calcolato per una particolare macchina di
riferimento, rispetto al quale esprimere il MIPS originario, ossia quello definito prima:
si ottiene così il cosiddetto MIPS relativo, dato da
MIPS relativo =
Tempo riferiment o
× MIPSriferiment o
Tempo non rapportato
In questa espressione, la quantità Tempo riferiment o rappresenta il tempo di esecuzione
di un programma sulla macchina di riferimento, mentre invece Tempo non
rapportato
è il
tempo necessario ad eseguire lo stesso programma sulla macchina da rapportare.
La quantità MIPSriferiment o è invece il MIPS accertato della macchina di riferimento.
Naturalmente, il MIPS relativo considera solo il tempo di esecuzione per un
programma specifico e per un ingresso specifico a tale programma.
Ci sono per lo meno due problemi da considerare a proposito del MIPS relativo:
•
il primo è che risulta comunque difficile trovare una macchina di
riferimento della stessa età di quella da testare ( 3);
•
il secondo consiste poi nel decidere se la macchina più vecchia debba
funzionare con la versione più recente del compilatore e del sistema
operativo oppure se il software debba comunque essere fissato in modo che
la macchina di riferimento non diventi più veloce con il passare del tempo.
Facendo dunque una sintesi di quanto detto, anche il MIPS relativo appare
scarso, in quanto il tempo di esecuzione, il programma ed il suo ingresso devono
comunque essere noti per poter ricavare delle informazioni significative.
3
Negli anni Ottanta, la principale macchina di riferimento fu il VAX 11/780, che fu detta anche macchina da 1 MIPS.
Autore: Sandro Petrizzelli
6
aggiornamento: 7 luglio 2001
Le prestazioni
MFLOPS (milione di operazioni in virgola mobile al
secondo)
Una diffusa alternativa al tempo di esecuzione, per la misura delle prestazioni, è il
cosiddetto MFLOPS (si legge “megaflops”), che sta per “milioni di operazioni in virgola
mobile al secondo”. La formula con cui si calcola questo indice di prestazione non è
altro che la definizione dell’acronimo:
MFLOPS =
Numero di operazioni in virgol a mobile in un programma
Tempo di esecuzione × 10 6
E’ subito evidente che il MFLOPS dipende sia dalla macchina sia dal programma
che si sta usando. Naturalmente, dato che il MFLOPS fa riferimento alle sole
operazioni in virgola mobile, non è applicabile altrove.
A titolo di esempio estremo, citiamo il fatto che ci sono alcuni compilatori che, a
prescindere dalla velocità della macchina su cui vengono eseguiti, hanno un MFLOPS
quasi nullo, dato che usano molto poco le operazioni in virgola mobile.
Il MFLOPS appare più rappresentativo del MIPS: infatti, essendo basato sulle
singole operazioni e non sulle istruzioni, esso può essere teoricamente usato per
confrontare tra loro due o più macchine, partendo dal presupposto che un
programma, funzionando su diverse macchine, può eseguire un diverso numero di
istruzioni, ma compirà sempre lo stesso numero di operazioni in virgola mobile.
Nonostante questo pregio, si manifesta comunque anche un problema: l’insieme
delle operazioni in virgola mobile non è lo stesso in tutte le macchine. Ad esempio, il
calcolatore CRAY-2 non possiede istruzioni di divisione, mentre invece il Motorola
68882 possiede la divisione, la radice quadrata, il seno ed il coseno.
A questo si aggiunge anche il problema per cui il MFLOPS cambia non solo al
variare della mescolanza tra operazioni intere ed operazioni in virgola mobile, ma
anche al variare della mescolanza tra operazioni in virgola mobile “lente” e “veloci”:
ad esempio, un programma con il 100% di addizioni in virgola mobile darà origine ad
un MFLOPS più alto (e quindi migliore) rispetto ad un programma che invece ha il
100% di divisioni in virgola mobile.
Una possibile soluzione ad entrambi questi problemi consiste nel definire un
numero canonico di istruzioni in virgola mobile a livello di programma sorgente ed
usare tale numero per calcolare il MFLOPS, dividendo cioè per il tempo di
esecuzione. Si ottiene in questo caso il cosiddetto MFLOPS normalizzato, che
differisce quindi dal MFLOPS originario (cioè quello definito all’inizio del paragrafo).
Ricordiamo che il MFLOPS, come ogni altra misura di prestazione, è legato al
programma che si sceglie di usare (per cui ha senso parlare solo di MFLOPS per un
dato programma su una data macchina) e quindi non può essere generalizzato al fine
di stabilire una singola misura di prestazione per un calcolatore.
Scelta dei programmi per valutare le prestazioni
Un utente di calcolatori che usa gli stessi programmi ogni giorno potrebbe essere il
candidato perfetto per valutare un nuovo calcolatore: infatti, per valutare un nuovo
sistema, egli dovrebbe semplicemente confrontare il tempo di esecuzione del suo
abituale carico di lavoro (workload), ossia appunto dell’insieme di programmi e di
comandi al sistema operativo che usa abitualmente. Il problema è che difficilmente si
trovano utenti che una tale caratteristica di regolarità per quanto riguarda i
aggiornamento: 7 luglio 2001
7
Autore: Sandro Petrizzelli
Appunti di “Calcolatori Elettronici” – Capitolo 2
programmi utilizzati, per cui bisogna necessariamente far riferimento ad altri metodi
per valutare le macchine.
Esistono allora quattro “livelli” di programmi da potersi usare per confrontare le
prestazioni di macchine diverse; li elenchiamo in ordine decrescente dal punto di
vista dell’accuratezza delle predizioni che consentono di ottenere:
•
programmi (reali): pur non sapendo quale frazione del tempo sarà dedicata
a questi programmi, il venditore sa comunque che alcuni utenti li useranno
per risolvere i propri problemi reali; tipici esempi di programmi reali sono i
compilatori per il C, i programmi di composizione testi come TeX oppure
alcuni strumenti CAD come Spice. Una delle caratteristiche dei programmi
reali è quella di avere degli ingressi, delle uscite e delle opzioni che l’utente
può selezionare quando tali programmi sono in funzione;
•
kernel (nuclei): sono stati fatti numerosi tentativi per circoscrivere piccoli
pezzi chiave (detti appunto kernel) dei programmi reali per valutare le
prestazioni dei calcolatori ( 4). Chiaramente, gli utenti generalmente non
fanno girare programmi kernel sulle proprie macchine, proprio perché
questi, a differenza dei programmi reali da cui provengono, sono pensati
solo per valutare le prestazioni e non per risolvere problemi reali. I kernel
vengono utilizzati al meglio quando si vogliono isolare le prestazioni di
alcune caratteristiche specifiche di una macchina, al fine di evidenziare le
ragioni delle differenze tra le prestazioni con programmi reali;
•
Toy Benchmark (programmi giocattolo): questi particolari programmi sono
tipicamente lunghi dalle 10 alle 100 linee di codice e producono un risultato
che l’utente conosce in partenza;
•
Benchmark Sintetici: questi programmi sono “filosoficamente” simili ai
kernel, ma hanno la differenza di sforzarsi di accordare la frequenza media
degli operandi e delle operazioni di un vasto insieme di programmi ( 5). Così
come i kernel, i benchmark sintetici non sono usati dagli utenti proprio
perché non calcolano nulla di utile per i loro problemi reali. Tra l’altro, i
benchmark sintetici sono ancora più astratti rispetto ai kernel, dato che,
mentre i kernel hanno un codice comunque estratto dai programmi reali, il
codice sintetico viene creato artificialmente per soddisfare il profilo medio di
esecuzione di cui si diceva prima.
Quando si ha a disposizione un programma per la valutazione delle prestazioni di
un calcolatore e non si è sicuri del modo con cui classificarlo, il primo controllo da
effettuare consiste nel vedere se esiste un qualche ingresso al programma e/o se
sono previsti dei risultati in uscita. Ad esempio, un programma senza ingresso
calcola lo stesso risultato ogni volta che viene invocato, mentre invece alcuni
programmi (tipicamente le applicazioni per l’analisi numerica e la simulazione) usano
quantità trascurabili di dati di ingresso. In generale, ogni programma reale ha
almeno un ingresso.
Dato che i produttori di calcolatori hanno maggiore o minore successo a seconda
del rapporto prezzo/prestazioni dei loro prodotti in relazione a quello degli altri
concorrenti presenti sul mercato, sono disponibili enormi risorse per migliorare le
prestazioni dei programmi più diffusi per la valutazione.
Abbiamo osservato più volte che i programmi reali possono essere teoricamente
usati per valutare le prestazioni dei calcolatori. Tra l’altro, se l’industria usasse tali
4
5
Gli esempi più noti sono il Livermore Loops ed il Linpack
I più popolari benchmark sintetici sono il Whetstone ed il Dhrystone.
Autore: Sandro Petrizzelli
8
aggiornamento: 7 luglio 2001
Le prestazioni
programmi, quanto meno spenderebbe le proprie risorse per migliorare le prestazioni
di ciò che realmente serve agli utenti. Viene allora da chiedersi come mai non tutti
usano i programmi reali per misurare le prestazioni. Possiamo citare le seguenti
motivazioni:
•
i kernel ed i toy benchmark appaiono molto utili nella fasi iniziali di un
progetto, in quanto sono abbastanza piccoli da essere simulati facilmente, al
limite anche a mano. Essi risultano particolarmente invitanti quando si
inventa una nuova macchina, dato che i compilatori potrebbero non essere
subito disponibili. Inoltre, i piccoli benchmark, a differenza dei grandi
programmi, possono essere standardizzati con maggiore facilità ed infatti si
trovano in letteratura molti più risultati pubblicati per i piccoli benchmark
che non per quelli grandi;
•
a fronte di questi pregi, almeno al giorno d’oggi non esiste più una valida
motivazione razionale che giustifichi l’uso dei benchmark e dei kernel per
valutare come lavorano i sistemi di calcolo: in passato, i linguaggi di
programmazione non erano uniformi in macchine diverse e ogni macchina
aveva il sistema operativo, per cui il trasporto dei programmi reali appariva
particolarmente scomodo e quindi venivano preferiti i benchmark e/o i
kernel; al giorno d’oggi, invece, la diffusione di sistemi operativi standard
(come UNIX e DOS), la presenza di software liberamente distribuito dalle
università e da altri enti, oltre alla disponibilità di calcolatori moderni e
veloci, hanno rimosso molti dei vecchi ostacoli, per cui l’uso di programmi
reali è diventato, oltre che opportuno al fine di ottenere risultati corretti,
anche molto semplice.
Come porre in relazione le prestazioni
Il principio fondamentale da applicare nella presentazione delle misure di
prestazioni dovrebbe essere la riproducibilità: si dovrebbero cioè annotare e fornire
tutte le informazioni che potrebbero essere utili ad un altro sperimentatore per
duplicare i risultati. Al contrario, tale principio non sempre viene applicato; per
rendersene conto, basterebbe confrontare il modo con cui vengono descritte in
letteratura le prestazioni dei calcolatori ed il modo, ad esempio, con cui vengono
presentate le prestazioni automobilistiche delle riviste del settore: tali riviste, oltre a
fornire un numero elevato di misure di prestazioni (almeno 20), elencato tutti gli
accessori montati sulla macchina in prova, il tipo di pneumatici usati durante il test,
la data di tale test e molto altro; al contrario, le pubblicazioni scientifiche possono
avere solo i secondi di esecuzione, etichettati semplicemente con il nome del
programma e quello della macchina: ad esempio, si trova scritto che Spice richiede
94 secondi su una macchina DECstation 3100. In casi come questo, si lasciano
all’immaginazione del lettore gli ingressi e la versione del programma, quella del
compilatore, il livello di ottimizzazione del codice compilato, la versione del sistema
operativo, le caratteristiche hardware della macchina (ad esempio quantità di
memoria centrale, numero e tipo di dischi, versione della CPU); si nasconde cioè
tutta una serie di informazioni che invece influiscono pesantemente sull’esito delle
prove.
I periodici automobilistici hanno abbastanza informazioni, circa le misurazioni, da
permettere allo stesso lettore di ripetere i risultati oppure semplicemente di mettere
in relazione le opzioni selezionate per i rilievi; al contrario, sulle riviste di calcolatori
spesso questo non avviene.
aggiornamento: 7 luglio 2001
9
Autore: Sandro Petrizzelli
Appunti di “Calcolatori Elettronici” – Capitolo 2
Tempo totale di esecuzione
Il più semplice approccio per riassumere le prestazioni relative di varie macchina
consiste nell’usare il tempo totale di esecuzione di due distinti programmi. Si
possono ad esempio ottenere risultati del tipo seguente:
•
la macchina B è dell’ 810% più veloce della macchina A per i programmi 1 e
2;
•
la macchina C è del 2400% più veloce della macchina A per i programmi 1 e
2.
Di conseguenza, si deduce che la macchina C è del 175% più veloce della
macchina B per i programmi 1 e 2.
Un simile sommario considera dunque il tempo di esecuzione, che è la nostra
misura finale delle prestazioni . Se il carico di lavoro usato per la prova consistesse
nell’eseguire i due programmi 1 e 2 uno stesso numero di volte, le affermazioni
precedenti consentirebbero di predire il tempo di esecuzione relativo per il carico
di lavoro su ogni macchina.
E’ possibile calcolare anche una media dei tempi di esecuzione, che in qualche
modo segua il tempo di esecuzione totale. Una scelta possibile è quella di usare la
media aritmetica dei tempi di esecuzione: considerando un totale di N programmi
costituenti il carico di lavoro e indicando con Tempo i il tempo di esecuzione del
programma i-simo, la suddetta media vale
1 N
∑ Tempo i
N i =1
Si potrebbe anche pensare di esprimere la prestazione non più in termini di tempo
di esecuzione, ma in termini di un rapporto (ad esempio il MFLOPS); con questa
scelta, la media che definisce il tempo totale di esecuzione prende il nome di
media armonica, definita nel modo seguente:
N
1
∑
i =1 Frequenza i
N
dove Frequenza i il è una funzione della quantità 1/Tempo i .
Tempo pesato di esecuzione
Sulla base delle precedenti considerazioni, viene da chiedersi quale possa essere la
migliore mescolanza di programmi con cui realizzare il carico di lavoro per il
calcolatore in prova. La risposta non è semplice.
La media aritmetica si basa sull’assunzione che gli N programmi funzionino tutti
allo stesso modo, cosa che però potrebbe non essere vera; in particolare, se l’ipotesi
non è verificata (per cui il carico di lavoro è composto da un assemblaggio “non
bilanciato” di programmi), ci sono due possibili approcci adottabili. Il primo di questi
(il secondo sarà esaminato nel prossimo paragrafo) consiste nell’introdurre il
concetto di media pesata:
Autore: Sandro Petrizzelli
10
aggiornamento: 7 luglio 2001
Le prestazioni
•
si può sostituire la media aritmetica con una media aritmetica pesata,
dove il peso w attribuito a ciascun programma dipende dalla frequenza
relativa del programma stesso entro il carico di lavoro. Ad esempio, nel caso
di N=2 programmi, se il 20% delle attività del carico di lavoro è dovuto al
programma 1 ed il restante 80% è dovuto al programma 2, allora si
useranno pesi rispettivamente pari a 0.2 e 0.8. L’espressione generale della
media pesata è dunque la seguente:
1 N
∑ (Pesoi × Tempo i )
N i =1
•
in alternativa, si può usare una media armonica pesata al posto della
semplice media armonica definita in precedenza:
N
Peso i
∑
i =1 Frequenza i
N
Per quanto riguarda la scelta effettiva di Peso i , lo si può porre uguale alla fequenza
del programma i-simo entro il carico di lavoro.
Tempo di esecuzione normalizzato
Il secondo approccio, al trattamento dei programmi in un carico di lavoro non
bilanciato, consiste fondamentalmente in due passaggi successivi:
•
in primo luogo, si normalizzano i tempi di esecuzione rispetto ad una
macchina di riferimento (così come si fa per il calcolo del MIPS
normalizzato), ottenendo i tempi di esecuzione normalizzati;
•
in secondo luogo, si considera la media dei tempi di esecuzione normalizzati,
che prende il nome di tempo di esecuzione medio normalizzato.
Si tratta in effetti di una misurazione leggermente aleatoria, in quanto suggerisce
che le prestazioni dei nuovi programmi possano essere predette semplicemente
moltiplicando tempi e prestazioni ottenuti sulla macchina campione.
In termini concreti, il tempo di esecuzione medio normalizzato può essere espresso
in due modi:
•
usando la media aritmetica dei tempi di esecuzione normalizzati:
1 N Tempo i
∑
N i =1 Tempo rif
•
usando la media geometrica dei tempi di esecuzione normalizzati:
N
N
Tempo i
∏ Tempo
i =1
aggiornamento: 7 luglio 2001
11
rif
Autore: Sandro Petrizzelli
Appunti di “Calcolatori Elettronici” – Capitolo 2
In entrambi i casi, la quantità
Tempo i
Tempo rif
è il tempo di esecuzione, normalizzato
sulla macchina di riferimento, per il programma i-simo su un totale di N programmi
presenti nel carico di lavoro.
P
Prroo ee ccoon
nttrroo d
deellllaa m
meed
diiaa ggeeoom
meettrriiccaa
La media geometrica dei tempi di esecuzione normalizzati presenta sia pregi sia
difetti. Un sicuro pregio è quello di soddisfare la seguente proprietà (valida per medie
geometriche di qualsiasi quantità):
X 
Media geometrica (X i )
= Media geometrica  i 
Media geometrica (Yi )
 Yi 
In base a questa proprietà, se prendiamo la frazione della media o la media delle
frazioni, otteniamo gli stessi risultati. La media geometrica dei tempi di
esecuzione normalizzati, in contrasto con la media aritmetica, è costante per
qualsiasi macchina di riferimento . Da qui consegue che la media aritmetica NON
dovrebbe essere usata come media normalizzata dei tempi di esecuzione.
Se consideriamo poi la media aritmetica pesata, è evidente una cosa: dato che i
suoi pesi sono proporzionati ai tempi di esecuzione su una data macchina, essi sono
influenzati non solo dalla frequenza d’uso dei programmi entro il carico di lavoro, ma
anche dalle peculiarità della particolare macchina, nonché anche dalla dimensione
dei dati in ingresso al programma. Al contrario, la media geometrica dei tempi di
esecuzione normalizzati è indipendente dal tempo di esecuzione
dei singoli
programmi, qualunque sia la macchina usata come riferimento per la
normalizzazione.
Tra l’altro, qualora ci sia da fare una analisi comparativa di prestazioni avendo
fissato i programmi ma non gli ingressi, le ditte in competizione potrebbero
“manipolare” il responso della media aritmetica pesata, fornendo l’ingresso più
grande al programma che ha le prestazioni migliori, in modo che esso domini il
risultato complessivo finale. Al contrario, in una simile situazione, la media
geometrica sarebbe senz’altro meno influenzabile rispetto alla media aritmetica.
A fronte di tutti questi pregi della media geometrica, c’è anche un inconveniente
non da poco: essa viola infatti il principio fondamentale della misura delle
prestazioni che abbiamo portato avanti fino ad ora, dato che non predice il tempo di
esecuzione. Per rendercene conto, ci serviamo di un esempio concreto.
Nella seguente tabella sono riportati i tempi di esecuzione, in secondi, di due
programmi (1 e 2) su tre macchine (A, B e C):
Programma 1
Programma 2
Tempo totale
Calcolatore A Calcolatore B Calcolatore C
(sec)
(sec)
(sec)
1
10
20
1000
100
20
1001
110
40
Tabella 1 – Tempo di esecuzione di due programmi su tre macchine
Autore: Sandro Petrizzelli
12
aggiornamento: 7 luglio 2001
Le prestazioni
Sulla base di questi dati, possiamo affermare quanto segue:
•
•
A è del 90% più veloce di B per il programma 1: A impiega infatti un solo
secondo contro i 10 impiegati da B;
B è del 900% più veloce di A per il programma 2: B impiega infatti 100
secondi contro i 1000 di A;
•
•
A è del 1900% più veloce di C per il programma 1;
C è del 4900% più veloce di A per il programma 2;
•
•
B è del 100% più veloce di C per il programma 1;
C è del 400% più veloce di B per il programma 2.
Andiamo ora a calcolare alcune medie aritmetiche pesate:
Calcolatore A Calcolatore B Calcolatore C
Programma 1
Programma 2
Medie aritmetiche
W(1)
W(2)
W(3)
1
1000
10
100
20
20
500,50
91,82
2,00
55,00
18,18
10,09
20,00
20,00
20,00
Tabella 2 – Media aritmetica pesata dei tempi di esecuzione, usando tre diversi insiemi di pesi
Abbiamo evidentemente considerato 3 medie diverse:
•
la media W(1) assegna pesi uguali ai due programmi, per cui coincide con
una media aritmetica non pesata:
W (1) =
•
la media W(2) usa invece una composizione dei programmi inversamente
proporzionale ai tempi di esecuzione sulla macchina B;
W (2) =
•
1 2
(Peso i × Tempo i ) = 1 [(0.5 × Tempo1 + 0.5 × Tempo 2 )]
∑
2 i =1
2
1 2
(Peso i × Tempo i ) = 1  1 × Tempo1 + 1 × Tempo 2 
∑
2 i =1
2  10
100

la media W(3), infine, considera pesi inversamente proporzionali ai tempi di
esecuzione dei programmi sulla macchina A.
W (3) =
1 2
(Peso i × Tempo i ) = 1  1 × Tempo1 + 1 × Tempo 2 
∑
2 i =1
2  1
1000

La caratteristica di W(2) e W(3) è dunque quella di normalizzare ai tempi di
esecuzione dei programmi su una data macchina affinché il tempo di funzionamento
venga speso uniformemente tra i vari programmi. Per un insieme di N programmi,
aggiornamento: 7 luglio 2001
13
Autore: Sandro Petrizzelli
Appunti di “Calcolatori Elettronici” – Capitolo 2
ognuno richiedente un dato tempo T j su un data macchina, il sistema di pesi che
origina tempi uguali è il seguente:
wj =
1
N
Tj × ∑
i =1
1
Ti
Adesso, partendo sempre dai dati della tabella 1, riportiamo i tempi di esecuzione
normalizzati a ciascuna delle tre macchine considerate:
Normalizzato
ad A
A
B
C
Programma 1
Programma 2
Medie
Media aritmetica
Media geometrica
Tempo totale
Normalizzato
a B
A
B
C
Normalizzato
A C
A
B
C
100% 1000% 2000% 10% 100% 200%
5%
50% 100%
100% 10%
2%
1000% 100% 20% 5000% 500% 100%
100%
100%
505%
100%
1001%
63%
505%
100%
100% 110% 2503% 275% 100%
100% 63% 158% 158% 100%
100%
11%
4%
910%
100%
36%
2503% 275% 100%
Tabella 3 – Tempi di esecuzione della tabella 1, normalizzati a ogni macchina
Le prime tre colonne considerano i tempi di esecuzione normalizzati a quelli della
macchina A (motivo per cui la prima colonna, corrispondente proprio ad A, riporta
sempre il valore 100%). Le medie aritmetiche evidenziano una minore velocità di B
rispetto ad A (B è più di 5 volte) e di C rispetto a B (quasi 2 volte). Le medie
geometriche dicono invece che A e B sono uguali ed entrambi più lenti di C.
Le successive tre colonne considerano i tempi di esecuzione normalizzati a quelli
della macchina B (motivo per cui la quinta colonna, corrispondente proprio ad B,
riporta sempre il valore 100%). Le medie aritmetiche evidenziano in questo caso
risultati opposti rispetto a quelli precedenti: esse dicono infatti che A è più lento di
B, che invece è leggermente più veloce di C. Al contrario, le medie geometriche
forniscono ancora gli stessi risultati rispetto a prima, a conferma del fatto che esse
sono indipendenti dalla macchina rispetto a cui si normalizza.
Le ultime tre colonne considerano infine i tempi di esecuzione normalizzati a quelli
della macchina C (motivo per cui la quinta colonna, corrispondente proprio ad C,
riporta sempre il valore 100%). Valgono le stesse considerazioni di prima: le medie
aritmetiche forniscono risultati contrastanti rispetto ai precedenti, mentre invece
quelle geometriche continuano ad essere coerenti: A e B hanno le stesse prestazioni,
mentre il tempo di esecuzione di C è il 63% di quello di A o di B (si noti che
100%/158% è pari proprio al 63%).
Fin qui, dunque, si evidenziano i pregi della media geometrica rispetto a quella
aritmetica. Ci sono però anche dei problemi: ad esempio, mentre le medie
geometriche della tabella 3 sembrano indicare prestazioni uguali per A e B e migliori
per C, dalla tabella 1 deduciamo che in realtà non necessariamente è così : infatti,
dalla suddetta tabella si ricava che, se il carico di lavoro consiste nell’eseguire 1 e 2
una sola volta, A impiega un tempo totale di 1001 secondi, mentre B impiega solo
110 secondi. Al contrario, il risultato fornito dalla media geometrica è veritiero solo
se il carico di lavoro consiste nell’eseguire centro volte il programma 1 e solo 1 volta
il programma 2:
Autore: Sandro Petrizzelli
14
aggiornamento: 7 luglio 2001
Le prestazioni
Calcolatore A: 100 × (1 sec) + 1 × (1000 sec) = 1100 sec
Calcolatore B: 100 × (10 sec) + 1 × (100 sec) = 1100 sec
Tuttavia, per un simile carico di lavoro, il tempo di esecuzione totale suggerisce
che le macchine A e B sono circa il 50% più veloci della macchina C:
Calcolatore C: 100 × (20 sec) + 1 × (20 sec) = 2020 sec
Al contrario, la media geometrica indica che la macchina C è più veloce sia di A
sia di B.
Quindi, il carico di lavoro che prevede 100 esecuzioni di 1 per ogni esecuzione di 2
non è un carico di lavoro valido per tre (o più) macchine che vogliano essere in
accordo con le prestazioni previste dalla media geometrica dei tempi di esecuzione
normalizzati.
Possiamo allora porci la seguente domanda: fermo restando che il motivo per cui è
stata introdotta la media geometrica dei tempi normalizzati era quello di evitare di
dare uguale enfasi ai programmi del carico di lavoro, tale soluzione consente di
ottenere effettivamente un miglioramento?
La soluzione ideale ai problemi esposti risulta essere la seguente: si considera un
reale carico di lavoro e si pesano i vari programmi in base alla loro frequenza di
esecuzione. Se questo sistema di pesi non è attuabile, allora si deve normalizzare i
tempi affinché un uguale tempo (normalizzato) venga speso su ciascun programma e
si prediranno i tempi di esecuzione usando tali insiemi, come fatto nella tabella 2. Se
sono presenti degli ingressi ai vari programmi, essi vanno specificati quando vengono
confrontate le prestazioni. Se poi i risultati devono essere normalizzati ad una
macchina specifica, bisogna prime riassumere le prestazioni con una opportuna
misura dei pesi e poi si potrà effettuare la normalizzazione.
Autore: Sandro Petrizzelli
e-mail: [email protected]
sito personale: http://users.iol.it/sandry
aggiornamento: 7 luglio 2001
15
Autore: Sandro Petrizzelli