Gigabytes’ Blog

Ci siamo, finalmente è arrivato. Mac OS X 10.6 è giunto sugli scaffali e tutti gli utenti mac si stanno domandando se vale la pena aggiornare oppure no. Inutile dire che per 29€ (o anche 9€ per chi ha comprato un mac quest’estate, come me), porsi il problema non ha neanche senso.. Ma mettiamo pure che uno voglia farsi del male. Cosa mette sul piatto il nuovo felino? Si tratta di un aggiornamento volto al miglioramento delle performance e una rifinitura dei dettagli del sistema e dalle voci che girano sembra proprio che ci siano riusciti. Una delle cose più importanti su questo fronte è il supporto a 64bit. Su questo argomento c’è tanta confusione. Vedrò allora di fare un po’ di chiarezza qui, in modo da poter rispondere ai forum con un link invece che con un papiro ogni volta XD

Vantaggi nell’uso dei 64bit

Prima di tutto due parole sui 64bit in generale. Che vantaggi si ottengono eseguendo software a 64bit? Ecco una lista:

1. Supporto a più di 4GB di ram. Con uno spazio di indirizzamento di 32bit, la massima quantità di memoria virtuale indirizzabile è 2^32 byte, ovvero 4GB. 2^64, invece, è un limite quasi astrofisico, che non ci toccherà per un bel po’ di anni.
2. Matematica più veloce. Software scientifici, tecnici o multimediali richiedono spesso calcoli pesanti su grandi numeri. Un qualsiasi calcolo su numeri da 64bit, in modalità 32bit richiede due operazioni distinte e i risultati vanno poi combinati. E’ chiaro che una sola unica operazione a 64bit risulta più veloce.
3. Maggior numero di registri general purpose. Nei processori Intel, la modalità a 32bit limita all’utilizzo di soli 6 (sei!!) registri di uso generico, contro i 32 (ad esempio) dei PowerPC e i 128 di Sparc. Si tratta di un numero talmente esiguo che virtualmente qualsiasi operazione richiede accesso alla memoria per depositare risultati intermedi, il che rallenta. La modalità a 64bit mette a disposizione 16 registri a 64bit, ovvero 32 registri a 32bit se la matematica a 64bit non serve. Non è un numero esorbitante ma abbastanza per aumentare le performance.

Basandomi su questi effettivi vantaggi, ecco adesso due delle leggende metropolitane che sento in giro, e il perchè di tale appellativo:

1. In modalità a 32bit, non si possono usare più di 4GB di ram. Falso! Apple vende da anni computer MacPro e Xserve che supportano fino a 32GB di ram. Eppure fino a OS X 10.5 il sistema era a 32bit, allora com’è possibile? E’ possibile grazie a PAE, un’estensione delle CPU intel disponibile fin dal Pentium Pro, che permette di usare fino a 64GB di ram pur rimanendo in uno spazio di indirizzamento a 32bit. Con questo sistema il SO può gestire benissimo tutta la ram del sistema. Il limite dei 4GB è quindi vero solo nel contesto di un singolo processo, il che significa che il sistema gestisce tutta la ram che c’è ma un singolo processo non può usarne più di 4GB.
2. Fare calcoli a 64bit è più lento se non se ne ha bisogno. Inesatto! E’ logico pensare che per fare conti sul doppio dei dati porti via il doppio del tempo. Questo era vero in architetture RISC quali il PowerPC. Per questo motivo, infatti, nessuno sui G5 usava eseguibili a 64bit se non ne aveva veramente bisogno, ovvero se non aveva necessità di compiere tanti calcoli su grandi numeri. Sui processori intel questo discorso non sussiste, per due ragioni. Prima di tutto, la modalità a 32bit sugli intel è una modalità di retrocompatibilità. Le parti della CPU che fanno i calcoli sono sempre le stesse, e per logica, fanno comunque tutti i conti che devono su dati da 64bit. Semplicemente i 4byte alti sono nascosti al programmatore. Secondo, le CPU intel sono CISC (almeno all’apparenza). Questo significa che ogni istruzione ha una variante per ogni combinazione di dati in input. C’è un addizione tra un byte è una word, una tra due byte, una tra un numero a 32 e uno a 64, ecc… Ognuna di queste varianti genera opcode diversi che vengono gestiti in modo diverso, e si possono quindi evitare calcoli inutili.

Storia del supporto a 64bit in Mac OS X

Con la pubblicità che fanno a Snow Leopard adesso, sembrerebbe che il supporto ai 64bit venga introdotto solo ora, anni in ritardo rispetto alla concorrenza. Inoltre chi si ricorda la campagna pubblicitaria per Leopard, si ricoderà che il “supporto ai 64bit” era già stato sbandierato allora. Quindi come stanno le cose? Le cose stanno che OS X supporta i 64bit da parecchi anni, ma il supporto è stato introdotto per gradi. Pigrizia direte voi. Forse, ma forse i motivi tecnici sono maggiori. Vediamoli. Fino al 2006 i Mac utilizzavano processori PowerPC. Come già detto, il codice a 64bit sui PowerPC girava più lentamente di quello a 32bit, se non si trattava di codice che ne avesse espressmente bisogno. Che motivo c’era di eseguire codice a 64bit quindi? Nessuno. Apple ha comunque dovuto lasciare agli utenti la possibilità di sfruttare i 64bit del proprio G5, se ne aveva bisogno. Tiger ha introdotto quindi il supporto per gli eseguibili a 64bit. Tutto il sistema girava a 32bit, ma poteva eseguire software a 64bit. Per fare questo, ovviamente, serviva una versione a 64bit delle varie librerie di sistema. In Tiger le librerie disponibili a 64bit erano quelle del substrato BSD e Core Foundation, ovvero le librerie C. In Tiger era quindi possibile scrivere demoni, programmi background ecc… a 64bit.

Con Leopard sono andati avanti, introducendo il supporto ai 64bit per tutte le librerie di sistema, anche quelle riguardanti la grafica. Su Leopard quindi si possono eseguire programmi anche con GUI, a 64bit. Questo supporto però non è stato esteso alle librerie di sistema considerate “deprecate”. Queste includono il framework Carbon, usato agli inizi del decennio per la transizione delle applicazioni da OS 9 a OS X. Per questo motivo, Adobe CS4 non è disponibile a 64bit per mac: usa Carbon, e non esiste una versione a 64bit di Carbon. Adobe ha annunciato che la GUI della CS5 verrà riscritta usando Cocoa e sarà quindi disponibile a 64bit anche su mac (potevano sbrigarsi anche prima comunque, visto che le API di OS9 sono deprecate da 10 anni).

Cosa aggiungono quindi in Snow Leopard? La novità è che ora tutto il sistema è compilato a 64bit, comprese le applicazioni incluse. Questo ha senso ora, perchè i mac usano processori intel. Sarebbe stato controproducente 3 anni fa sui G5. Ci voleva un’intera release per far ciò? Non bastava ricompilare, adattando al massimo qualcosa? No, non bastava. Un numero incredibilmente alto di applicazioni di sistema usava ancora Carbon, almeno in parte, e quindi tutti questi componenti (compreso il Finder, il Dock, ecc..) sono stati riscritti da capo. La riscrittura ha comunque portato codice nuovo al sistema, aumentando le performance anche per questo. Chissà se nel Windows Explorer c’è ancora codice di NT 4, io ci scommetterei

Supporto hardware

In rete circolano voci del tipo “Che orrore, SL supporta i 64bit solo su 2 modelli e gli altri restano a 32″. Queste cose sono infondate. Il dati di fatto sono questi:

1. Per partire con un kernel a 64bit, è necessario un firmware EFI a 64bit. I modelli prima del 2007 hanno un EFI a 32bit e quindi il kernel deve partire a 32bit per forza. Esistono comunque dei workaround facilmente applicabili.
2. Apple ha comunque settato di default il kernel a 32bit su tutti i modelli tranne gli Xserve. Questo ha lo scopo di ridurre al minimo i problemi di compatibilità con i driver di terze parti. Questi devono tutti essere aggiornati per supportare il kernel a 64bit. Fino ad allora, usare il kernel a 64bit significherà fare a meno di quei driver. Per semplificare la vita agli utenti, piuttosto che partire a 64bit e poi non caricare i driver, la scelta è stata questa. Il kernel a 64bit è selezionabile in qualsiasi momento con due semplici comandini (appena avrò SL tra le mani proverò e aggiornerò il post di conseguenza).

Quando si fanno questi discorsi è importante capire che si parla solo del kernel. Come già detto prima, OS X da sempre supporta l’esecuzione di binari a 64bit anche su kernel a 32bit. Essendo tutto SL compilato a 64bit, l’unico pezzo di SO a girare a 32bit sarà il kernel. Siccome il kernel non fa matematica pesante, ed è in esecuzione poco rispetto all’userspace, nessuno noterà la differenza. Per quanto riguarda la RAM, anche se il kernel è a 32bit, tutta la RAM disponibile viene comunque gestita grazie a PAE come detto sopra, ma non solo. I processi a 64bit (ovvero tutto il resto del sistema), vedono comunque tutto lo spazio di indirizzamento a 64bit senza bisogno di usare PAE. Quindi anche con il kernel a 32bit, non esiste più il limite dei 4GB per processo (e non esisteva neanche in Leopard, a dire il vero), se il processo è in esecuzione a 64bit (cosa che vale sicuramente per tutto l’userspace).

Tutto questo non vuol dire “il kernel a 64bit non serve a nulla”. Vuol dire solo che finchè quasi tutti i driver di terze parti non saranno disponibili a 64bit, questa scelta “cautelativa” risparmierà la vita a tanti utenti e non farà calare di niente le performance.

Universal binary 32/64. Ecco come.

Venite da BSD/Linux/Windows e ancora non credete ad un kernel a 32bit che esegue software a 64? Eccovi un esempio. La mia macchina, iMac del 2007, da questo output di uname -a:

Darwin gigabytes.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01
PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

Come vedete c’è scritto i386, e il sistema è Leopard (Darwin 9.8.0). Ora scrivo con nano questo programmino C:

#include <stdio.h>
int main() {
   printf("Bitness: %d\n", sizeof(void *) * 8);
   return 0;
}

Compilando il programma ottengo:

$ gcc bitness.c -o bitness
$ ./bitness
Bitness: 32

L’eseguibile è stato compilato a 32bit (di default la configurazione di gcc è Universal ppc/intel) ed eseguito come tale. Ora ricompilo lo stesso programmino ma a 64bit:

$ gcc bitness.c -arch x86_64 -o bitness
$ ./bitness
Bitness: 64

Eseguibile a 64bit, bello pronto, con un kernel a 32bit. Compilando con i due parametri -arch i386 e -arch x86_64, lui avrebbe generato un fat binary con due versioni all’interno. L’output in questo caso è sempre Bitness: 64, il che indica che il kernel carica la versione più adatta automaticamente (è il meccanismo degli universal binary usati per la transizione soft da ppc ad intel). Di fatto tutto SL è compilato in questo modo. Questo elimina anche alla radice tutti i problemi di distribuzione. Non esistono due versioni diverse (come Windows x86/x64, o Ubuntu x86/x86_64), ce n’è una sola e funziona su tutto l’hardware supportato. Il software di terze parti verrà distribuito in una forma Universal, con codice a 32 e a 64bit  in un unico binario, senza che gli utenti debbano neanche sapere che esiste questa scelta. Per chi si preoccupa dello spreco di spazio: state tranquilli. Le applicazioni occupano spazio per un mucchio di altre cose, e il codice eseguibile è un granello di sabbia. Sul mio sistema, per esempio, /Applications/Mail.app occupa 390 MB, di cui l’eseguibile effettivo, /Applications/Mail.app/Contents/MacOS/Mail, occupa 6MB. Il resto sono grafica e localizzazioni.

Spero di aver fugato ogni dubbio su questo argomento. Ciao a tutti.

Apple & Macintosh 64bit, Snow Leopard