Guide: 32bit vs 64bit

[MarcoGT]

Scritta in origine da Filippo

Come di consueto, è bene fare un po' di riassunto storico.

I primi PC IBM, nei primissimi anni 80, erano equipaggiati con il mitico Intel 8086, o più probabilmente con il "fratello minore" 8088. I due processori erano pressoché identici, con la differenza principale nell'ampiezza del bus di comunicazione tra CPU e resto del computer, che nell'8086 era di 16 bit e nell'8088 di soli 8 bit. Nonostante l'8088 fosse quindi più lento a comunicare con l'esterno, era comunque preferito perché a quei tempi realizzare periferiche con bus di comunicazione a 16 bit era enormemente più costoso.

Quale che fosse la variante, l'8086/8088 era un processore a 16 bit. Cosa significa questa definizione? Purtroppo non è univoco il criterio a cui nei vari casi ci si affida per definire se una CPU è a 8/16/32/64 bit o che altro. Nel caso delle CPU x86 (quelle dei nostri PC) si è presa come riferimento l'ampiezza dei registri, ovvero quelle piccolissime memorie interne alla CPU che servono per immagazzinare i dati su cui operano le singole istruzioni macchina, nonché i risultati delle relative operazioni. L'8086/8088 aveva 8 registri a 16 bit, per cui è stato definito una CPU a 16 bit. Questi registri, oltre che contenere i dati delle classiche operazioni aritmetiche/logiche, potevano contenere gli indirizzi, ovvero numeri che individuano univocamente una delle varie celle di memoria contenenti le informazioni da elaborare.
Tramite un meccanismo di gestione della memoria definito "segmentazione", l'8086/8088 poteva indirizzare "ben" 1 MByte di RAM. Una quantità ridicola per gli standard di oggi, ma considerata enorme per l'epoca (famosa la dichiarazione di Bill Gates: "640 kBytes saranno sufficienti per qualsiasi necessità", anche se qualcuno sostiene che in realtà Bill non abbia mai pronunciato questa affermazione).

Anche il successore dell'8086, ovvero l'80286 (comunemente abbreviato in "286") era una CPU a 16 bit, la cui differenza sostanziale rispetto all'8086/8088 era l'introduzione della modalità di funzionamento cosiddetta "Protected Mode", che permetteva di indirizzare più memoria (16 MBytes) ed offriva un supporto hardware al multitasking (nel senso che la CPU poteva gestire la memoria in modo da tenere separate le aree di memoria assegnate ad applicazioni distinte).

Con l'80386, introdotto nel 1985, arrivarono finalmente i registri dati/indirizzi a 32 bit (anche se la variante 386SX era "castrata" e solamente 24 dei 32 bit erano utilizzabili per gli indirizzi) e migliorato la "Protected Mode" con un più articolato supporto al multitasking: meccanismo di paginazione della memoria, memoria virtuale (meccanismi il cui approfondimento esula dagli scopi di questa FAQ: vi basti sapere che la Protected Mode a 32 bit è la modalità di funzionamento della CPU comunemente impiegata in tutti i sistemi operativi moderni a 32 bit).

Dall'80386 in poi, l'ampiezza dei registri non è più cambiata, fino al Pentium 4 con core Prescott, il primo nel quale Intel ha proposto le estensioni a 64 bit scopiazzandole da AMD che le aveva già introdotte da oltre un anno sul proprio Athlon64.

Al momento attuale, tutte le CPU sia Intel che AMD supportano le cosiddette estensioni a 64 bit, meglio conosciute con l'acronimo "x64", che in sostanza consistono in un ulteriore ampliamento dei registri, portati a 64 bit di ampiezza, le relative nuove istruzioni macchina per processare dati e indirizzi a 64 bit, nonché il supporto hardware all'emulazione del funzionamento a 32 bit quando è operativa la modalità a 64 bit (supporto sfruttato da Windows e Linux a 64 bit per poter far funzionare le applicazioni a 32 bit).

Adesso forse vi sarà possibile capire meglio quando si parla di sistemi operativi a 32 e a 64 bit. Un sistema operativo a 32 bit è infatti un software che utilizza, come detto, la modalità Protected Mode a 32 bit dei processori 80386 e superiori. In questa modalità, le CPU x86 supportano il multitasking, il multithreading e sono in grado di processare dati e indirizzi a 32 bit. In particolare la possibilità di trattare indirizzi a 32 bit ci interessa, perché è da lì che nasce il limite, oggi ormai divenuto pesante, dei sistemi a 32 bit, ovvero la possibilità di gestire non più di 4 GB per applicazione.
Questo limite nasce da un elementare calcolo di aritmetica binaria: un bit rappresenta un valore che può essere 0 o 1, quindi 1 singolo bit può rappresentare 2 diversi valori. 32 bit potranno pertanto rappresentare 2^32 diversi valori, ovvero 4 miliardi e rotti. Poiché un indirizzo individua univocamente una cella di memoria, e nelle architetture x86 una cella contiene 1 byte, ne consegue che un indirizzo a 32 bit può "vedere" 4 miliardi e passa di bytes, ovvero i famigerati 4 GB.

Ecco perché è nata la tecnologia delle estensioni a 64 bit dei processori x86. Un indirizzo a 64 bit può vedere 2^64 bytes (vi lascio fare il conto...), e quindi il limite dei 4 GB è brutalmente superato.

Verrà mai un momento in cui 64 bit saranno pochi e dovremo passare a registri a 128 bit? Beh, sicuramente questo momento non verrà entro i prossimi 50 anni, credo Resta il fatto che dati a 64 bit possono essere ancora pochi per alcune applicazioni molto specifiche, in particolare la crittografia, in cui farebbero comodo registri ben più grossi, a 128, 256 o anche 512 bit. Ma se si escludono questi casi estremamente particolari, per il resto già processare dati a 32 bit soddisfa la quasi totalità delle esigenze "normali" (d'altra parte i nostri padri, e i più vecchi di noi, vivevano tranquillamente con MS-DOS e Windows 3.x che erano sistemi a 16 bit...).

Un sistema operativo a 64 bit utilizza la modalità di funzionamento delle nuove CPU Intel e AMD nella quale vengono processati dati e indirizzi a 64 bit; lo scopo di tutto ciò, come si sarà ormai capito, è essenzialmente quello di vedere più dei maledetti 4 GB di memoria; dopodiché, per carità, ci sono particolari ambiti che possono trarre giovamento dal processare dati a 64 bit invece che a 32... anche se spiegare esattamente in che senso c'è questo giovamento sarebbe un po' troppo tecnico. Magari alla prossima puntata...

...continua...

[MarcoGT]

...continua...

Avevo accennato al fatto che taluni contesti applicativi possono trarre giovamento dall'uso di dati a 64 bit invece che a 32, senza dire di più. Ebbene, magari qualche parolina per fare capire meglio questo discorso credo ci possa stare.

Partiamo da una considerazione di carattere generale. Lanciare (e di conseguenza utilizzare) un programma significa, stringi stringi, far eseguire alla CPU una sequenza di istruzioni che elaborano dati in varia maniera, per poi presentare i risultati di queste elaborazioni attraverso diversi canali di output (lo schermo, le casse audio, la stampante, ecc.).

Per quanto lunga e complicata possa essere la sequenza di istruzioni eseguite, alla fin fine le categorie di operazioni eseguite dalla CPU sono sempre quelle, ovvero:
Aritmetiche: come dice il nome, si tratta delle consuete operazioni di aritmetica che abbiamo imparato a scuola: addizioni, sottrazioni, prodotti e, a seconda della CPU, anche divisioni.
Logiche: questo tipo di operazioni è intimamente legato al fatto che la rappresentazione dei dati in un calcolatore avviene secondo il sistema binario, sistema che prevede una serie di operazioni tipiche e definite appunto logiche: AND, OR, NOT, XOR, NAND, NOR, ecc.
Load/store: queste operazioni non effettuano elaborazioni vere e proprie, bensì spostano i dati tra CPU e memoria.
Controllo: queste istruzioni hanno lo scopo principale di influenzare la sequenza di esecuzione delle altre istruzioni in funzione dell'avverarsi o meno di determinate condizioni. In questo genere di istruzioni rientrano ad esempio i classici "salti condizionati", ovvero comandi del tipo "vai all'istruzione XXX se..."

Esaminiamo in particolare le istruzioni aritmetiche e logiche, che sono quelle intorno a cui ruota tutto l'impianto di elaborazione di un'applicazione. Nell'architettura x86 dei processori dei nostri PC, queste istruzioni possono operare su dati di 8 o 16 bit (in tutte le CPU x86), o 32 bit (dal 386 in poi), oppure 64 bit (dall'Athlon64 e Pentium 4 serie 600 in poi, purché inizializzati per funzionare in modalità a 64 bit: questa inizializzazione è compito del sistema operativo). Allora, quand'è che abbiamo bisogno dei 64 bit?

Facciamo un passo indietro. Si diceva che 1 bit, che è l'unità più piccola di informazione che una CPU può elaborare, rappresenta solo due possibili valori, 0 e 1. Con 2 bit posso rappresentare 2*2=4 valori, con 3 bit 8 valori, e via di seguito. Con dati di 16 bit (gli unici che si potevano processare direttamente con le CPU x86 fino all'80286) posso rappresentare 2^16 = 65536 valori. A seconda di come uso questa rappresentazione, con 16 bit posso individuare un numero intero senza segno da 0 a 65535, oppure un numero intero con segno da -32768 a 32767.

A questo punto inizierete ad intuire il problema, ovvero: cosa succede se io devo fare dei conti i cui dati e risultati siano più grandi di questi valori massimi che posso rappresentare con 16 bit? Mi attacco? Beh, non proprio. Posso comunque fare i miei conti, ma devo "spezzarli" in più parti le quali possano essere portate avanti con numeri che rientrino nei valori rappresentabili in 16 bit. Ed ecco il fulcro del problema: se voglio far fare alla mia CPU calcoli su valori che superano il limite rappresentabile, posso farlo ma al costo di una sequenza più o meno lunga di istruzioni, invece che usarne una sola.

Senza star qui a dimostrarlo rigorosamente, però posso farvi questo esempio: supponiamo di voler moltiplicare tra loro due numeri di 16 bit. Il risultato sarà un numero di 32 bit. Con una CPU x86 a 32 bit possiamo fare questa operazione con un'unica istruzione aritmetica e 1 scrittura in memoria; con un ipotetico 80286, per ottenere lo stesso risultato, dovremmo invece fare 1 moltiplicazione e 2 scritture in memoria (visto che una CPU a 16 bit può leggere/scrivere 16 bit alla volta). E già per questo semplice esempio vediamo che una CPU a 32 bit deve fare un'operazione in meno (2 contro 3), con un risparmio del 33% sul tempo di esecuzione. Senza contare poi se il risultato di questa moltiplicazione dovesse venire impiegato in successive operazioni aritmetiche (per esempio una somma): nel caso della CPU a 32 bit potremmo direttamente usare il risultato in tutti i suoi 32 bit e fare la nostra somma; con una CPU a 16 bit dovremmo spezzare la somma a 32 bit in due somme da 16, che poi diventano 3 somme se teniamo conto che sommando i 16 bit che rappresentano la metà inferiore dei 32 bit potremmo ottenere un bit di riporto che andrebbe poi a sua volta sommato nei 16 bit della metà superiore.

Insomma, operazioni aritmetiche che superino la precisione massima supportata da una CPU sono sì fattibili, ma diventano un macello, con un peso prestazionale non indifferente.

Un'alternativa comoda per il programmatore è quella di usare i dati in virgola mobile (floating point) anche per fare calcoli su numeri interi. A partire dal Pentium Intel e dal K6 AMD, tutte le CPU hanno integrata una FPU (Floating Point Unit), ovvero un co-processore il cui scopo è quello di gestire specificamente i calcoli di numeri con la virgola. I numeri floating point permettono la rappresentazione di un range di valori enormemente più esteso di quelli rappresentabili con un intero. Ma a che prezzo: anche operazioni banali come le somme, se fatte con la FPU, sono più lente delle corrispondenti operazioni su interi. L'uso della FPU, quindi, è di fatto relegato solamente agli ambiti in cui la precisione dei calcoli è prioritaria rispetto alla velocità, e quindi parliamo dei calcoli scientifici, del rendering 3D, tanto per dirne due.

Ecco perché alcune applicazioni possono essere più veloci se si hanno a disposizione operazioni in grado di agire su dati a 64 bit invece che a 32: si tratta di risparmiare istruzioni, e fare quindi lo stesso conto più speditamente.

Senza contare che poter processare numeri interi a 64 bit apre un'altra interessante possibilità, ovvero (per talune applicazioni sulle quali la precisione è sì richiesta ma non è un must assoluto, e quindi ci si "accontenta" di precisioni inferiori a quelle della virgola mobile) l'uso della rappresentazione cosiddetta FIXED POINT. In pratica si tratta di dire: posso fare operazioni aritmetiche su numeri a 64 bit? Bene, allora dico che di questi 64 bit ne uso (per fare un esempio) 32 per rappresentare la parte intera e gli altri 32 per la parte decimale di un numero. Così facendo posso rappresentare, pur usando un numero intero, numeri con la virgola con una precisione di 2^(-32) = 0,00000000023 = 2,3*10^(-10) cioè un numero decimale con 9 cifre significative dopo la virgola, che non è poco. In più, con gli altri 32 bit posso rappresentare 2^32 = 4294967296 valori. Quindi con un numero Fixed Point a 64 bit di cui 32 per la parte intera e 32 per quella decimale posso rappresentare valori con la virgola che vanno da 0 a 4294967295,99999999977.

Con questa furbata posso permettermi di fare conti su numeri con la virgola (con i limiti di precisione che abbiamo appena visto in questo esempio) senza usare la FPU che è più lenta. Avendo a disposizione CPU a 32 bit, l'uso di questo sistema sarebbe stato meno raccomandabile: se dei 32 bit decidevo (per esempio) di destinarne 16 alla parte intera e gli altri 16 alla parte decimale, potevo rappresentare valori da 0 a 65535,999984, con una precisione di 0,000016 che è chiaramente mediocre, sicuramente insufficiente per molte applicazioni in ambito scientifico.

So che sono andato a scavare un argomento piuttosto ostico, che è quello delle approssimazioni dovute alla precisione finita della rappresentazione dei dati, però spero che questo possa far capire in che situazioni avere la possibilità di processare molti bit può tornare utile.