di  -  mercoledì 5 agosto 2009

In un paio di articoli precedenti abbiamo trattato il tema della “classificazione”, rispettivamente, di un sistema e di una CPU (o processore in generale) in termini di “bit”.

Tolti di mezzo i meccanismi psicologici di appagamento & tutela del prodotto acquistato da parte di un consumatore e quelli che portano i markettari a sparare quanto più in alto possibile, appare in ogni caso evidente che, dall’invenzione dei primi calcolatori elettronici in poi, abbiamo assistito a un generale aumento delle capacità dei processori di manipolare informazioni costituite da sempre “più bit”.

Non è un caso se oggi ci troviamo immersi nell’era dei sistemi a 64 bit (che fra qualche anno diventeranno i soli a esser venduti) quando fino a qualche anno fa gli unici presenti erano quelli a 32 bit, e i 64 bit appartenevano alla fantasia e a server di fascia alta fino ad arrivare ai supercomputer.

Ma siamo sicuri che servano realmente? E, soprattutto, siamo sicuri che poter manipolare dati “con più bit” migliori le prestazioni?

Chi è passato in mezzo alla “guerra dei Mhz” combattuta da Apple prima coi suoi PowerPC e da AMD poi con gli Athlon, sempre nei confronti dell’onnipresente Intel, sa già che “più Mhz” non implica necessariamente più “velocità”, e a buon ragione lo dimostrano i risultati dell’esecuzione delle applicazioni real world e… la fine dell’architettura NetBurst.

La questione non è così semplice e ci sarebbe da spiegare e ricordare un po’ di cose, ma il tema su cui mi voglio soffermare oggi è quello dei “bit”, non dei “Mhz” (e poi in un passato non ancora remoto se n’è parlato in abbondanza), per i quali le considerazioni sono comunque le stesse, come avremo modo di appurare.

Prima di tutto è necessario definire bene il significato di informazione “a n bit”, visto che ne esistono sostanzialmente di due tipi all’interno di un processore: i dati e gli indirizzi, e il numero di bit attribuibili a ciascuno possono benissimo essere diversi. Ad esempio il 6502 poteva manipolare dati a 8 bit, ma aveva indirizzi a 16 bit.

Questa distinzione è importante perché il primo tipo di informazione riguarda le capacità di calcolo vere e proprie (sto volutamente semplificando il discorso, senza citare unità SIMD et similia), mentre il secondo è associato alla capacità di indirizzamento della memoria.

Ecco perché un microprocessore a 8 bit poteva eseguire calcoli con interi da 0 a 255 (o da -128 a 127, se consideriamo gli 8 bit con segno), ma aveva la necessità di poter indirizzare più di 256 locazioni di memoria: erano veramente troppo poche per realizzare qualcosa di utile.

Come ci si poteva intuitivamente aspettare, aumentando il numero di bit per manipolare informazioni aumentano anche i problemi. Ad esempio, gestire puntatori a 16 bit nel 6502 aveva un costo maggiore rispetto alla manipolazione dei dati a 8 bit, e questo perché:

  • l’interfaccia verso la memoria era a 8 bit, per cui prelevare o memorizzare quantità a 16 bit comportava necessariamente due accessi a essa;
  • l’ALU a 8 bit veniva usata più volte per eseguire operazioni a 16 bit.

Tutto ciò si riflette in un maggior utilizzo di transistor (e, quindi, anche di costi di progettazione e produzione), consumo di corrente, dissipazione di calore, spazio, e possono avere ripercursioni anche sulle prestazioni della CPU. Si tratta, in ogni caso, di un “male” necessario (mentre alla fine parlerò di un caso del tutto diverso), per quanto detto prima.

Considerato che l’articolo è incentrato sulle prestazioni legate all’aumento del numero dei bit, potremmo pensare a delle soluzioni per cercare di eliminare o comunque migliorare questo problema per il 6502. Le medesime considerazioni saranno applicabili anche ad altri microprocessori, con i dovuti “aggiustamenti” (è il concetto che m’interessa esporre).

Per quanto riguarda i calcoli a 16 bit, la soluzione è molto semplice: basta realizzare un’ALU in grado di eseguire operazioni a 8 e 16 bit in un solo ciclo di clock. Cosa abbastanza comune per le CPU a 16 bit, ma che richiede molti più transistor e una modifica dell’architettura interna del 6502 (il cui bus dati interno era esclusivamente a 8 bit, come potete vedere dalla pagina 2 del datasheet).

Anche per l’accesso in memoria a 16 bit la soluzione sembra banale e a portata di mano: sarebbe sufficiente realizzare un bus dati (interno ed esterno) a 16 bit, com’è stato fatto per il 68000, ad esempio, al costo di un’interfaccia esterna più complicata (dev’essere possibile leggere e scrivere dati indifferentemente a 8 bit o 16 bit).

In realtà si tratta di una soluzione parziale, poiché rimane valida esclusivamente per letture o scritture di dati a 16 bit che siano allineati a questa quantità di bit. Questo significa che va benissimo l’accesso a un indirizzo pari (ad esempio $C0DE), ma non per uno dispari (ad esempio $0BAD).

Infatti in quest’ultimo caso il byte meno significativo (il 6502 è un processore little-endian) del dato a 16 bit a cui si vuole accedere si trova nel byte alto della locazione a 16 bit $0BAC, mentre quello più significativo in quello basso della successiva $0BAE (sempre a 16 bit).

Statisticamente parlando, però, abbiamo ottenuto mezza soluzione al problema. Il 68000 lo risolve definitivamente e in maniera elegante (si fa per dire, visto che è assolutamente dispotico): non permette l’accesso di dati a 16 bit a indirizzi dispari, pena il sollevamento di un’eccezione address error.

Soluzione applicabile anche al 6502, ma imponendo però limitazioni alla sua ISA. In primo luogo obbligando i programmatori a utilizzare esclusivamente locazioni pari nelle modalità d’indirizzamento indiretto (le uniche che consentono di prelevare quantità a 16 bit in maniera programmatica), e forzando lo stack a indirizzi sempre a 16 bit memorizzandovi esclusivamente valori di questa dimensione.

Ma se per i programmatori la prima parte è abbordabile (si tratta di organizzare in maniera opportuna le 256 locazioni di memoria utilizzabili allo scopo), forzare lo stack a indirizzi e dati sempre a 16 bit porrebbe troppe limitazioni.

Infatti lo stack è costituito da soli 256 byte, e in questo modo consentirebbe di memorizzare soltanto 128 valori, anche se la stragrande maggioranza dello scambio di dati avviene per quantità a 8 bit (non a caso il 6502 è una CPU a 8 bit). Portare la dimensione dello stack a 512 byte sarebbe un’altra soluzione, ma si sprecherebbe troppo spazio.

Situazioni del genere esistono per tanti altri microprocessori. Ad esempio il 68000 ha all’incirca lo stesso problema del 6502: è un microprocessore a 32 bit, ma con un bus dati esterno a 16 bit, per cui accedere a dati o indirizzi a 32 bit comporta necessariamente due accessi alla memoria.

Altri processori presentano problemi con l’allineamento dei dati, similmente al 68000. Infatti, pur disponendo di bus dati in grado di leggere o scrivere dati e/o indirizzi della stessa dimensione dei rispettivi registri interni, sono in grado di farlo esclusivamente per indirizzi allineati alla medesima quantità. E’ una scelta comune a molti RISC, come ARM e PowerPC (giusto per citare due fra i più comuni rappresentanti della categoria).

Altre CPU, come gli 80×86, non impongono limitazioni di questo tipo (è possibile comunque forzarne il funzionamento in modo da obbligare a effettuare accessi allineati), ma in questo caso le prestazioni ne risentiranno in presenza di accesso a indirizzi disallineati (rispetto alla dimensione del dato), e per questo motivo in tutti i manuali riguardanti l’ottimizzazione per questa ISA è consigliato allineare opportunamente i dati.

Rimane in piedi la domanda posta a inizio articolo: più bit equivale a migliori prestazioni? Non sempre: dipende tutto dai problemi che devono essere risolti dalle applicazioni (e sarebbe opportuno scegliere sempre dimensione dei dati adeguate a ciò che realmente serve). Anzi, a seconda dell’ISA, più bit può equivalere a un decadimento della velocità di esecuzione.

Sembra strano, se consideriamo che il passaggio dai 32 bit ai 64 bit per l’architettura x86 ha comportato mediamente un miglioramento del 10-15% dei tempi di calcolo, e il motivo per cui ciò non si ripete con altre architetture è presto detto: con x86-64 AMD non ha semplicemente portato la dimensione dei registri da 32 a 64 bit, ma ha apportato all’ISA notevoli altre migliorie che hanno ammortizzato (e mediamente anche superato) la penalizzazione dovuta a tale passaggio.

Infatti il solo “allargamento” dei registri comporta sempre un peggioramento delle prestazioni, dovuto a un aumento dei tempi di context switch, a un maggior consumo di spazio, di banda in lettura / scrittura verso la memoria ed eventuali cache causata dalla dimensione doppia dei puntatori (tipologia di dati fortemente utilizzata nelle applicazioni), e di page fault e TLB miss (entrambi a causa del maggior spazio richiesto).

Ecco perché utilizzare un G5 di IBM in modalità a 32 o a 64 bit comporta in quest’ultimo caso un decadimento delle prestazioni, se non si fa specifico utilizzo delle capacità di elaborazione a 64 bit e/o non si utilizzano più di 4GB di memoria, come si può notare dalle due pagine dedicate a Tiger e alla scrittura delle applicazioni a 64 bit.

Tiger, infatti, è stata la prima versione di OS X in grado di supportare applicazioni a 64 bit per i G5, ma Apple ne ha fortemente sconsigliato l’utilizzo, se non per particolari e ben precisi ambiti applicativi (estremamente limitati e contorti, se consideriamo che, ad esempio, non era possibile realizzare applicazioni interamente a 64 bit; cosa che sarà possibile soltanto con Snow Leopard, che è alle porte), proprio per le negative ricadute sul fronte prestazionale.

Come per il 6502, anche per il G5 (e altri microprocessori che hanno avuto all’incirca gli stessi problemi, come i MIPS e gli SPARC, ad esempio), si possono prevedere delle soluzioni adeguate quanto meno per contenere l’impatto dell’aumentata dimensione dei registri, ma aumentare la dimensione del bus dati, delle cache, il numero delle entry nella cache TLB, ecc. non è cosa semplice e, soprattutto, può essere particolarmente dispendioso.

Si tratta, in definitiva, di trovare sempre il giusto compromesso, una soluzione che cerchi di bilanciare tutte le variabili in gioco. Appare, quindi, particolarmente strana la decisione di IBM/Sony/Toshiba da un lato e di IBM/Microsoft dall’altro, di dotare la PlayStation 3 e la XBox 360 di CPU a 64 bit (e qui mi riallaccio a quanto detto sopra sul male “necessario”).

Si tratta di console dotate di 512MB di RAM (29 bit d’indirizzamento necessari), e per le quali mi sembra alquanto difficile ipotizzare che abbiano avuto un “massivo” bisogno di manipolare dati a 64 bit. Dunque perché non sviluppare Cell e Xenon sulla base dell’ISA a 32 bit dei PowerPC, eliminando gli svantaggi di cui parlavo prima?

Un altro mistero che si va ad aggiungere alla storia dell’informatica…

13 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    StreamX
     scrive: 

    Perché il Cell finanziato anche da IBM doveva fornire capacità DP, per coprire il settore delle workstation finanziarie/scientifiche.

    A Sony/Toshiba serviva un processore per la manipolazione dei pixel nel settore dell’elettronica di consumo.

    Lo Xenon invece nasce come processore a basso costo, quindi la base di partenza era sempre il PPE del Cell, non si richiedeva da contratto uno sviluppo dedicato se non per le estensioni VMX. Gli altri processori IBM avevano prestazioni integer sovradimensionate(logica OOO) e clock inferiori.

  • # 2
    banryu79
     scrive: 

    Complimenti Cesare,
    i tuoi articoli sono sempre interessantissimi, e densi di informazioni, quando ho tempo li leggo sempre volentieri.

  • # 3
    spannocchiatore
     scrive: 

    imho, uno dei migliori articoli mai letti su AD.
    complimenti!!

  • # 4
    pek
     scrive: 

    …perchè 64 è sempre meglio di 32!
    sai che smacco per il marketing?

    ps3 -> cpu Cell a 64bit
    x360 -> ppc a 32 bit – KE SKARSOOOOOO!!!!!

  • # 5
    pleg
     scrive: 

    Aggiungo un altro motivo per cui aumentare il numero di bit degli indirizzi puo’ essere dannoso: la traduzione degli indirizzi virtuali in indirizzi fisici diventa piu’ complessa e lenta (piu’ bit da tradurre), e questa traduzione potrebbe benissimo essere nel critical path della CPU e limitarne quindi la frequenza operativa. Inoltre, diventano analogamente piu’ complessi anche i meccanismi di memory disambiguation (load bypass & load forward, store sets…)

  • # 6
    Massive
     scrive: 

    Credo che il Cell sia stato pensato sin dall’inizio per qualcosa di più di una console, la PS3 è stata sfruttata per ridurre i costi (vendendo molti più processori) e la Sony ha sfruttato il Cell più come marketing che come CPU, ciò non toglie che potranno farlo per una nuova PS, forse.

  • # 7
    Dal mito dei Mhz a quello dei bit… | succoso
     scrive: 

    […] Dal mito dei Mhz a quello dei bit… […]

  • # 8
    Alessandro
     scrive: 

    Ottimo articolo, complimenti
    ma ora mi sorge un dubbio:
    premesse;
    – le attuali CPU sono (credo) a 64 bit (Intel/AMD)
    – ipotizzo “l´utilizzo di software a 64 bit” per SO a 64 bit
    – ipotizzo “l´utilizzo di software a 32 bit” per SO a 32 bit

    domanda:
    è meglio farle lavorare con un SO a 32 o a 64bit???
    con quale, considerando la loro architettura ottengo prestazioni migliori??

  • # 9
    The3D
     scrive: 

    Nel caso delle cpu x86/x64, l’utilizzo dell’ISA a 64 bit porta vantaggi prestazionali in alcuni casi notevoli. Questo fondamentalmente grazie a:

    -l’incremento nel numero di registri

    -L’utilizzo delle istruzioni SSE/SSE2 al posto delle classiche x87.

  • # 10
    Cesare Di Mauro
     scrive: 

    Innazitutto ringrazio per i complimenti e mi scuso per aver risposto soltanto adesso, ma… ero in ferie, e abbastanza lontano da PC e internet. :D

    @StreamX: ciò non toglie che per le console realizzare CPU a 64 bit sia stato più un costo e una perdita di prestazioni, che un vantaggio. Essendo hardware con un target ben preciso, mi aspetto che sia adeguatamente tarato.

    Comunque aspetto di vedere nuovi sistemi basati su Cell che abbiano più di 4GB di memoria.

    @pek: verissimo e ne avrei dovuto parlare in maniera più chiara. Mi rendo conto che il “TLB miss” che ho scritto è un po’ troppo generico.

    Comunque nelle CPU più moderne si tende ad aumentare la dimensione delle pagine, in modo da ridurre il numero dei livelli dell’albero e minimizzare quindi le traduzioni necessarie per ottenere l’indirizzo fisico.

    Non conosco, invece, il motivo per cui la memory disambiguation diventerebbe più complicata. E’ un aspetto che devo sicuramente approfondire. :-P

    @Massive: penso che la nuova PS(4?) sarà ancora una volta basata su Cell come CPU, anche se con frequenze elevate, e magari dei miglioramenti alle SPU. Sony ha investito troppo su questo progetto, e credo voglia cercare di sfruttarlo il più possibile.

    @The3D: esatto.

  • # 11
    pleg
     scrive: 

    @ Cesare di Mauro

    Ciao, con “memory disambiguation” intendevo ad es. i meccanismi di load bypass & load forward a livello dello store buffer.
    Brevissimamente un esempio: gli store completano in pipe quando scrivono non nella memoria, ma nel write buffer. In questo modo puoi accelerarli molto (invece di aspettare la lentissima memoria, li accumuli nel buffer, e li gestisci comodamente da li’, invece che dal datapath della pipe). Esempio di problema che questa cosa comporta: cosa succede se arriva un load ad un indirizzo, e c’e’ uno store pending nello store buffer a quello stesso indirizzo? Se permetti ai load di andare out-of-order rispetto agli store (cosa che ti da’ anche un 10-20% di prestazioni in piu’, in media), se il load andasse in memoria, prenderebbe il dato sbagliato. Quindi, il load deve prima controllare nello store buffer. Se c’e’ qualcosa li’, lo deve prelevare. Ma per farlo, deve confrontare gli indirizzi: quindi, salire da 32 a 64 bit per gli indirizzi significa comparatori piu’ grandi, piu’ lenti, eccetera.

  • # 12
    Cesare Di Mauro
     scrive: 

    Ah, ok. Adesso ho capito cosa intendi. E sono perfettamente d’accordo. :)

  • # 13
    Apple ri-scopre i 64 bit… - Appunti Digitali
     scrive: 

    […] uno dei miei precedenti articoli sul mito dei Mhz e dei bit ribadivo che quest’assunto non è sempre vero ma, anzi, può rivelarsi del tutto falso. Nel […]

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.