Apple presenta il nuovo Power Mac G5. Era il 24 giugno 2003, e con questo titolo esordiva la notizia che Apple presentava l’attesissima nuova linea di macchine della casa, il cui cuore era costituto dal nuovissimo gioiello di casa IBM: il PowerPC 970.
Stanco del lento processo di aggiornamento della linea PowerPC G4, Steve Jobs decise di dare il benservito a Motorola e stringere, quindi, un accordo con BigBlue, quest’ultima forte della nota e apprezzata (nel campo dei server e dei supercomputer) famiglia POWER, per ridare linfa alla sua linea Mac, che da tempo non era più stata in grado di tenere il passo con gli odiati x86 di Intel & co.
Lo fece in grande stile, presentando al mondo il personal computer più veloce al mondo e… il primo a 64 bit! Tanto per cambiare, entrambe le affermazioni furono frutto del solito marketing a cui ci ha abituato ormai questa eclettica azienda.
La prima fu smentita qualche mese dopo, quando finalmente le prime macchine furono commercializzate (a fine agosto, primi di settembre; questo per battere in volata AMD che il 22 settembre dello stesso anno presentò l’Athlon64, versione consumer della sua neonata architettura AMD64) e fu possibile effettuare finalmente dei test che mostrarono, però, un quadro diametralmente opposto a quello pomposamente sbandierato.
La seconda è un po’ più difficile da ribaltare e richiede una ricostruzione più laboriosa, ma per cominciare bisogna dire che già il 22 aprile AMD aveva presentato gli Opteron, cioè la versione server degli x86-64 (altro nome più “neutro”, col quale si identifica l’architettura AMD64), e oltre a dei server blasonati era possibile acquistare direttamente queste CPU per farsi in casa il proprio “super desktop”. Come da tradizione (o filosofia) PC.
In ogni caso la posizione dei PowerMac G5 nei confronti dei 64 bit non era concreta, ma abbastanza fumosa (nel senso che c’era più fumo che arrosto), e ciò per diversi motivi, tutti legati al sistema operativo che ci girava sopra: OS X.
Innanzitutto all’epoca della loro presentazione era a disposizione soltanto la versione 10.2, Jaguar (rilasciato ad agosto dell’anno precedente), che era esclusivamente a 32 bit. Tutti i test di presentazione furono, infatti, realizzati con questo s.o. e ovviamente con applicazioni a 32 bit: dei 64 bit non si sfruttò proprio nulla, se non l’immagine a fini pubblicitari.
A ottobre dello stesso anno fu presentata la successiva major release, Panther, che permetteva di sfruttare la memoria oltre i canonici 4GB dello spazio d’indirizzamento a 32 bit, ma esclusivamente per eseguire caching dei dati letti (o scritti) dal filesystem.
Quindi macchine con 8GB di RAM, ad esempio, usavano il secondo banco da 4GB per memorizzare i dati letti o scritti più frequentemente dal disco. Siamo, insomma, ancora ben distanti dal loro utilizzo in ambito applicativo.
La svolta, parziale, arriva soltanto due anni dopo (fine aprile del 2005) con OS X 10.4 (Tiger) che finalmente metteva a disposizione un ambiente POSIX-compliant (cioè la libreria di sistema che espone le API di questo standard industriale, base di quasi tutti i s.o. Unix-like) a 64 bit e, quindi, la possibilità di poter eseguire applicazioni a 64 bit che ne facevano uso.
Un bicchiere che non si potrebbe definire nemmeno mezzo pieno, considerato che le normali applicazioni (quelle dotate di interfaccia grafica) continuavano a rimanere rigorosamente a 32 bit. Quelle che avevano necessità di eseguire elaborazioni a 64 bit (siano essi dati a 64 bit o l’accesso a quantità di memoria oltre i 4GB), dovevano necessariamente prevedere la classica applicazione a 32 bit, a cui se ne affiancava un’altra per il solo codice a 64 bit; la comunicazione fra i due “mondi” avveniva esclusivamente tramite un (lento) meccanismo di IPC (Inter-Process Communication).
Un sistema che sembra perverso, ma che aveva ovviamente la sua ragione di esistere (dal punto di vista applicativo): l’ambiente a 64 bit era decisamente più lento nell’esecuzione, per cui era necessario limitarne il più possibile l’uso. Sembra un controsenso, perché il battage pubblicitario propagandava i 64 bit come il nuovo Santo Graal, e nell’immaginario collettivo più bit equivalgono a prestazioni superiori.
In 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 caso del PPC970 (meglio conosciuto col nome di G5), vale lo stesso di diverse altre architetture la cui unica innovazione riguardi l’estensione a 64 bit di registri e puntatori: si verifica un decadimento prestazionale dovuto alla dimensione doppia dei puntatori e al maggior tempo di context switch dei processi.
Lecita, quindi, la moderazione di Apple (ma non nella pubblicità) e il consiglio ai programmatori di utilizzare codice a 64 bit soltanto se strettamente necessario, ossia se il bilancio fra riduzione delle prestazioni (a causa dell’ambiente a 64 bit e al meccanismo dell’IPC per la comunicazione fra codice a 32 e 64 bit) e il miglioramento delle medesime (dovuto alla capacità di eseguire in scioltezza calcoli su dati a 64 bit e/o di indirizzare più di 4GB di memoria) fosse strettamente positivo.
Il codice a 64 bit rimane, pertanto, relegato esclusivamente a una nicchia, a un paio di strati (POSIX a 64 bit e applicazione non dotata di GUI a 64 bit) dell’astrazione della piattaforma OS X: tutto il resto, kernel e driver inclusi, rimane rigorosamente a 32 bit, e questo anche e soprattutto per il pallino di Apple, che si trascina da sempre, della retrocompatibilità a tutti i costi.
Infatti Tiger non introduce alcun nuovo driver model (al contrario di quanto faccia spesso Microsoft coi suoi s.o.) e i produttori di periferiche non devono, pertanto, fornire driver a 32 e 64 bit per i nuovi PowerMac G5: si possono benissimo sfruttare quelli già esistenti, anche per l’ambiente a 64 bit. Il che però, suona molto strano. E a ragione.
Se il codice dei driver non si tocca, rimane il dubbio di come sia possibile, per una periferica, leggere o scrivere dati nello spazio d’indirizzamento superiori (ai 4GB canonici). In questi casi la soluzione da manuale è quella di utilizzare dei buffer (di “transito”) nella zona di memoria bassa, che saranno poi quelli effettivamente utilizzati dai driver.
Quindi se, poniamo il caso, un’applicazione a 64 bit volesse leggere il contenuto di un file in una sua zona di memoria (con indirizzo a 64 bit), la procedura sarebbe la seguente (sto volutamente semplificando il discorso):
- chiede alle apposite API POSIX a 64 bit di eseguire la lettura specificando l’indirizzo del suo buffer
- le API smistano la richiesta al kernel, che provvederà a richiedere alla periferica di leggere il blocco di dati, trasferendolo in un apposito buffer in memoria bassa
- completata quest’operazione, i dati verranno copiati dal buffer in memoria bassa a quello dell’applicazione a 64 bit
Risulta evidente come rispetto a un s.o. con driver a 64 bit sia necessaria un’operazione addizionale di copia dei dati e maggior spazio occupato (per il buffer nella zona di memoria bassa). Il quadro precedentemente delineato peggiora ancora, perché viene introdotto un ulteriore collo di bottiglia nell’uso del codice a 64 bit, di cui bisogna tener conto nelle valutazioni dell’opportunità di sfruttare questa possibilità.
Servono più di due anni a Apple, con l’arrivo di Leopard nell’ottobre del 2007, per rimuovere il grosso limite rappresentato dall’impossibilità di avere applicazioni native a 64 bit dotate di GUI, sebbene poco software ne farà uso (nemmeno Apple stessa, che rilascia ancora quasi tutto il suo codice a 32 bit). I tempi, però, sono decisamente cambiati e, come aveva fatto con Motorola, Jobs ha già abbandonato anche IBM per unirsi all’odiata rivale di sempre: Intel.
Col passaggio alle “nuove” CPU (avvenuto il 6 giugno del 2005; qualche ora prima, nel commento #68, potete leggere il mio pensiero sull’argomento e l’incoraggiamento ai fan della mela mordicchiata a godere delle nuove possibilità che si sarebbero aperte) si libera anche dei colli di bottiglia dell’ambiente a 64 bit dei G5, in quanto l’architettura AMD64 risulta mediamente più veloce del 10-15% rispetto al medesimo codice, ma a 32 bit (per x86)
Dunque architettura nuova per i Mac, nuovo codice per il s.o. e nuovo driver model, ma soprattutto nuove sfide per gli sviluppatori, che dovranno prevedere la compilazione di eseguibili in grado di girare sia sulle vecchie piattaforme PowerPC, sia sulle nuove x86 di Intel. Kernel e driver sono, però, sempre a 32 bit e rimane il collo di bottiglia rappresentato dall’uso del buffer di transizione nella zona di memoria bassa.
Arriviamo ad Agosto 2009 e con la commercializzazione di Snow Leopard finalmente Apple toglie di mezzo quest’ultimo fardello, presentando un s.o. dotato di kernel e driver model a 64 bit (anche se di default il sistema parte a 32 bit; forse perché il parco driver non è ancora al completo e/o maturo?).
Ci sono voluti più di 6 anni dall’annuncio del primo personal computer “a 64 bit”, ma ce l’ha fatta: tutta la piattaforma è, adesso, a 64 bit. Meglio tardi che mai, come si suol dire in questi casi, e la macchina del marketing può tornare prepotentemente a puntare sui favolosi 64 bit…
