|
Articolo pubblicato sul n. 72 di MCmicrocomputer (Edizioni Technimedia Srl - Roma) nel marzo 1988
M.I.P.S.:
In questa puntata di MIPS, faremo una breve passeggiata
informatica sui processori. Parleremo di processori RISC (Reduced
Instruction Set Computer), di processori CISC (Complex
ecc.ecc.) e ... del famosissimo Transputer della INMOS,
arcinoto ormai a tutti. Computermania L'informatica personale, che ormai compie quasi un decennio di esistenza, ha sempre rappresentato solo la punta di un iceberg dalle dimensioni, per quanto anch'esso relativamente giovane d'età, ben piu' mastodontiche. Tale iceberg, come noto, è l'informatica (con la i maiuscola) vera e propria, nella quale da alcuni decenni stanno impegnando le proprie energie scienziati e studiosi di tutto il mondo. Attenzione: non è di certo l'informatica personale che rappresenta il banco di prova per l'informatica seria, ma il contrario. Quanto noi vediamo nei personal non è che una contrazione di tecniche via via piu' avanzate che hanno gia' fatto, magari, la loro storia in computer ben piu' grandi. Quando ad esempio fu presentato l'Amiga, tutti i copmuter-freak di questa generazione sussultarono venendo a conoscenza del fatto che su tale macchina potevano girare in parallelo piu' programmi. Per conto mio fu solo un simpatico salto indietro nel tempo di qualche decennio quando si facevano i primi esperimenti di multiyasking. Discorso analogo pre l'Apple Machintosh II, facente capo a chissà quale misterioso NuBus che poi, ad un esame un po' piu' attento si è rivelato essere soltanto un Bus con meccanismo di arbitragio, deterministico, sincrono decentralizzato, fritto e rifritto (nell'idea di base) chissà da quanto tempo. Scendendo a livello di processori, abbiamo avuto prima delle CPU semplici e lente (8 bit) poi, piano piano, hanno pensato di aumentare lo spazio di memoria indirizzabile e le dimensioni dei registri interni (16 e poi 3 bit) dotando tali CPU di prefetch e qualche stadio di pipeline in piu'. La solita scoperta dell'acqua calda. Sono sicuro che tra un po' cominceranno ad arrivare le macchine non con uno ma con piu' processori equivalenti e sentiremo strillare da qualche pubblicità: "... la prima macchina multiprocessor disponibile sul commercio... novità mondiale...". L'Atari già ci sta provando col suo progetto Abaq (che secondo me non sarà mai commercializzato, a meno che l'Atari stessa non voglia entrare nel mondo dei mini computer e delle workstation grafiche professionali lasciando perdere gli ST). Progetto Abaq basato interamente sui Transputer del quale tra un po' vi narrero' una storiella. RISC è bello E' piu' semplice costruire una casa utilizzando tanti mattoncini piccoli (e leggeri) o pochi mattoni grandi (e pesanti) ? Potremo fare un bel sondaggio e vedere la distribuzione di fautori di mattoni piccoli e grandi e cercare di dare una bella risposta al problema. Molto probabilmente pero' chi avrà votato per i mattoni piccoli continuerà ad usare questi anche se vincono i "forzuti" e viceversa... Bene, con i processor sta succedendo la stessa cosa: è meglio un computer chr opera velocemente con istruzioni facili-facili o meno velocemente con istruzioni piu' potenti? C'è infatti chi dice che la prima possibilità sia la migliore. L'idea nasce, probabilmente, da un detto informatico che suona piu' o meno cosi': "i processor impiegano l'80% del loro tempo ad eseguire il 20% delle loro istruzioni". Statisticamente parlando non fa una grinza: del resto tale valutazione è stata fatta proprio... statisticamente!Dunque dai processor via via sempre piu' poteni, con linguaggi macchina molto evoluti, un bel giorno (non molti anni fa, diciamo 8-9 al massimo) alla IBM hanno pensato in un certo senso di fare macchina indietro, costruendo un processor molto semplice, con un set di istruzioni ridotte ma molto veloci da eseguire. Istruzioni semplici al posto di istruzioni potenti significa pero' che con uno stesso algoritmo nel primo caso viene implementato con un numero maggiore di istruzioni che nel secondo caso. Ma le istruzioni del primo sono eseguite piu' velocemente di quelle del secondo... chi vince, dunque, questo, tira e molla? Ovviamente i progettisti di processori RISC pensano che siano meglio le istruzioni semplici. E per applicazioni piu' o meno "normali" non gli si puo' proprio dare torto. Nel frattempo, pero', anche i compilatori dei vari linguaggi di programmazione si sono evoluti sempre di piu' fornendo codici oggetto quanto piu' ottimizzati possibile per la macchina sulla quale dovranno girare. Infatti i processori RISC hanno si' un linguaggio macchina assai semplice ma non sono affatto stupidi! Nei processori RISC sono impegnate la maggior parte delle piu' alte tecnologie rivolte all'aumento di velocità: troviamo stadi di pipeline, utilizzo di memorie cache, un gran numero di registri general purpose ed altri meccanismi che vi illustreremo in seguito. E quanto piu' un compilatore sfrutta tutte queste feature tanto piu' riesce ad assottigliare la differenza (quantitativa) rispetto al codice oggetto generato per un processor convenzionale. Considerato poi che il clock dei processori RISC, grazie proprio alle istruzioni semplici, è di solito ben piu' elevato del "normale", scopriamo che l'ago della bilancia pende proprio, inesorabimente, dalla partr RISC. Questo, come detto prima, per applicazioni normali. Se infatti abbiamo ad esempio a che fare con calcoli scientifici, matrici, vettori e simili, state pur certi che non c'è RISC che tenga di fronte ad un bel calcolatore vettoriale che esegue in parallelo decine di operazioni per volta. Discorso analogo per i Transputer che il sottoscritto (vedi a tal proposito il riquadro "L'Anti-David") ritiene non essere, assolutamente, un processore RISC. Il Transputer è fatto essenzialmente per lavorare in parallelo con altri Transputer. Molti altri. Lo testimoniano ad esempio le quattro linee di I/0 disponibili in ognuno di essi che permettono di dialogare ad alta velocità con altrettanti Transputer. Nel progetto Abaq della Atari, ad esempio, ne vengono utilizzati fino a 13, il primo dei quali si trova sulla scheda madre e gli altri si aggiungono via via (a gruppi di quattro, pare) secondo le proprie necessità. Ora, non crediate che un programma, piu' Transputer ci sono , piu' va veloce (in questo caso, infatti, converrebbe rivolgersi ad un bel RISC), solo per applicazioni rigorosamente concorrenti (un algoritmo è scisso in piu' processi paralleli) potremo allocare un processo su ogni processore e far correre "il tutto" come la solita scheggia. Ma queste problematiche avremo modo di parlarne in altri "Appuntamenti". L'architettura RISC UN processore, per essere RISC, deve verificare alcune condizioni che indichiamo qui di seguito. 1) implementazione delle istruzioni in Hardware senza utilizzo di microprogramma. Cio' è abbastanza facile per la semplicità intrinseca delle istruzioni da eseguire e, naturalmente, concorre ad aumentare la velocità di elaborazione del processore. Per chi si trovasse in difficoltà, ricordiamo che il livello di linguaggio macchina "convenzionale" che dunque non sarebbe eseguito direttamente dall'hardware ma interpretato dal livello sottostante. Un po' come succede con qualsiasi personal dotato di interprete Basic: noi scriviamo istruzioni in tale linguaggio, ma queste vengono eseguite dall'interprete che, come è noto, è scritto in linguaggio macchina. 2) formato fisso delle istruzioni. Le istruzioni dei processori RISC coinvolgono sempre l'uso di registri interni e gli accessi in memoria riguardano solo le istruzioni di Load e Store. Tutte le operazioni aritmeticho-logiche vengono eseguite sui registri interni ed è molto ridotto anche il numero di modi di indirizzamento in memoria. Cio' significa, ad esempio, che non avremo, come mostrato in figura 1, una istruzione pre sommare il contenuto di due celle (e mettere il rsultato in una terza locazione) ma dovremo caricare in un registro il primo operando, in un altro registro il secondo operando, eseguire la somma tra registri e scrivere il risultato nella cella " destinazione": vedasi figura 2. 3) Molti registri interni. Dal momento che tutto il "lavoro" viene effettuato all'interno del processore è bene che siano disponibili molti registri interni (32, 64, 128 o anche di piu', contro i 2-16 dei processor convenzionali) in modo da non dover mai ricorrere alla memoria, che fa perdere piu' tempo di tutti, per parchrggiare risultati intermedi. 4) Esecuzione "single-cycle". Grazie alle caratteristiche sopra esposte si raggiunge facilmente l'ambito traguardo di eseguire le istruzioni in un solo ciclo di clock. MIPS assoluti? Nella prima puntata di M.I.P.S. vi abbiamo parlato di questa unità di misura della velocità di elaborazione dei processori che ha il grandissimo difetto di non essere assoluta ma relativa ad una stessa famiglia di processor. Quando infatti si dice milioni di operazioni per secondo, dovrebbe essere ben chiaro anche il tipo di istruzioni, se RISC o CISC, altrmenti si puo' cadere facilmente in errori valutativi macroscopici. Tra un processore RISC, ad esempio che "corre" a 6 MIPS e un processore CISC che "corre" a 3 MIPS non è possibile stabilire, guardando solo i MIPS, quale dei due sia piu' veloce. Infatti il primo fa 6 milioni di istruzioni RISC al secondo, l'altro ne esegue solo 3 milioni, ma ben piu' potenti. Per confrontare le velocità occorre di fatto eseguire svariati benchmarck, partendo magari da diversi linguaggi di programmazione ad alto livello (quindi imparziali) e tirare le conclusioni solo dopo molti tentativi. Possiamo, a questo punto, capovolgere tutto il discorso finora fatto e tentare di valutare le performance di processor diversi non piu' partendo dalle istruzioni dei singoli processori e dalla loro velocità di esecuzione, ma da un determinato benchmark che... andiamo ad eseguire. Si esprime ancora in MIPS, ma la I non indica le istruzioni del processore testato, ma istruzioni fittizie, uguali per tutti i processor. Prendiamo ora un benchmark, contiamo quante istruzioni sono state eseguite da ogni processore per portarlo a termine. Per semplicità, al processore che ha adoperato il numero minore di istruzioni applichiamo la costante 1 e calcoliamo per gli altri processori, in proèporzione le relative costanti. Se ad esempio il secondo processore ha impiegato il 20% di istruzioni in piu' la sua costante sarà 1.2 se fosse stato il 35% la sua costante sarebbe stata 1.35 e cosi' via. Si noti che come processor campione possiamo anche adoperarne uno fittizio, che immaginiamo abbia eseguito il test in un numero ancora minore di operazioni, oppure possiamo appioppare la costante 1 non piu' "economo" ma ad uno qualsiasi dei processor in lizza, nel qualcaso avremo costanti possono variare (e sicuramente variano e non di poco) se partiamo da un benchmark diveso: in teoria si potrebbe anche azzardare un valore medio per questo K al "variare" del benchmark, ma se lo scarto comincia ad essere troppo variabile conviene non fidarsi troppo... e lasciare perdere con le valutazioni assolute. Tornando ai nostri calcoli, occorre stabilire il numero medio di cicli di macchina che ogni processore impiega per eseguire una istruzione e, naturalmente, occorre sapere la velocità dei clock dei singoli processori. La formula finale è mostrata in figura XX. In figura YY (fonte Sun Microsystems) sono riportate le performance "normalizzate" di tre architetture processor che hanno fatto e faranno storia nell'informatica moderna: 68030, 80386 e i nuovissimi SPARC. Buona Pasqua!
Articolo pubblicato su www.digiTANTO.it - per ulteriori informazioni clicca qui |
