Questi 64 bit   Italiano

Questi giorni che hanno fatto seguito alla presentazione di Apple dei nuovi iPhone 5C e 5S hanno riportato in auge una “buzzword” che era passata un po’ di moda nel settore PC: i famigerati “64 bit”.

Oggi come ieri, è stata diffusa la stessa balla per esigenze di marketing: “Una CPU a 64 bit va il doppio di una a 32 bit”. Ieri era AMD a raccontarcela, oggi è Apple.

Ho quindi pensato di raccogliere qui, una volta per tutte, che cosa vuol dire avere una CPU “a 64 bit”, che vantaggi offre eccetera.

Fortunatamente, spiegare queste cose non è particolarmente difficile e non richiede grandi competenze tecniche :-)

L’unica nozione tecnica che bisogna sapere è che ogni programma deve accedere alla memoria prima o poi1. Per farlo, ha bisogno di un indirizzo in cui andare a prendere il dato. I 32 o 64 bit si riferiscono al numero di bit che compongono un indirizzo. Dato che ogni bit è o 0 o 1, con 32 bit puoi indicizzare uno “spazio” di bit, che sono 4 GB.

Questo vuol dire che con 32 bit puoi vedere al massimo 4 GB di RAM2, oltre è proprio impossibile vederli (ci sono stati trucchi in passato per arrivare un po’ più in là tipo a 6 GB, ma lasciamoli perdere). Con i 64 bit il problema è risolto per boh credo il prossimo millennio ( bit sono una cifra ridicola, attorno ai 16 MILIONI di Terabyte di RAM3!).

Per supportare la cosa, devi riscrivere l’instruction set della CPU (cioè il suo codice macchina), devi riscrivere il compilatore e devi ricompilare il sistema operativo nella nuova modalità.

QUINDI, perché Apple l’ha fatto sto benedetto passaggio anche su un terminale con solamente 1 GB di RAM? Perché seppur oggi sia del tutto inutile, un iPhone viene supportato tre anni. Pertanto questa mossa ci sta dicendo che entro 3 anni Apple prevede di sforare i 4 GB e inizia già adesso a fare il passaggio in modo da dare tempo ai dev di adeguarsi.

Un ultimo passaggio un po’ più tecnico sulle differenze iOS vs Android: Objective C è tipo C++ e fa un uso esplicito della memoria (devi usare i puntatori). Quindi tutte le app di iOS vanno esplicitamente ricompilate a 64 bit [credo senza necessità di cambiare il codice sotto, ma non sono un esperto di compilatori e potrei sbagliare]. Per Android invece il discorso è diverso: se usi codice nativo come alcuni giochi, ti tocca ricompilare come iOS. Se invece usi solo Java (come tutte le app non-giochi) allora non devi fare niente! Il codice Java è super-portabile e basta che Google aggiorni Android e non ti accorgi nemmeno della differenza :-)

#”Ottimizzare” e il passaggio ai 64 bit

La cosa importante da notare è che le ottimizzazioni non hanno nulla a che vedere con queste cose: tu ottimizzi un software cambiando algoritmo, usando lib più performanti, togliendo codice in Java per passare a codice nativo, eccetera. Tutte cose che avvengono sul piano delle idee del dev. Il passaggio 32 -> 64 bit è invece una cosa puramente “meccanica” dettata dalla sola necessità di superare il limite di 4 GB di RAM.

Un’analogia: pensiamo ad un’app che permette di visualizzare i contatti della rubrica di un utente. Si collega a Google, li riceve da lì e li mette in un layout carino.

Se l’app va lenta, va lenta perché magari usa codice idiota (che ne so, ordina i contatti con un Bubblesort invece di usare un QuickSort, oppure usa una libreria per caricare le immagini che è fatta male e ci mette troppo tempo). In tutto questo, che abbia indirizzi a 32 bit o a 64 non c’entra nulla: è un problema di idee dello sviluppatore, o magari di implementazione delle idee con le tecnologie giuste come le librerie usate, la scelta del linguaggio di programmazione eccetera. In questo caso, l’app va quindi non solo riscritta, ma ripensata.

Il passaggio da 32 a 64 bit serve quando la stessa app deve passare da ordinare i contatti nel mio telefono a gestire gli elenchi del telefono di tutta l’Asia: con oltre 2 miliardi di persone 4 GB di RAM non basterebbero più (vi garantisco che ciascun contatto non può occupare solo 2 byte) e quindi non ci sarebbe modo di farlo se non quello di aumentare lo spazio “visualizzabile” spostandosi sui 64 bit. Notate che l’app non va né riscritta né ripensata, va solo ricompilata (e nemmeno quello se era in Java o Python o altri linguaggi interpretati. In questo caso devi cambiare l’interprete e basta, il codice esegue fin da subito restando uguale).

#Conclusione

Quando Apple dice che A7 è più veloce di A6 ci possiamo credere (di solito sono abbastanza accurati), e comunque lo vedremo dai benchmark. La scelta del passaggio ai 64 bit è un’ottima cosa perché assicura longevità al nuovo iPhone 5S. Quello che non va bene è dire che questo passaggio sia fonte di incrementi prestazionali! A7 sarà più veloce di A6 per i fatti suoi, perché gli ingegneri di Apple ci avranno lavorato a lungo. Insomma, occhio al marketing dei numeroni ;-)

  1. Entrando un po’ più nel tecnico, chiunque abbia fatto un minimo di programmazione può vederlo facilmente: ogni volta che dichiari una variabile quando programmi, stai usando gli indirizzi. Il numero di bit è proprio il numero di bit che compongono un puntatore. Chi pensa che linguaggi senza puntatori (espliciti) come Java o Python non ne usino è del tutto fuori strada: semplicemente tutto è un puntatore e tu non te ne accorgi :P

  2. Trucchetto per calcolare rapidamente i GB a partire dagli esponenti del 2 e viceversa: vi basta sapere che è circa 1000 (fa 1024 ma che ci frega). Quindi byte sono 1 KB, sono un MB, sono un GB e così via. lo possiamo vedere come e quindi 4 GB.

  3. Col metodo di prima sappiamo che 1 TB = bit. Qui bisogna moltiplicare per un milione per arrivare a e poi ancora per per arrivare a . Incidentalmente, 1000 TB formano 1 PB (Petabyte) e 1 milione di TB formano un EB (Exabyte). Quindi sarebbero 16 EB di RAM. Not bad!