Calcolatori Elettronici II 23/03/2004

Transcript

1 Calcolatori Elettronici II 23/03/2004 Questa sopra è una curva che rappresenta le performance evolutive al passare degli anni. Quella in basso è la curva che dà ragione della crescita delle prestazioni se questa fosse soltanto dovuta all innovazione tecnologica. Si vede che inizialmente le curve sono molto vicine e poi da un certo punto succede qualcosa, nel senso che il tasso di crescita della prestazione ha un brusco incremento, e come si vede poi si arriva al punto per cui, negli anni 2000, si ha un incremento al di sopra di quello che ci si poteva aspettare soltanto dall innovazione tecnologica (fattore 10-15). Oggi occorrono 1000$, o anche meno, per un personal computer che ha più performance, memoria e disco di un computer che negli anni '80 era un supercomputer e che veniva venduto per $. Questo dà l'idea di quello che è successo negli ultimi 20 anni. Che cosa ha prodotto questo? Le cause sono sostanzialmente due: 1. I progressi dovuti all'innovazione tecnologica; 2. L'innovazione nei principi di progettazione dei computer. Fino agli anni '70 queste due cause concorrevano pressoché allo stesso livello, cioè avevano la stessa importanza per quanto riguardava la crescita delle performance dei computers: normalmente si aveva un 25%-30% di tasso di crescita annuale delle prestazioni. Da un certo punto in poi è successo qualcosa che ha rivoluzionato quel trend, ed in particolare l avvento dei microprocessori, che è stato dovuto all innovazione tecnologica, alla tecnologia MOS, quindi alla grande capacità di integrazione che si è resa disponibile, e alla possibilità di integrare all interno di un unico chip quella che normalmente viene chiamata CPU, che prima veniva realizzata a logica discreta. Questo ha fatto sì che i progettisti cavalcassero questa tendenza abbandonando via via la logica discreta nel realizzare i computer, e quindi facendo morire dei settori che erano i settori prevalenti dei minicomputer e dei mainframes (grossi computer). Questo ha fatto sì che l incremento delle prestazioni dal 25%-30% l anno passasse al 35%. 1

2 In realtà però questo salto essenzialmente era dovuto, più che all'innovazione nelle tecniche di progettare un computer, quasi esclusivamente alla tecnologia. Ad un certo punto c'è stata una svolta: fino a quel punto si lavorava tipicamente in assembler, e questo significa che non era facile programmare, e poi quando veniva creato un nuovo microprocessore si cercava di renderlo compatibile con quello precedente, almeno per quanto riguardava l'esecuzione del codice; un esempio classico è quello della famiglia Intel (che è nata con l'8080, che era un microprocessore a 8 bit, poi è nato l'8085, l'8086, l'80186,, l'80486, Pentium), dove un codice sviluppato negli anni '80 ancora girerebbe su un Pentium. Questo era legato non al fatto che il progettista nel progettare il prossimo microprocessore era innamorato dell'architettura precedente, ma ad un fatto pratico, cioè al fatto di non sprecare tutte le risorse investite nel progettare il software che girava su quel microprocessore. Questo era un vincolo fortissimo per il progettista. A metà degli anni '80 però via via si è cominciato ad abbandonare il linguaggio assembler, perché i programmatori cominciavano ad usare sempre più i compilatori. Abbandonare il linguaggio assembler significava incominciare ad eliminare quel vincolo sulla compatibilità del codice: se ho un codice scritto in C e voglio passare da un processore all'altro ricompilo e non devo rifare il software. Però questo è uno degli aspetti; l'altro aspetto fondamentale è legato ai sistemi operativi: fino a quel tempo i sistemi operativi erano essenzialmente i sistemi operativi proprietari, e questo significava che quando l'ibm, per esempio, vendeva ad una banca un software che girava su quel sistema operativo, questa era bloccata a vita su quella piattaforma perché il software fa riferimento al sistema operativo. Poi è stato creato Unix: è stato concepito all'interno di un università, quindi era un software libero, non risentiva di logiche di mercato e si poneva quindi come un sistema operativo che non era legato ad una particolare piattaforma hardware. Unix è stato già dall'inizio progettato, quasi tutto scritto in C e non più in assembler, per essere indipendente dalla piattaforma. Questo ha fatto sì che il progettista improvvisamente si trovasse di fronte ad una libertà inaspettata. A questo punto, Patterson ed Hennessy non dovendo più sottostare a quei vincoli potevano progettare un processore che aveva delle prestazioni molto più elevate delle architetture che in quel momento erano in circolazione. Questa logica ha fatto sì che si incominciasse ad affermare la nuova filosofia di processori, che è quella che si chiama RISC (reduced instruction set computer). A parità di tecnologia perché una filosofia RISC dovrebbe avere prestazioni migliori? Patterson ed Hennessy hanno fatto una considerazione: prima si programmava in assembler, e oltre al problema della compatibilità del codice c'erano altri problemi, cioè un programmatore assembler da un nuovo processore si aspetta un set di istruzioni molto ricco così ha una certa libertà nello scegliere il proprio stile di programmazione. Una volta che non si programma più in assembler non è più programmatore che utilizza il set di istruzioni del processore ma il compilatore, ovvero il progettista del compilatore; allora ci si è chiesti il perché continuare a progettare un processore con set di istruzioni ricchissimo (ricchissimo significa che da un punto di vista implementativo più esteso e complesso è il set di istruzioni più complesso è l'hardware che poi realizza quel set di istruzioni, e quindi occupa più area sul silicio) se poi nessuno più lo utilizza, o meglio non si sa quanto è utilizzato. Qual è il modo più semplice e diretto di capire se conviene o no progettare un set di istruzioni ricco visto che adesso ci sono i compilatori? Si cominciano a compilare tanti programmi diversi tra loro e vado a vedere ogni per programma compilato quali sono le istruzioni del processore che utilizza, e magari faccio una statistica. Facendo questo posso scoprire che, per esempio, un istruzione pazzesca che qualcuno aveva concepito in quel microprocessore dal compilatore non veniva mai usata o quasi mai; ma allora se io la tolgo il compilatore entra in crisi oppure si può sempre trovare una strategia per cui quella istruzione io la faccio la stessa però usando altre istruzioni? La risposta naturalmente è sì. Siccome progettare un processore significa innanzitutto definire il suo set di istruzioni, e siccome il progettista sa che più complesso è il set di istruzioni più complesso è il processore, allora incomincia a vedere un determinato compilatore su quel processore che ha un set complesso di istruzioni quante ne utilizza, e quindi si fanno delle statistiche, delle misure sull'utilizzo del set di istruzioni. Facendo queste misure è emerso che moltissime istruzioni erano praticamente quasi mai utilizzate. Allora a questo punto la cosa più 2

3 ovvia era ridurre il set di istruzioni all'essenziale; ma riducendo il set di istruzioni qual è il vantaggio che si ottiene? Se il set di istruzioni è meno complesso significa che l'hardware è meno complesso e quindi posso andare più veloce. Se io diminuisco il numero di transistor all'interno del chip per eseguire le istruzioni, i rimanenti transistor li posso utilizzare per metterci dentro la memoria oppure per realizzare il pipeline (un modo di eseguire più istruzioni contemporaneamente all'interno dello stesso processore). Normalmente il processore è molto più veloce della memoria, allora se all'interno del processore si sono liberati tanti transistor potrei utilizzare quell'aria di silicio libera per mettere un po di memoria dentro, per esempio dei registri; questo mi fa andare più veloce perché si risparmiano un sacco di accessi in memoria. Un aspetto è la memoria cache. Tutte le volte che si va memoria il processore deve rallentare moltissimo, allora la possibilità di inventarsi la gerarchia di memoria, cioè la memoria cache, è un qualcosa che fa pagare molto meno il prezzo al processore sulla lentezza della memoria. Facendo queste innovazioni si incomincia ad assistere ad un rate di crescita delle prestazioni di oltre il 50% per anno, e questo è quello che dà la spiegazione dell'andamento di quelle curve. Conseguenze: Un microprocessore di oggi supera le prestazioni di un supercomputer di 10 anni fa Dominanza di computer a microprocessore (PC+WS) sull'intero range dei computers (minicomputer e mainframe sostituiti da multiprocessore). Tutto questo è dovuto a questa innovazione nell'arte di progettare, innovazione che si basa sul principio fondamentale che è quello di un approccio quantitativo alla progettazione. Approccio quantitativo significa che prima di progettare qualcosa vado a fare delle misure vedo quello che già ho come viene utilizzato, e se ci sono cose che vengono utilizzate raramente queste sono le candidate ad essere buttate via, e questo significa inventarsi qualcosa di nuovo. Questa è una possibile rappresentazione della catena alimentare: i pesci più grossi mangiano i pesci più piccoli: Questa catena alimentare nel caso dell'informatica è stata ribaltata: Alcune conseguenze dell'approccio quantitativo sono: Le prestazioni delle workstation migliorano del 50% per anno Se si tiene conto del fattore costo un miglioramento costo-prestazioni del 70% per anno. Quando parliamo di computer che cosa intendiamo esattamente? Oggi ci sono tre segmenti di mercato che è abbastanza facile identificare: Desktop computing (PC + WS) Servers: file server, web server, ecc Embedded computers: parte più in crescita del mercato. 3

4 Questi tre segmenti di mercato però hanno caratteristiche diverse da diversi punti di vista: Nell'ultima riga sono riportate le caratteristiche tipiche di ognuno dei tre settori: nel caso del desktop due parametri importanti sono il prezzo e le prestazioni (anche sulla grafica); per quanto riguarda il server si vuole un throughput elevato, cioè che riesca per esempio a processare un certo numero di milioni di richieste secondo, la disponibilità, che significa la capacità del sistema a continuare a mantenersi funzionante anche in presenza di guasti, e poi la scalabilità, ovvero la capacità del sistema ad essere espanso (un server normalmente prevede la possibilità di aumentare la capacità di memorizzazione, la possibilità di aggiungere processori, ecc ); per quanto riguarda i sistemi embedded questi sono caratterizzati sicuramente dal prezzo, il consumo di potenza, prestazioni per quella specifica applicazione. Dopo aver parlato di questa suddivisione e aver visto come i tre settori richiedono parametri di performance diversi, il compito del progettista è quello di determinare quali sono gli attributi della nuova macchina, e progettare per massimizzare la prestazioni rispettando i vincoli di costo e potenza, naturalmente collocandosi nel settore orientato (desktop, server o embedded). Un aspetto molto interessante è quello legato alla tendenza della tecnologia: perché un progettista di computer deve preoccuparsi moltissimo della tendenza tecnologica? Se io progettista ho oggi una certa tecnologia e il progetto del prossimo processore lo faccio con quello che ho a disposizione, perché mi devo preoccupare della tecnologia che avrò fra due anni? Ci sono dei dati che sono abbastanza consolidati che riguardano l'evoluzione della tecnologia: (capacity = capacità d integrazione) C'è un parametro che assume un ruolo cruciale: time to market = 2 anni design + produzione. Il time to market è il tempo che si impiega ad immettere un nuovo prodotto sul mercato. Se io ho un time to market, per esempio per una workstation, di due anni e faccio il progetto con la tecnologia di oggi faccio un errore clamoroso perché se fra due anni il trend tecnologico è quello visto sopra allora la capacità, per esempio, sarà sicuramente maggiore di quella di oggi. Quindi bisogna guardare a cosa ci sarà disponibile quando il prodotto andrà in produzione. Altri aspetti legati alla tecnologia sono: Feature size: minima size di un transistor o wire nelle direzioni x e y 10µ (1971) 0,08µ (2003) Il numero di transistor incrementa quadraticamente con la diminuzione della feature size, mentre la performance invece aumenta linearmente con la feature size. All'aumentare della capacità di integrazione e della frequenza di funzionamento di questi dispositivi il ritardo di propagazione (wire delay) dei segnali incomincia ad essere rilevante: 4

5 molti cicli di clock sono spesi per il ritardo sulle linee, e nel caso del Pentium IV due stage di pipeline su 20 sono consumati per la propagazione dei segnali attraverso il chip. Potenza (power): l'incremento del numero di transistor per chip e la frequenza di switching comporta un incremento del consumo di potenza (qualche decina di W per un microprocessore anni '80, 100 W per il Pentium IV a 2GHz). Nel prossimo futuro la potenza sarà il limite principale. 5

6 25/03/2004 Abbiamo visto che una delle chiavi fondamentali che spiega l'elevato incremento delle performance nei computers è un nuovo approccio alla progettazione: un approccio di tipo quantitativo, quindi un approccio che sostanzialmente assume come paradigma quello di eseguire delle misure e sulla base di queste misure selezionare quelli che sono gli aspetti più rilevanti, quindi quelli che sono più suscettibili di essere migliorati garantendo un elevato livello di performance, e trascurando altri aspetti che, per quanto possono offrire scelte che soddisfano l'utente, magari poi sono molto poco utilizzati. Per fare queste misure questo approccio quantitativo utilizza vari strumenti che si basano su un insieme di programmi che si chiamano Benchmarks, sui Traces (queste informazioni vengono derivate a fronte dell'esecuzione di un programma, e per esempio questi traces ci dicono un'istruzione rispetto al totale quante volte viene eseguita), sugli instruction Mixes (mi dicono per esempio 30% di ALU e così via). Abbiamo visto, per esempio, nel caso dei sistemi embedded che uno dei requisiti fondamentali, oltre alla performance per quella determinata applicazione, per esempio era il consumo di potenza, ma si capisce bene è fondamentale anche l'area consumata sul silicio. Quindi sono stati messi a punto strumenti per la stima della potenza, dell'aria, del delay (tempo speso per eseguire un programma), ecc. Naturalmente poi ci sono strumenti che provano valutare i vari parametri di interesse attraverso teorie tradizionali, quale la teoria delle code, regole di tipo pratico, e leggi fondamentali. Oggi incominciamo a vedere cosa significa valutare alcuni parametri prestazionali dei sistemi partendo da alcune definizioni di base. Per noi misurare le prestazioni di un computer, per esempio in termini di velocità, significa valutare il tempo di esecuzione, cioè all'utente finale quello che interessa è quanto tempo viene speso da questo oggetto per eseguire una determinata applicazione, quindi si parla di ExTime (execution time): dire che un computer X è n volte più veloce di un computer Y significa dire che (per un web server non ci interessa l ExTime, ma il throughput). A seconda che si parla di ExTime, oppure di throughput, oppure di qualsiasi altro parametro, devo stare attento a cosa mettere numeratore per dire che una cosa è più performante di quella precedente; questa ambiguità si elimina, quanto meno a livello di linguaggio, parlando di rapporto di prestazioni: se io dico che la macchina X è più performante della macchina Y di n volte, significa che > 1 > 1 Naturalmente in questo caso si ha che, se la mia performance è espressa in termini di tempo di esecuzione; se invece come performance intento il throughput ecco che la performance coincide con il throughput. Se X è n% volte più veloce di Y significa che, dove 6

7 Esempio: Se Y impiega 15 secondi per eseguire un task e X impiega 10 secondi, quanto % X è più veloce? n=50%. Legge di Amdahl Questo è un principio che dovrebbe essere sempre seguito da un progettista, e in verità occorrerebbe seguirlo sempre a prescindere che il progetto riguardi un computer piuttosto che un'automobile, ecc. Make the common case fast! (rendi il caso più frequente veloce). Più frequente come va inteso? Va inteso che quando io utilizzo il sistema c'è una sua parte che è responsabile di molto del tempo di lavoro del sistema, allora intuitivamente un miglioramento apportato a questa parte ci ripaga sufficientemente. In miglioramento di prestazioni che può essere ottenuto migliorando una qualche attività, quindi rendendola più veloce, è limitato dalla frazione di tempo in cui tale attività ha luogo. SPEEDUP: misura di quanto più veloce un task gira sulla macchina enhanced. Quindi se io misuro uno Speedup = 1.5 significa che ho migliorato le performance del 50%. Vediamo come si ricava una qualche relazione che ci consenta quantitativamente di misurare qual è lo Speedup che si ottiene quando si apporta un miglioramento ad un sistema. Supponiamo di avere un programma che impiega il seguente tempo (la ExTime) per essere eseguito; analizzando il sistema vedo che c'è una sua parte che si può migliorare e in termini di tempo di esecuzione è responsabile di quella frazione di tempo (parte colorata) rispetto al totale. Questa parte a cui applico il miglioramento posso renderla più veloce, e questo significa che nel nuovo sistema quella parte si contrarrà, e quindi il tempo di esecuzione totale si accorcerà: Il rapporto tra il primo tempo di esecuzione e il secondo mi dà lo Speedup overall (cioè Speedup complessivo). Le due grandezze che ci interessano sono: Speedup enhanced (Speedup Enhanced, cioè lo Speedup che posso ottenere solo della parte a cui applico il miglioramento); il rapporto tra il tempo da migliorare e l ExTime totale si chiama Fraction Enhanced (cioè la frazione di tempo a cui posso applicare il miglioramento, si misura sul sistema originario). Avendo definito queste due grandezze possiamo vedere come si misura lo Speedup overall. Quest'ultimo non è altro che: (woe = without enhancement, we = with enhancement). Il nuovo tempo di esecuzione è dato da: Così lo Speedup overall è: Questa formula ci consente di fare un sacco di valutazioni per scoprire se un determinato miglioramento ripaga oppure no in termini di guadagno complessivo che si può ottenere. Nelle annunciato della legge di Amdahl abbiamo detto che il performance improvement è limitato dalla frazione di tempo in cui l'attività ha luogo; questa frazione di tempo è proprio la Fraction Enhanced ; ovvero il massimo Speedup ottenibile è limitato dalla Fraction Enhanced. In che senso? 7

8 Immaginiamo, caso irrealizzabile, di trovare un idea che fa sì che una certa parte del sistema possa andare infinitamente più veloce di quanto va adesso; questo significa che lo Speedup enhanced sarebbe infinito e quindi il rapporto Fraction Enhanced /Speedup enhanced tenderebbe a 0; più elevata è la Fraction Enhanced maggiore è lo Speedup overall. Da questa analisi semplicissima si può concludere che quello che in effetti ha un impatto enorme dal punto di vista di guadagno di prestazioni complessivo è la Fraction Enhanced, ovvero la frazione di tempo suscettibile di essere migliorata: maggiore è questa frazione di tempo maggiore è il guadagno che si può ottenere, e questo ragionamento lo si fa indipendentemente da quanto veloce si vuole rendere. Esempio Prendiamo un computer che ha un certo processore in cui la parte relativa all esecuzione delle istruzioni in floating point può essere migliorata facendola andare al doppio di velocità rispetto a quella attuale, quindi abbiamo uno Speedup enhanced pari a 2; qual è il guadagno che possiamo ottenere? Per rispondere a questa domanda dobbiamo stimare la Fraction Enhanced. L unità floating point viene utilizzata dai programmi, quindi non devo parlare in astratto, ma prendo un programma, suppongo che è il programma che mi interessa, e vedo quanto tempo viene speso (da questo programma) durante l esecuzione sull unità floating point rispetto al totale. In questo caso supponiamo che soltanto il 10% delle istruzioni eseguite sono di tipo floating point, ed è come dire che soltanto il 10% del tempo rispetto al totale del tempo di esecuzione, di un determinato programma, viene speso per la parte floating point. Questo 10% rappresenta la Fraction Enhanced. Applicando le formule abbiamo: Quindi viene fuori che lo Speedup è pari al 5,3%. Esempio Dato un computer cerchiamo di rendere più veloce la CPU di 5 volte, ma questo ci costa 5 volte il costo originale della CPU. Quanto ci guadagno? Per vedere se questo investimento è economicamente vantaggioso devo vedere quanto ci guadagno in termini di performance e quanto mi costa questo guadagno di performance. I dati che abbiamo sono: la CPU nel sistema originario è responsabile del 50% del tempo totale di esecuzione (di un determinato programma); questo significa che l altro 50% è dedicato all I/O. Il costo della CPU è di 1/3 del costo totale del sistema. La prima cosa che facciamo è valutare lo Speedup: Quindi ottengo un miglioramento di performance complessivo pari al 67%. Quanto mi costa questo investimento? I 2/3 del sistema continueranno a costare quanto prima, mentre l altro 1/3 costerà 5 volte di più: Quindi mi costerà 2,33 volte il costo originario. Così ho che il costo cresce molto di più delle performance. 8

9 Esempio Supponiamo di avere un computer su cui viene eseguito una determinata applicazione. Questa applicazione ha delle operazioni in floating point alcune delle quali sono radici quadrate (FPSQR). In totale l unità floating point è responsabile del 50% del tempo di esecuzione, e la sola FPSQR è responsabile del 10% del tempo di esecuzione totale. A questo punto c è una gara tra due tipi di progettazione diversi: 1) l hardwareista dice che riesce a migliorare l hardware del FPSQR in modo tale da farlo andare 10 volte più veloce; 2) il softwareista dice che può ottenere il doppio di velocità dell intera unità floating point. Nel primo caso ho una Fraction Enhanced che è pari a 0,2 e uno Speedup di 10, e allora ne segue che: Nel secondo caso ho una Fraction Enhanced che è pari a 0,5 e uno Speedup di 2, e allora ne segue che: Quindi migliorano di più le prestazioni se aumento la velocità di tutta l unità floating point anche se solo del doppio, rispetto al miglioramento della sola FPSQR anche se di 10 volte. Abbiamo detto che uno dei dilemmi che fa diventare matti i progettisti di computer è quello della lentezza della memoria. È un problema perché il computer nasce come una macchina per eseguire programmi e la CPU non fa altro che andare a leggere l'istruzione della memoria ed eseguirla. Quindi sicuramente per ogni istruzione bisogna fare quanto meno un accesso in memoria; questo significa che tutti i miglioramenti di prestazioni che si riescono ad apportare al processore possono essere vanificate dalla lentezza della memoria. Cosa si può fare per cercare di risolvere questo problema, o quanto meno di farlo pesare poco? Non potendo fare niente la tecnologia, qualcuno si è inventato una soluzione estremamente intelligente. Questa soluzione fa riferimento ad un principio che è il cosiddetto principio di località, e ad un altro principio che è molto legato all'elettronica. Per quanto riguarda l'elettronica c'è un principio che dice che: smaller is faster (più piccolo è più veloce). Sappiamo che quando parliamo di memorie RAM ci sono due tipologie: RAM statiche e RAM dinamiche. Le RAM statiche sono caratterizzate da una velocità più elevata delle RAM dinamiche, però le prime hanno il problema che consumano di più, perché sono più veloci, e la loro capacità di integrazione è molto più bassa delle seconde. Il principio di località è un principio che fa riferimento ad una considerazione base: quando eseguo un programma vado in memoria legge un istruzione, la eseguo e vado all'istruzione successiva, ecc.; queste istruzioni quando un programma viene caricato in memoria si succedono una dopo l'altra nella memoria; quindi quando io eseguo l'istruzione i-esima è probabile che la prossima da eseguire sta nella locazione di memoria immediatamente successiva. Questo è quello che ha fatto pensare a qualcuno che allora c'è una località nell'esecuzione del programma, e questo è quello che viene chiamato principio di località spaziale, ovvero quando io vado a referenziare un item probabilmente referenzierò gli item che stanno là intorno. C'è un altro aspetto di questo principio di località che, piuttosto che guardare alla località spaziale, guarda alla località temporale, ovvero se io vada referenziare un item (istruzione) in questo tempo, è probabile che nel prossimo futuro la referenzierò di nuovo (si pensi ai loop). Questa considerazione che tipo di idea potrebbe fare venire al progettista per risolvere questo problema del gap di prestazioni tra processore e memoria? 9

10 Se io vado ad interporre una memoria statica, quindi una piccola memoria, tra processore e RAM dinamica, e in questa piccola memoria di volta in volta ci metto, sfruttando il principio di località, la parte di codice che viene referenziata, essendo veloce diminuisco in termini di velocità il gap tra processore e memoria. Quest idea è furba soltanto se capita poco spesso che il processore andando in questa piccola memoria (memoria cache) non trova quello che cerca. Per verificare se questa cosa succede poco spesso oppure no si fanno delle misure su dei programmi di uso molto frequente. Ci sono delle misure su programmi molto utilizzati e si va scoprire che l 80%-90% dei riferimenti generati dal processore durante l'esecuzione di un programma cadono all'interno del 10%-20% dell'intero codice. Se questo è vero quel 20% di codice lo piglio e lo metto nella memoria statica. Da un punto di vista architetturale il nostro sistema si organizza nel seguente modo: abbiamo il processore all'interno del quale c'è un certo insieme di registri (che si può vedere come una piccola memoria incorporata all'interno del processore), poi quando il processore ma all'esterno per leggere dalla memoria qualcosa, incontra come prima cosa la memoria cache, che sta prima della main memory, e naturalmente dopo c è la memoria di massa. Vista in questi termini è come se avessimo creato una gerarchia di memoria. Più alto è il livello, più questo è prossimo al processore più veloce è, e più costoso è. Esempio Cache cinque volte più veloce della main memory, e il 90% del tempo di CPU è speso in una frazione di codice che può interamente essere posto in cache. Lo Speedup che posso ottenere è: Questo significa che il sistema complessivamente sarà più veloce di 3,6 volte, cioè delle 360%. (secondo me del 260%) La formula che sintetizza il principio di Amdahl e che fa riferimento allo Speedup enhanced e alla Fraction Enhanced ci serve a valutare il rapporto tra il vecchio ExTime e il nuovo ExTime. Laddove questi ExTime io potessi valutarli attraverso altre grandezze che magari in alcuni casi sono più facilmente misurabili è ovvio che ricorro ad un altro modo per valutarli. Cycles per Instruction A noi interessa vedere qual è il CPU time, cioè il tempo speso dalla CPU per eseguire un programma. Naturalmente in questo CPU time non è presente la parte eventualmente legata all input/output. Il CPU time lo possiamo esprimere attraverso il seguente prodotto: 10

11 Il tempo del processore durante il suo lavoro viene scandito da un clock con un periodo pari a T ck. Se io voglio misurare quanto tempo ho speso per eseguire un programma, ovviamente se conosco quant'è il periodo di clock, misuro quanti cicli di clock dall'inizio alla fine del programma sono trascorsi. CK cycles for a program a sua volta si può esprimere come I c CPI, dove I c sta per Instruction Count, e CPI è il clock per instruction. Supponiamo di potere sapere quante istruzioni sono state eseguite, I c, e conosco il numero di cicli di clock eseguiti per ogni istruzione, allora il numero di cicli di clock richiesti per un istruzione moltiplicati per il numero di istruzioni mi dà il numero totale di cicli di clock del programma, che moltiplicato per il tempo di clock mi dà il CPUtime: Il CPI in realtà non è altro che un valore medio, ed è ottenuto come: Qua si parla di CPI medio. In realtà molto spesso io posso calcolare il CPI attraverso una media pesata che fa riferimento a categorie diverse di istruzioni: quando viene eseguito un programma ci saranno istruzioni che implicano l esecuzione di operazioni logico-aritmetiche (ALU), poi ci saranno istruzioni di Branch (salto condizionato), poi ci saranno istruzioni di scambio di informazioni tra la memoria e il processore (Load/Store), ecc ; ammettendo che ogni categoria sia omogenea dal punto di vista del numero di cicli di clock richiesta per essere eseguita posso calcolare il CPI attraverso una media pesata: dove n rappresenta il numero di categorie distinte di istruzioni, ed F i è la frequenza con cui la categoria i-esima è presente all interno del running; la frequenza non è altro che il numero di volte in cui quella categoria di istruzioni è stata eseguita rispetto al numero di istruzioni totali eseguite: Ovviamente il CPUtime in questo caso è pari a: Il problema è stimare F i, cioè durante un runnig quante volte è stata eseguita una determinata classe di istruzioni; questo si chiama instruction mix. È da notare che il CPI i dovrebbe essere misurato e non dedotto da quello che normalmente viene chiamato CPU technical reference manual, perché questo assume che tutto vada alla velocità del processore e non considera che alcuni cicli di clock possono essere spesi per degli accessi in memoria che è più lenta. Se è vero che il CPUtime è una misura delle prestazioni del nostro sistema ed è esprimibile dal prodotto di I c, CPI e T ck, noi possiamo pensare che se vogliamo apportare un miglioramento, diminuire l I c del 30% è la stessa cosa, in termini di guadagno di performance, di fare più veloce il clock del 30% oppure ridurre del 30% il CPI medio. Allora si potrebbe pensare di investire sulla cosa che viene più facile migliorare. C è un problema: questi tre fattori non sono tra di loro indipendenti, ma cercare di migliorare uno dei tre porta al peggioramento di qualcuno degli altri due o di entrambi. Quindi come sempre succede nella pratica bisogna trovare un compromesso tra esigenze molto spesso tra di loro in conflitto. 11

12 Di seguito mostriamo una tabella che fa vedere da cosa dipendono l I c, il CPI e il Clock Rate: L I c dipende dal compilatore perché ogni compilatore lo stesso programma lo può tradurre in diversi modi; dipende dall Instruction Set perché per esempio un istruzione di Branch in alcuni processori è un unica istruzione, e ci sono processori in cui il loro set di istruzioni non prevede di fare sia la verifica della condizione che il salto in un unica istruzione, ma sono splittate su due istruzioni diverse. Il CPI indirettamente dipende dal compilatore perché a seconda di come compilo, e quindi dalla sequenza di istruzioni che produco, questo può portare a richiedere più cicli di clock per eseguire un istruzione; dipende dall Instruction Set perché se nel mio set di istruzioni includo un istruzione che fa un insieme di operazioni è ovvio che ha bisogno di più cicli di clock per essere eseguita; dipende dall Organizzazione che è l organizzazione architetturale che io scelgo per implementare tutte le attività che deve eseguire il processore. Il Clock Rate dipende dall Organizzazione perché più semplice è l hardware più veloce si può rendere; ed è ovvio che la Tecnologia incide sulla frequenza di clock. Si vede che il miglioramento della tecnologia porta solo benefici. Come si vede se io penso di abbassare il CPI agendo sull organizzazione bisogna capire cosa succede al clock rate; per esempio se io trovo una soluzione che mi porta le istruzioni dell ALU da 1.5 cicli di clock ad 1 ciclo di clock, e però per implementare questa soluzione scopro che l hardware si è complicato e quindi la frequenza di clock con cui opero devo abbassarla, automaticamente ho migliorato il CPI ed ho peggiorato il Clock Rate. 12

13 30/04/2004 Esempio Facciamo riferimento ad una macchina base A in cui all interno dell instruction set tutte le volte che dobbiamo implementare un if, cioè un salto condizionato, in realtà per come è fatto l instruction set questo richiede l esecuzione di due istruzioni: COMPARE + BRANCH. Immaginando di avere un programma che giri su questa macchina, attraverso delle misure sono state dedotte le seguenti frequenze di esecuzione delle varie classi di istruzioni: alla fine otteniamo un CPI medio di 1,2. Significa che per eseguire quel programma mediamente spendiamo 1,2 cicli di clock per ogni istruzione. A questo punto un progettista pensa di apportare una modifica: proviamo a modificare l instruction set di questo processore in modo tale che l istruzione COMPARE venga incorporata all interno dell istruzione di BRANCH, cioè in poche parole la fase di valutazione della condizione appartiene all istruzione di BRANCH. Per fare questo però l organizzazione interna del processore, l organizzazione hardware, è tale che la frequenza di clock operativa deve modificarsi; in particolare a seguito di questa modifica bisogna allungare, rispetto alla versione base, il periodo di clock di 1,25, cioè del 25%. La domanda è: conviene questa modifica? Supponendo di ignorare il problema legato al costo, cioè quanto costa fare questa modifica, ma ci concentriamo soltanto sulla performance, noi dobbiamo andare a vedere se il tempo speso per eseguire lo stesso programma sulla macchina A o sulla macchina B (quella modificata) varia, e come varia. Cercando di ricavarsi di nuovo quel tipo di tabella, però per la nuova macchina, adesso dobbiamo vedere qual è la nuova frequenza di BRANCH, e la frequenza delle rimanenti istruzioni: Sappiamo che il CPUtime della macchina base è: CPUtime A = Ic A 1,2 Tck A. Noi sappiamo che sulla macchina B l Ic B varia rispetto a quello della macchina A perché in quest ultima c erano due istruzioni per ogni BRANCH; questo significa che adesso il numero di istruzioni si contrae del 20%: Ic B = Ic A 20%Ic A = 0,8Ic A. La frequenza di BRANCH è data dal numero di occorrenze del BRANCH rispetto all Ic B complessivo: Così la tabella che si ottiene è: quindi il nuovo CPI medio è 1,25. 13

14 A questo punto il CPUtime B è: CPUtime B = Ic B CPI B 1,25 Tck A = 0,8Ic A 1,25 1,25Tck A = 1,25 Ic A Tck A. Questo significa che il programma viene eseguito più velocemente nella macchina A. Quando si parla di misure delle performance c'è un indice, che è stato utilizzato moltissimo un po' di anni fa, tuttora viene ancora utilizzato, ma è caduto in disuso, che è il cosiddetto MIPS: milioni di istruzioni per secondo. MIPS = instruction count / Time 10 6 = Clock Rate / CPI Se io confronto due CPU è una ha un numero di MIPS maggiore dell'altra allora la prima è più veloce della seconda. Questa cosa non è detto che sia una cosa vera: è facilmente dimostrabile che una CPU con un numero di MIPS può portare ad un CPUtime maggiore piuttosto che minore. Se due CPU hanno un set diverso di istruzioni, lo stesso programma compilato su una macchina potrebbe presentare un MIPS, quando viene eseguito, maggiore perché per esempio sono istruzioni semplici quindi maggiori come numero di istruzioni piuttosto che in un'altra macchina dove ci sono istruzioni più complesse. I MFLOP/s sono milioni di floating point operation per second. MFLOP/s = FP Operation / Time Anche in questo caso vale lo stesso ragionamento fatto prima. Esempio Supponiamo di avere una macchia base di cui sono state ottenute, a fronte dell'esecuzione di un programma, le seguenti statistiche: Questa macchina base che tipo di set di istruzioni ha? Ha un set di istruzioni che si chiamano register/register, oppure si può dire che è una macchina di tipo Load/Store. Una macchina di tipo Load/Store è una macchina in cui qualsiasi operazione che coinvolge l'unità logica-aritmetica (ALU) può essere eseguita soltanto se gli operandi stanno entrambi all'interno del processore, cioè sono nei registri del processore. Questo significa che, per esempio, quando scriviamo un programma in C e c è la somma fra due variabili, queste variabili se quando è stato compilato il programma stanno in memoria, prima di potere eseguire la somma bisogna prevedere che il valore di queste variabili venga caricato con un operazione di load all interno di registri del processore, e successivamente può essere eseguita la somma; il risultato della somma presuppone che poi ci sia un operazione di store, cioè venga scritto in memoria. Questa è un architettura load/store. In un architettura di questo tipo non è possibile eseguire, per esempio, la somma tra un operando che sta all interno di un registro del processore e un operando che sta all interno della memoria. Adesso rispetto ad una macchina di tipo load/store supponiamo di voler modificare l architettura di questa macchina modificando l instruction set e aggiungendo una nuova classe di istruzioni di tipo register/memory ovvero che mi consentono di fare operazioni ALU anche con operandi che stanno uno in un registro e uno in memoria. Questo tipo di istruzioni richiedono due cicli di clock, a differenza di una qualunque istruzione ALU che invece richiedeva un ciclo di clock. 14

15 Il problema è: a fronte dello stesso programma, compilato sulle due macchine, cosa ci guadagno modificando il set di istruzioni introducendo questo tipo di istruzione? In particolare la domanda è: quale frazione di load nella macchina base deve essere eliminata perché questa modifica incominci a dare un guadagno? Questo significa che, se adesso ho istruzioni di tipo register/memory, tutta una parte di operazioni che facevo nella macchina base, operazioni che coinvolgevano l ALU, che richiedevano delle load verranno eliminate nella nuova macchina perché non è necessario fare delle load esplicite. In pratica probabilmente riduco l I c, e riducendo l I c, siccome CPUtime = I c CPI T ck, se non peggiorano le altre due componenti può darsi che avrò un CPUtime più basso, quindi che la nuova macchina con questo nuovo set di istruzioni sia più performante della vecchia macchina. È ovvio che in qualche modo la performance di una macchina dipenderà da quante load scompaiono; allora in questo caso il nostro obiettivo è valutare qual è la percentuale di load che deve essere eliminata perché questo tipo di instruction set architecture possa incominciare a fornire un guadagno rispetto alla macchina base. I dati relativi alla macchina base sono riportati sopra. Se io metto anche l istruzione RegMem e chiamiamo X il numero di istruzioni RegMem eseguite abbiamo che X è il numero di load che si riducono rispetto alla macchina originaria, ma queste istruzioni di tipo RegMem le utilizzo per fare operazioni di tipo ALU, quindi anche le istruzioni ALU si riducono di X: facendo questa modifica purtroppo il branch avrà 2 bisogno di tre cicli di clock. Calcolando il nuovo CPI otterrei 1.7-X; in realtà X è la frazione di istruzioni espressa però rispetto al vecchio instruction count. Noi vogliamo calcolare il CPI della nuova macchina, quindi questo CPI deve essere normalizzato rispetto al nuovo instruction count, ovvero il vecchio instruction count moltiplicato per 1-X, questo perché ognuna delle nuove frequenze è divisa per 1-X: F ALU =N ALU /I C =(N ALU N RegMem )/I C (1 X)=N ALU /I C (1 X) N RegMem /I C (1 X)=F ALU /(1 X) X/(1 X). Vado a trovare il valore di X per cui i due CPUtime sono uguali: / = (1 X) (1.7 X)/(1 X) (Clock Old = Clock New ) 1.5 =1.7 X X = 0.2 X deve essere almeno uguale a 0.2, cioè tutte le load che erano presenti dovrebbero essere eliminate, affinché la modifica non produca una perdita di performance. Noi abbiamo considerato il CPUtime immaginando che tutto vada alla velocità della CPU, e quindi che la CPU non debba aspettare memoria, ecc. In realtà le cose non stanno così: quando la CPU accede in memoria normalmente deve aspettare. Abbiamo visto che per mitigare questo problema è stata inventata la memoria cache. Allora tutte le volte che andando in memoria la CPU trova quello che sta cercando nella cache di fatto non deve aspettare (immaginando che la cache vada alla stessa velocità del processore); naturalmente questo non può succedere sempre perché la cache è piccola e quindi difficilmente riuscirà a contenere tutto quello che serve; questo significa che delle volte ci sarà un miss (mancato successo); in tal caso si 15

16 deve aspettare che il dato che non sta in cache debba essere reperito nel livello di memoria successivo, main memory, spostato nella cache e quindi il processore può leggere quel dato se si trattava di un operazione di lettura. Questo significa che il CPUtime, se lo devo calcolare correttamente quando c è una gerarchia di memoria, lo devo esprimere nel seguente modo: Quindi il tempo di CPU per eseguire un determinato programma sarà pari al numero di cicli della CPU se tutto andasse bene dilatato di un numero di cicli di stallo, nel senso che il processore deve bloccare la propria attività aspettando che qualcosa arrivi dalla memoria. Questo come si vede fa sì che il numero di cicli di clock totale per eseguire quel programma in presenza di una memoria reale aumenti rispetto al numero di cicli di clock strettamente richiesti dal processore. Proviamo a esprimere il MemoryStallCycles in qualche modo: questi cicli di clock di stallo si verificano tutte le volte che andando in memoria si verifica un miss. Se moltiplico il numero di miss per il miss penalty, ovvero per la penalità che pago per spostare il dato dalla main memory alla cache espresso in numero di cicli di clock, ottengo il numero totale di cicli di clock di stallo. Se io voglio mettere in evidenza l instruction count, il numero di miss non è altro che una frazione di I c, ovvero il numero di miss per instruction. Posso definire una nuova grandezza: il cosiddetto miss rate. Il miss rate non è altro che la frazione di miss che sperimento rispetto al numero totale di accessi in memoria: se vado 100 volte in memoria (cache) e 15 volte su queste 100 volte c è un miss allora il miss rate è il 15%. Allora possiamo scrivere: dove mem.ref.per.instr. è il numero di riferimenti medio per istruzione, cioè per ogni istruzione quanti riferimenti in memoria si fanno. Esempio Supponiamo di avere una macchina A e supponiamo di avere un programma in cui ci sono il 40% di istruzioni load/store, un CPI medio pari a 2, in cui però ci siano tutti cache hits (tutti gli accessi in memoria hanno successo). Questa macchina la voglio confrontare con una macchina B che ha il 2% di miss rate, cioè il 2% delle volte che vado in cache non trovo quello che voglio; tutte le volte che succede questo il miss penalty è di 25 cicli di clock. Nel caso della macchina A abbiamo:, Per quanto riguarda la macchina B abbiamo: Il mem.ref.per.instr. sarà 1 perché tutte le istruzioni eseguite richiedono un accesso in memoria, e poi ci sono il 40% delle istruzioni che sono di tipo load/store che richiedono due accessi: uno per leggere l istruzione e un altro per eseguire o la load o la store, quindi il numero di riferimenti medi è 1+0,4. Così il CPUtime è: Se facciamo il rapporto otteniamo: Così abbiamo un degrado di performance del 35%. 16

17 Abbiamo parlato di approcci quantitativi alla progettazione basati su misure per vedere quanto una certa alternativa piuttosto che un altra è utilizzata, e abbiamo visto come valutare. Siccome parliamo di computer, cos è che ci consente di valutare le prestazioni? Fare girare dei programmi e vedere quanto tempo impiega il computer per eseguirlo. Se ci mettiamo nella prospettiva in cui normalmente si mettono i produttori di computer si capisce che è auspicabile che il proprio prodotto è migliore di quello che produce qualcun altro. Solo che dire migliore non è facile. Incominciamo da un punto di vista logico a definire cosa ci consentirebbe di dire se un computer è migliore oppure no. Il produttore per dire che un computer è meglio di un altro dovrebbe dimostrare che per eseguire certi programmi il suo computer impiega meno tempo di un altro; però non si sa a quali programmi fare riferimento, perché non si sa ogni utente quali programmi usa. Il primo problema quindi è: quali programmi usare per valutare le prestazioni? E per quali tipologie di utenti? Qual è la condizione ideale impossibile da realizzare? La condizione è quella di utilizzare un workload reale, quindi fatto da programmi reali, che non è altro che l insieme di applicazioni e di comandi di sistema operativo che vengono dati durante l utilizzo normale da parte di quell utente. Questo perché gli utenti sono tanti e ognuno ha esigenze abbastanza diverse. La soluzione che è stata individuata già da un po di anni è quella di utilizzare le cosiddette benchmark suites, cioè delle collezioni di programmi che in qualche modo siano rappresentativi dei diversi scenari di utilizzo dei computer. Che tipo di programmi costituiscono una benchmark suite? Ci sono varie tipologie di programmi. Toy benchmarks, sono dei software semplicissimi, linee di programma, fatti per stimolare certi parti del sistema: sieve, puzzle, quicksort. Synthetic benchmark, che non sono dei programmi reali, cioè che non risolvono nessun problema reale: whetstone, dhrystone. Kernels, che sono dei pezzi di programmi reali, tipicamente per esempio pezzi di programmi di un sistema operativo o kernel di qualche applicazione particolare: livermore loops. Programmi reali: gcc, spice, ecc. Dopo aver litigato per tanti anni alla fine i costruttori sempre cercano di trovare un accordo, e in genere lo scenario in cui si cerca di sintetizzare queste liti e questo accordo è quello degli organismi di standardizzazione internazionali. A livello di standardizzazione è stato proposto il cosiddetto SPEC (Standard Performance Evaluation Corporation), che è riconosciuto da tutti i costruttori e che specifica quali sono i programmi che bisogna utilizzare per valutare le prestazioni di una macchina. Considerando il tipo di differenziazione del mercato nel settore dei computer (desktop, server ed embedded) SPEC ha cercato di differenziare le suites per valutare le prestazioni dei vari settori: CPU intensive significa che stimolano prevalentemente la CPU, quindi valutano le prestazioni prevalentemente del processore. I Graphic intensive che cercano di valutare le prestazioni dal punto di vista della grafica. Gli SPEC FS (spec filesystem) sono basati sulla valutazione del numero di transazioni per secondo che è in grado di eseguire un server. 17

18 Tipicamente un benchmark esce ogni 3 anni. SPEC CPU2000 Naturalmente c è un ampio settore di mercato, che è il settore di mercato più promettente, che è quello dei PC, per cui sono nati anche i benchmark per PC: Business Winstone: è uno script che lancia Netscape e diversi prodotti di Office per cercare di simulare un workload reale di un tipico pc user; CC Winstone: simula un ambiente di applicazioni per la creazione di contenuti multimediali (Photoshop, Premiere, Navigator, ecc.); Winbench: insieme di kernel per il test di CPU, sistema video, dischi. Per quanto riguarda i sistemi embedded è nato il consorzio EEMBC che ha creato la suite chiamata EDN che include: automotive industrial, consumer, networking, office automation, elecommunication. Si fanno molti giochi con i benchmark: ottenere dei risultati migliori su una macchina rispetto ad un altra facendo girare lo stesso benchmark suite sui due sistemi senza dire come sono equipaggiati; ottenere performance migliori ottimizzando dei compilatori per determinati programmi; 18

19 workload utilizzati in modo arbitrario: quando per esempio ho una suite di benchmark con i programmi A, B, C, D, e il programma A è quello più veloce allora quando faccio girare questa suite di benchmark, se non ho delle costrizioni particolari, potrei fare girare molte volte il programma A e poche volte gli altri programmi; quindi prevale la performance del programma A. 19

20 01/04/2004 Abbiamo detto che proprio perché è abbastanza complicato individuare un workload che sia rappresentativo per ogni utente sono nati dei benchmark suites. Un benchmark suite abbiamo detto che è costituito da un insieme di programmi molto diversi tra di loro, quindi si capisce che non è facile stabilire qual è il giusto mixing di questi programmi per valutare le prestazioni. Allora c è il problema di cercare di stabilire quando si fa girare un benchmark che tipo di rapporto di prestazioni devo andare ad ottenere. Una delle cose che molto raramente avviene nel campo dei computer è quello di rispettare il cosiddetto principio di riproducibilità: includere tutto ciò che consente ad altri di replicare gli esperimenti fatti. Nel caso degli SPEC benchmark un report richiede: - una descrizione quasi completa della macchina (configurazione hardware e software); - flag di compilazione: quando si usa un programma come gcc per compilare, per esempio, è necessario settare dei flag in modo tale che tutti devono utilizzare quei flag per compilare; - pubblicazione dei risultati sia delle performance di base (baseline) sia quelle ottimizzate. Nella performance baseline viene imposto di utilizzare un particolare tipo di compilatore e un set di flag da utilizzare nella compilazione per tutti i programmi nello stesso linguaggio. Per quanto riguarda la performance di picco (peak performance) c è una maggiore libertà in modo da potere fare un tuning delle prestazioni attraverso, per esempio, compilatori proprietari o flag specifici, cioè che non sono imposti. Esempio di baseline performance Per quanto riguarda l affidabilità dei benchmark come predittori della performance reale riportiamo un esempio: c è un programma che si chiama matrix300 (SPEC 89), un software che fa il prodotto tra matrici, che spende il 99% del tempo di esecuzione su una linea di codice. ottimizzando il loop più interno attraverso un compilatore per una IBM PowerStation 550 si ottiene un miglioramento di un fattore 9 20