Alla Merced di Intel? Un'occhiata all'architettura IA-64, per (s)cavalcare il 2000 Caratteristiche principali della nuova famiglia di processori Intel - E gli altri? di Fernando Carello La dinastia i386, ovvero il predominio dell'architettura Intel 32 bit iniziata nel 1985 con l'uscita dell'80386, sembra stia per finire ... ma solo per dare il 'LA' ad un nuovo predominio, forse ancora più netto: quello dell'architettura IA-64 che verrà inaugurata dall'Intel Merced, primo processore Intel a 64 bit. Verso la fine del 1999, infatti, verrà introdotta sul mercato una nuova famiglia di processori nata dalla collaborazione tra Intel e Hewlett-Packard: la prima ha portato il patrimonio genetico x86, mentre la seconda ha fornito i cromosomi dell'architettura RISC HP-PA (Precision Architecture); i processori della famiglia Merced saranno infatti figli di un matrimonio a prima vista impossibile, tra la più famosa e longeva delle famiglie CISC a 32 bit (nonché la più importante famiglia di CPU della storia) ed una delle più sofisticate stirpi RISC a 64 bit. L'inserimento sarà graduale (CPU Intel a 32 bit continueranno ad essere prodotte anche oltre il 2000, visti anche i prezzi inizialmente elevati dei nuovi venuti), ma segnerà una svolta molto importante nella filosofia Intel. In grado di eseguire sia il codice binario Intel che quello HP-PA, i nuovi processori potranno usufruire di un parco software di dimensioni impressionanti, promettendo nel contempo prestazioni di tutto rispetto. Rimandandovi alle note tecniche per un breve esame della nuova architettura, apriamo qui qualche spunto di dibattito ... Ad oggi, diverse grandi famiglie di processori si contendono il mercato di PC, Workstation e Server: le RISC ALPHA, PowerPC, HP-PA, SPARC, MIPS e la CISC x86 (nonostante ultimamente le CPU Intel PentiumPro e PentiumII abbiano adottato un'architettura mista, con un nucleo RISC). Ciascuna di queste architetture ha i suoi pregi e i suoi difetti, ciascuna di queste architetture ha richiesto, e continua a richiedere, uno sforzo economico e progettuale notevole per poter reggere la competizione sul parametro prezzo/prestazioni. Con l'industria sempre più attenta alle economie di scala, una simile proliferazione di architetture diverse è alquanto critica: non solo i produttori di CPU devono continuare ad investire sulla propria creatura per mantenerla competitiva, ma altresì i produttori finali (dalla motherboard al supercomputer) devono seguire più fronti, ingegneristicamente incompatibili, se non vogliono "chiudersi" su una sola architettura. Per non parlare dei produttori di Sistemi Operativi: ad oggi il solo Linux è riuscito a "portarsi" completamente e con successo su almeno 4 piattaforme diverse (x86, Sparc, Alpha, PowerPC), mentre per altri sistemi la "scommessa multipiattaforma" è stata persa (WindowsNT su tutti: oggi esiste solo per x86 ed Alpha). Il discorso vale, ovviamente, per tutti i produttori di software. Visto in quest'ottica, l'accordo tra Intel e Hewlett-Packard suona assai meno strano: con i due giganti ad investire su un'architettura comune, per i produttori hardware e software si apre la possibilità di investire una volta sola, e su un sistema apparentemente ben corazzato. Naturalmente, ci sono gli interrogativi d'obbligo in casi come questi: andrà tutto bene nel rapporto tra i due colossi? Il Merced sarà competitivo nel rapporto prezzo/prestazioni? Sarà progettualmente robusto, e saprà soddisfare le esigenze del mercato? Sarà disponibile in tempo e senza bug significativi? Ad ogni modo la strada è tracciata, e nulla esclude che altri la seguano ... tanto per cominciare, Sun Microsystems ha annunciato (destando una certa sorpresa, visti i rapporti di feroce concorrenza con Intel e specialmente HP) che porterà il proprio sistema operativo Solaris a 64 bit sul Merced; ciò significa che il più importante degli Unixoidi sarà disponibile su PC, Workstation e Server basati su Merced, aggiungendosi ad HP-UX e prevedibilmente a Linux, BSD e FreeBSD, UnixWare. Clamorosamente, il primo sistema operativo "nativo" a 64 bit per il nuovo Merced potrebbe non essere WindowsNT ! In realtà, l'annuncio di Sun fa riflettere: una volta portato Solaris sulla nuova architettura, e ammettendo che Merced soddisfi le aspettative, non sarebbe granché strano se l'architettura Sparc venisse pian piano abbandonata quanto meno per una certa fascia delle workstation, tagliando un bel po' di costi e rischi d'impresa. Approfondiamo questo concetto... Nei primi anni della propria vita (siamo agli inizi degli anni Ottanta), Sun costruiva workstation senza costruire CPU: la propria linea di prodotti si basava infatti sull'architettura Motorola 68000. Ad un certo punto, però, lo sviluppo delle CPU 68K non fu abbastanza veloce da assecondare le necessità prestazionali della Sun, che abbracciò il progetto Sparc - a quell'epoca poco più che uno studio accademico. Oggi, le migliori CPU Sparc (UltraSparc-II), tutte a 64 bit, sono caratterizzate da ottime prestazioni e una buona scalabilità; ma il loro sviluppo assorbe una grossa fetta delle risorse finanziarie Sun, profondamente impegnata sul fronte del software (Solaris e Java) e dell'hardware, con nuove linee workstation e server caratterizzate da un notevole sforzo progettuale per l'abbattimento dei costi. Se il Merced dovesse effettivamente promettere ciò che mantiene Sun potrebbe concentrarsi altrove: mantenendo l'architettura Sparc multiprocessore sui server di fascia alta, potrebbe adottare la piattaforma Merced per i segmenti di mercato dove più forte è la concorrenza Wintel, tornando alla sua primitiva vocazione: offrire prodotti a valore aggiunto, senza per forza costruirsi tutto in casa. Su un altro fronte, Intel e Digital hanno concluso anni di attriti siglando un accordo che vede Intel acquisire i diritti di produzione della tecnologia Alpha, nonché i veri e propri stabilimenti di produzione dei chip. Pur senza combinare questa notizia con la clamorosa acquisizione della stessa Digital da parte di Compaq, viene spontaneo chiedersi che fine faranno Digital Unix ed Alpha; ma è una domanda probabilmente prematura. Samsung, il colosso coreano licenziatario e produttore di CPU Alpha, ha infatti affinato le armi, annunciando che la nuova linea di processori (21264) arriverà prima del previsto -probabilmente verso la fine del 1998- al traguardo dei 1000 MHz (con tecnologia 0.25 micron, che passerà a 0.18 micron per la fine del 1999); le dichiarazioni parlano di rapporto prezzo/prestazioni migliore di quello del Merced, almeno per i primi tempi (si prevede che le prime versioni del Merced non spingeranno particolarmente sul fronte prestazionale). Sommando questo alla comprovata scalabilità dell'architettura Alpha (sono correntemente in vendita server DEC con 14 CPU), non sembra azzardato prevedere un certo vantaggio per queste CPU nella fascia alta di mercato & Peraltro, il settore low-end vede AMD preparare la sua nuova linea di processori - K7 - proprio sull'architettura di bus Alpha: magari potremo installare sulla nostra scheda madre indifferentemente un appetibile K7 o un Alpha "da competizione" ? Passando al sistema operativo Digital Unix, un recente accordo con Sequent (il produttore di supercomputer paralleli Numa) dovrebbe preludere alla nascita di un nuovo sistema operativo Unix comune per le due società, da sviluppare subito sull'onnipresente Merced. Più oscuro il futuro per le altre famiglie di CPU: se Silicon Graphics ha annunciato la nascita di una linea di workstation con sistema operativo NT, non è ben chiaro cosa intenda fare sul fronte hardware. Oggi le stazioni grafiche SGI puntano ad una fascia di mercato posizionata piuttosto in alto, e subiscono dal basso l'aggressione delle nuove workstation Sun Ultra20 e Ultra60 basate su UltraSparcII e sistema grafico Creator3D, caratterizzate da un competitivo rapporto prezzo/prestazioni. Notando uno sviluppo delle CPU MIPS apparentemente meno rapido rispetto alla concorrenza, non sarebbe troppo strano se SGI introducesse una nuova linea di workstation economiche basate sul Merced, probabilmente abbinato a WindowsNT visto che finora non si è parlato di porting su Merced del sistema operativo Irix E PowerPC? Da un po' di tempo sembra sia calata l'attenzione della stampa verso questa famiglia di processori RISC sviluppata da IBM e Motorola. Eppure i PowerPC sono gli unici ad essere montati su una gamma di elaboratori che va notebook ai grandi server aziendali multiprocessore (IBM AS/400). L'ultimo nato è il PowerPC 750 a 300 MHz, che consacra la nuova famiglia 750 (a basso consumo) anche sul fronte prestazionale: le sue prestazioni sono superiori a quelle del 604e 350 MHz, finora il processore più veloce del mondo sugli interi secondo gli indici BYTEMark (che lo portano addirittura davanti all'Alpha 600 MHz). Le ultime notizie dicono che IBM continuerà ad occuparsi dello sviluppo dei processori per workstation e server, mentre Motorola si concentrerà sul settore dell'embedded, dunque processori per PDA, prodotti TelCo ed applicazioni industriali. Difficile, tuttavia, dire quale sia il futuro di questi processori nel mainstream di PC, workstation e server. Fermo restando che il mercato di PowerMac ed AS/400 è ben radicato in certe fasce d'utenza, i numeri mossi e le prospettive di crescita non sembrano tali da fare del PowerPC un valido concorrente del Merced. Ma l'architettura IA-64 sarà davvero la mattatrice dell'inizio del nuovo millennio? Diversi interrogativi pesano su di essa, e sono squisitamente da "mondo reale". Anzitutto va sottolineato come, per sfruttare appieno le eccezionali potenzialità del Merced, i compilatori dovranno davvero fare un salto in avanti: ad essi è infatti demandato, più ancora che per i RISC, l'onere maggiore; dovranno produrre un codice in grado di soddisfare difficilissime esigenze, dovranno essere multi-target perché ogni processore della famiglia IA-64 sarà diverso dall'altro, dovranno conoscere le parti più intime dell'architettura di questi nuovi processori. Naturalmente, per soddisfare le esigenze del mercato dovrà esserci una collaborazione strettissima tra gli sviluppatori di compilatori e i progettisti delle CPU IA-64. Ci sarà ancora spazio per il free software di qualità? Se qualcuno di voi conosce l'ambiente Unix, non ignorerà certo l'importanza dei tool gratuitamente messi a disposizione da vari gruppi di sviluppo; primo fra tutti, il celeberrimo GNU C/C++, altrimenti noto come "gcc" e "g++". Questo compilatore con relativo toolset, sviluppato dalla Free Software Fundation nell'ambito del Progetto GNU (http://www.gnu.org), ha rappresentato e sempre più rappresenta l'ancora di salvezza e lo "swiss army knife" di un'intera generazione di programmatori e sistemisti, che hanno trovato in esso un valido sostituto, per di più gratuito e completo di sorgenti, ai più blasonati (ma non necessariamente migliori) prodotti "di marca". Il GCC ha spesso dimostrato di poter generare codice efficiente quanto quello dei compilatori commerciali, quando non addirittura migliore; ma sarà ancora così con i processori IA-64 ? Sarà possibile, per un gruppo di volontari senza scopo di lucro, sopportare l'enorme sforzo necessario a produrre un valido ambiente di sviluppo per la nuova architettura ? Godranno di tutta l'assistenza tecnica Intel come le controparti commerciali o verranno lasciati da soli ? Se il GCC dovesse segnare il passo, cosa ne sarà dei sistemi operativi freeware di enorme successo, quali Linux e FreeBSD ? Probabilmente si tratta di preoccupazioni eccessive: i team di sviluppo che hanno dato vita a questi importantissimi progetti hanno più volte dimostrato di poter supplire con la ricerca ed il talento alle lacune dovute al fatto di non essere nel "giro commerciale"; ma è indubbio che la sfida sarà durissima. Noi possiamo solo augurarci che, pur nell'ottica benefica di una maggiore interscambiabilità tra i sistemi e di una maggiore standardizzazione delle architetture, la salutare concorrenza tra produttori non rimanga soffocata dalla nuova stirpe Intel: come si vede oggi con diversi prodotti Microsoft (così come in passato con i prodotti IBM), il monopolio spesso porta solo effimeri benefici, mentre alla lunga può guastare il mercato e ridurre molto la libertà dei consumatori. La tecnica nel Merced La piattaforma IA-64 è stata congiuntamente sviluppata da Intel ed HP nel corso di circa tre anni; una gestazione così lunga appare senz'altro adeguata quando si analizzino le numerose innovazioni strutturali del Merced rispetto ai suoi predecessori. Prima, però, facciamo una breve panoramica all'indietro, guardando l'evoluzione nel corso degli anni '90 delle architetture CPU per sistemi desktop e server. La rigida suddivisione tra sistemi RISC e sistemi CISC caratteristica dei primi anni '90 è andata man mano sfumando: da un lato, piattaforme tradizionalmente CISC quali la x86 hanno visto l'apparizione di modelli "ibridi", con un cuore RISC servito da logica di decodifica in grado di supportare tutto il set di istruzioni delle precedenti generazioni (che più CISC non si può); dall'altro lato, gran parte delle CPU RISC sono enormemente cresciute in complessità per migliorare l'efficienza d'esecuzione delle istruzioni, potendo così mantenersi su frequenze di clock relativamente basse (logica diametralmente opposta rispetto all'architettura ALPHA, che privilegia la semplicità permettendo il raggiungimento di frequenze elevatissime, a prezzo tuttavia di notevoli complicazioni dal punto di vista termoelettrico). Tutte le architetture, comunque, hanno tre nemici comuni: La sequenzialità del codice (con relative dipendenze temporali tra le istruzioni), che impedisce il pieno sfruttamento del parallelismo interno su cui tutte le moderne CPU sono basate La non linearità del flusso delle istruzioni, interrotto da salti (branches) che abbassano l'efficienza funzionale delle pipeline presenti nelle unità di esecuzione La lentezza delle memorie, che penalizza le prestazioni quando ci siano molti accessi a dati non presenti nelle varie cache integrate nelle CPU Lo sviluppo della famiglia IA-64 ha come obiettivo la massima riduzione di queste tre cause d'inefficienza, garantendo un salto prestazionale di rilievo rispetto ai processori della generazione precedente senza perdere la compatibilità con il codice binario delle famiglie che è chiamata a sostituire (Intel x86 ed HP PA-RISC). La filosofia di base per centrare questi obiettivi richiama quella d'esordio delle architetture RISC: spostare la complessità fuori dai chip e dentro i compilatori. Vediamo dunque quali strategie adotta il Merced per affrontare i tre problemi sopra descritti: Parallelismo Il Merced sarà un processore superscalare, in grado di eseguire almeno 5 istruzioni per ciclo di clock. A differenza delle CPU odierne, però, non avrà a bordo molta logica per trovare ed eliminare le dipendenze incrociate tra le istruzioni: sarà un compito del compilatore, che dovrà riorganizzare il susseguirsi delle istruzioni in modo tale che queste possano essere combinate in "pacchetti" da 128 bit senza dipendenze interne; le istruzioni in questi pacchetti verranno quasi sempre eseguite dal Merced in modo parallelo (sarà sempre il compilatore ad indicare quali, settando in modo opportuno alcuni bit all'interno del pacchetto), come se ciascun pacchetto non fosse altro che una sola istruzione RISC. Questa caratteristica ha spesso portato a considerare il Merced come esempio di architettura VLIW - Very Long Instruction Word - , il che però è probabilmente una forzatura, visto che un "pacchetto" contiene in realtà 3 istruzioni. Risoluzione dei salti Anche il Merced, come tutte le CPU moderne, ha le unità di esecuzione organizzate in pipeline, una successione di unità elementari in grado di operare in parallelo sulla sequenza di istruzioni e dati. Questa architettura funziona molto bene quando il flusso del programma è lineare; quando c'è un salto, la catena si rompe e la pipeline si svuota. Per questo motivo, oggi una certa parte del silicio di una CPU è occupata da logica di predizione dei salti, spesso assistita da una memoria che tiene traccia del comportamento del programma in esecuzione. La predizione dei salti ha spesso buona efficienza, e gli errori difficilmente superano il 10%; tuttavia, essi sono sufficienti a penalizzare le prestazioni anche del 30%. L'architettura IA-64 introduce una funzionalità denominata esecuzione predicata: anziché offrire una previsione di salto (che, se sbagliata, dovrà essere scartata, perdendo cicli per prendere l'altra direzione), la CPU si predispone a seguire indifferentemente l'una o l'altra possibilità, in modo parallelo: qualunque sia il risultato del salto, non sarà necessario fermarsi e svuotare la pipeline, basterà semplicemente ignorare il percorso sbagliato e proseguire con quello giusto. Naturalmente, questo richiede particolare efficienza nella gestione di percorsi paralleli, ed una grande quantità di registri per immagazzinare i dati di ciascun flusso: proprio il contrario delle vecchie CPU x86, che proprio nello scarso numero di registri avevano la principale penalizzazione. Il Merced avrà 128 registri di uso generico, e 128 registri dedicati al floating point (altro settore tradizionalmente debole per le x86): ciò è possibile grazie anche allo spazio risparmiato non implementando sofisticate circuiterie di branch prediction. Accessi alla memoria Il gap di velocità tra memorie e processori continua a crescere; quando il Merced arriverà sul mercato, verso la fine del 1999, le frequenze tipiche delle CPU saranno dell'ordine dei 700-800 MHz, e tale sarà probabilmente anche la frequenza di clock dei primi Merced (che verranno costruiti con tecnologia da 0.18 micron). Se è vero che l'adozione di memorie cache sempre più grandi aiuta, va anche detto che c'è un limite alla quantità di silicio che si può "sprecare" per implementarle: con l'aumentare delle frequenze, è fondamentale che le dimensioni dei chip si mantengano molto contenute per tenere a bada i tempi di propagazione dei segnali al loro interno; già oggi, la cache integrata occupa una quantità di spazio circa pari a quello delle unità di esecuzione. Per migliorare l'efficienza degli accessi alla memoria, la famiglia IA-64 adotta una tecnica denominata caricamento speculativo. Si tratta di una sofisticata variante delle note tecniche di read-ahead già ampiamente usate, assistita però dal compilatore: quest'ultimo, durante la compilazione, esplora il codice alla ricerca di punti in cui è probabile la necessità di un accesso a memoria; quando genera il codice binario, inserisce in anticipo un'istruzione di lettura dalla memoria, in modo tale che il dato sarà già stato caricato quando servirà. Un'istruzione di controllo (sempre inserita dal compilatore) si accerterà al momento giusto dell'effettiva necessità di usare quel dato, che altrimenti verrà scartato. Fernando Carello è raggiungibile via Internet all'indirizzo fcarello@nice.net e tramite la redazione.