Android e 64 bit: quali cambiamenti comporta il passaggio a questa architettura?

Una delle domande che sicuramente vi siete posti è: quali reali differenze comporta il passaggio da un’architettura a 32 bit, ad una a 64 bit? In questo approfondimento cercheremo di dare risposta a quella che, dopo l’annuncio di iPhone 5S – il primo smartphone con processore ad architettura a 64 bit – è la domanda più cliccata in rete.

Molte aziende, infatti, si stanno orientando verso i 64 bit, a partire da HTC che durante l‘IFA Berlin 2014 ha presentato il Desire 820, il primo smartphone Android dotato di un processore Qualcomm Snapdragon 615 a 64-bit con modem LTE.

Urge una premessa, che in seguito ci sarà d’aiuto per comprendere meglio:

Qualunque device può essere diviso in tre parti: l’hardware, il sistema operativo e le applicazioni (o programmi).

32-bit vs 64 bit

I calcolatori elettronici utilizzano come unità d’informazione di base il cosiddetto bit (binary digit , cioè cifra binaria). Da un punto di vista prettamente fisico il bit è un sistema a 2 stati: può infatti essere indotto in uno dei due stati distinti rappresentanti 2 valori logici (no o si, falso o vero, o semplicemente 0 o 1). In termini pratici, il bit viene realizzato utilizzando le proprietà dell’energia elettrica (assenza di carica o presenza di carica).

Se il numero di bit aumenta ci sono tre importanti vantaggi:

• Elaborazione dati maggiore, ne deriva quindi una maggiore precisione
• Capacità massima di memorizzazione del singolo dato
• Un sistema operativo a 32 bit non può usare più di 4 gigabyte di memoria per una serie di limitazioni, che non esistono quando si usa un sistema operativo a 64 bit. Per sfruttare al massimo un’architettura a 64 bit è necessario un quantitativo di memoria RAM superiore ai 3 GB.

Un SoC a 32 bit permette al device di indirizzare 2^32 = 4,294,967,296 byte di memoria (o 4 gigabyte).
Un device il cui SoC è a 64-bit può gestire 2^64 bytes (o 16 exbibytes); ne deriverebbe una memoria RAM virtualmente infinita.

Premessa: Il porting è un’attività di trasposizione che avviene modificando una componente software, affinché essa possa essere eseguita in un ambiente diverso da quello originale.

Il passaggio da un’architettura a 32 bit ad una a 64 non comporta un cambiamento profondo; teoricamente, le applicazioni dovrebbero essere “portate” per supportare la nuova architettura, ma in realtà non è così.

Le applicazioni saranno supportate attraverso una modalità di compatibilità hardware (dove cioè il processore supporta anche il vecchio set di istruzioni a 32 bit), attraverso l’emulazione software, o anche attraverso l’implementazione del nucleo di un processore a 32 bit all’interno del chip stesso del processore.

Alcuni programmi potrebbero essere più veloci in modalità a 32 bit. Su certe architetture le istruzioni a 64 bit portano via più spazio di quelle a 32, per cui è possibile che certi programmi a 32 bit possano entrare nella memoria cache della CPU laddove quelli a 64 non ci riescano. In altri termini, usare 64 bit per effettuare operazioni che potrebbero essere gestite a 32, comporta un inutile spreco di risorse.

Ricapitolando:

• Un’applicazione progettata per un SoC a 32 bit verrà eseguita su un SoC a 32-bit o 64-bit senza alcun problema.
• Un’applicazione progettata per un SoC a 64 bit verrà eseguita solo su un SoC a 64-bit.

Gli ambienti a 64 bit sono essenzialmente costituiti da due componenti: hardware e software. Al centro (perdonate il gioco di parole) c’è il sistema operativo e i driver e, senza questi ultimi, l’hardware (la CPU ndr) a 64 bit è inutile.  Allo stesso modo, senza un hardware che supporti l’architettura a 64 bit, le applicazioni e il software sono inutili.

Un device a 64 bit è più veloce di uno a 32-bit? No, o almeno in parte.

L’architettura a 64-bit permette di avere più “corsie” attraverso cui i dati possono viaggiare.

Esempio:

Una superstrada a tre corsie ha un limite di velocità di 90 km/h. Quella strada può gestire un quantitativo di vetture che può essere accelerato in due modi: aumentare il limite di velocità o aggiungere più corsie.

Aumentare il limite di velocità consiste nell‘aumentare la frequenza di clock di un processore; la velocità di clock di una CPU è la frequenza del segnale di temporizzazione e corrisponde al numero di operazioni elementari per secondo che la CPU è in grado di eseguire.

L’aggiunta di più corsie corrisponde al passaggio da 32 bit a 64-bit: non è aumentata la velocità, ma è aumentato il throughput.

Cos’è il throughput?
E’ la capacità di trasmissione effettivamente utilizzata, misurata in bit/s. Ne deriva che il throughput è la quantità di dati trasmessi in un’unità di tempo.

C’è un altro elemento da considerare: i core.
Il core è il “nucleo elaborativo” di un microprocessore. Questo infatti è costituito in realtà da 2 componenti principali: il core e il package che lo contiene.
L’aggiunta di un altro nucleo elaborativo equivarebbe ad aggiungere un altro senso di marcia. Le auto possono salire e scendere contemporaneamente, proprio come i dati con i quali lavora un device. Nei sistemi multicore (CPU composta da 3 o più core, ossia più nuclei elaborativi montati sullo stesso package), dunque, la velocità è si superiore, ma non di molto. Ciò che trae beneficio è sicuramente la batteria, avendo il processore più “corsie” ed essendo quindi impegnato meno.

La velocità di clock è uno dei fattori che contribuisce alle prestazioni della CPU, ma non l’unico, infatti a parità di architettura, una CPU con frequenza di clock maggiore ha prestazioni migliori, nel senso che riesce ad eseguire un numero di operazioni maggiore rispetto ad un processore con frequenza più bassa. Sbloccando le opzioni di sviluppatore è possibile eseguire un overclocking, ossia l’aumento della frequenza di clock rispetto a quella prevista dal produttore.

Questo tipo di confronto non è fattibile tra architetture diverse: una CPU da 64 bit con frequenza di lavoro pari alla metà è in grado di eseguire calcoli nello stesso intervallo di tempo.

Ma il kernel linux sarà compatibile con i 64 bit?

I kernel linux a 64 bit sono diventati più comuni negli ultimi anni, ma le applicazioni compatibili con i 64 bit stentano ancora a decollare.
A volte può essere difficile trovare pacchetti precompilati per architetture a 64 bit, anche se in molti casi è sufficiente ricompilare i sorgenti (a patto di avere le conoscenze tecniche necessarie). Benché i sistemi a 64 bit possano eseguire anche programmi a 32 bit, nel sistema devono essere installate entrambe le versioni delle librerie. Fortuntamente Android adopera il kernel del sistema GNU, utilizzato congiuntamente al kernel Linux, che supporta queste librerie.
Con Android L Google implementerà la runtime ART, che supporterà sicuramente i 64 bit.

I 64 bit hanno svantaggi? Ovviamente si.

Il maggior svantaggio delle architetture a 64 bit rispetto a quelle a 32 risiede nel fatto che i dati occupano uno spazio leggermente maggiore in memoria.

Esempio:
•numero 2 in sistema binario su un’architettura a 32 bit:

00000000000000000000000000000010

•numero 2 in sistema binario su un’architettura a 64 bit

0000000000000000000000000000000000000000000000000000000000000010

Questo incrementa le richieste di memoria dei programmi e può avere implicazioni nell’uso della cache (che ha dimensioni limitate).

Conclusioni

Se vi state chiedendo: dovrei aspettare e comprarmi uno smartphone a 64 bit, la risposta è no.

Vi chiederete: perché?
Per una serie di ragioni, la cui principale risiede nel fatto che Android non è ancora pronto per sfruttare realmente l’architettura a 64 bit e solo con Android L Google si muoverà verso questa “trasformazione”.
Acquistare un device a 64 bit con uno Snappdragon 808 o un Exynos 5433 (un octa-core con quattro core Cortex-A57 e quattro core Cortex-A53 a 64-bit con architettura big.LITTLE ) non porterà nessun reale vantaggio rispetto all’acquisto di un Samsung Galaxy S5 o un LG G3, che possiedono un processore Qualcomm Snapdragon 801 a 32 bit.

In generale, finché non avremo smartphone con una memoria RAM da 4 GB o più, le CPU a 64 bit saranno inutili.

Oltre all’architettura, entrano in gioco molte altre variabili, tra le quali: personalizzazioni apportate dal produttore, qualità degli update, ottimizzazione software e applicazioni non pienamente compatibili (nel primo periodo, a nostro avviso, si assisterà ad una involuzione della qualità delle app).