Nella puntata pilota di Mettiamoci le Facce, che spero abbiate gradito, Loris mi aveva posto la domanda se le nuove architetture con i processori a 64 bit nei prossimi smartphone, porteranno reali benefici all’utente finale, ed io ho risposto molto succintamente di no a questa domanda, anche per non rubare troppo tempo al live.

Però mi sono reso conto che potevo fare sul blog, un focus su questo argomento per cercare di approfondirlo insieme a voi, simulando un vero e proprio botta e risposta, poichè, mi sto rendendo conto che c’è ancora diversa confusione  …

Naturalmente l’argomento è molto vasto e ci sarebbe davvero molto di più da dire, ma l’obiettivo di questo articolo non è scrivere una tesi sulle architetture hardware, piuttosto vorrei darvi semplicemente gli elementi sufficienti per comprendere dal punto di vista tecnico, una serie di informazioni che il marketing sta dando in pasto al pubblico in maniera incompleta e a volte fuorviante.

Cercherò come sempre di utilizzare un linguaggio accessibile a chiunque e di dare tutte le informazioni che vi servono per avere un quadro che sia il più completo possibile.

Siete pronti ? Let’s go ! 😀

Che significa architettura a 32 o 64 bit ?

Fondamentalmente in informatica, dire che un sistema è a 32 o 64 bit è usare un aggettivo per indicare che in una data architettura il formato standard di una variabile semplice (intero, puntatore, handle ecc.) è di 32 o 64 bit di larghezza. Generalmente questo riflette la dimensione dei registri interni della CPU usata per quella architettura.

Ehi, ehi calma … stai andando troppo forte, innanzi tutto: “Ma che cos’è un bit ?”

Ok, hai ragione, facciamo un passo indietro:

I computer in generale e quindi anche i dispositivi mobili che ormai sono calcolatori che telefonano, utilizzano come unità d’informazione di base (dall’inglese Binary Information Unit) il cosiddetto bit, ossia l’unità elementare, cioè più piccola, dell’informazione (quindi di memoria) trattata da un elaboratore. Queste unità seguono quindi la numerazione binaria ossia in base 2, più semplice da trattare in chiave elaborativa,  poichè analizza lo stato logico solo dei valori 0 e 1 (acceso/spento, assenza di carica/presenza di carica ecc. ecc.), diversamente dalla numerazione decimale a cui siamo più abituati.

Quindi dire che una CPU è a 32 bit, significa dire che può indirizzare memoria fino a:

2^{^32} = 4294967296 -1 = 4Gb

Mentre passare ad un’architettura a 64 bit, significa che si può indirizzare memoria fino a:

2^{^64} = 18446744073709551616-1 = 16Eb (16 exabyte è un numero enorme, ossia 16 miliardi di Gbyte, virtualmente irraggiungibile ai giorni nostri.)

Questo quindi che vuol dire per i nostri dispositivi ?

Beh, significa che con una architettura a 64 bit, possiamo elaborare molte più informazioni in una sola volta.

Riducendo e semplificando al massimo i componenti di un computer, possiamo dire che c’è un processore che legge i dati nella memoria ram, esegue i suoi calcoli ed infine scrive il risultato in un’altra cella di memoria, che magari visualizziamo su un dispositivo di output (display)

Quindi se dico al processore di fare un calcolo semplice, ad esempio 5 + 2 … Esso non farà altro che mettere la cifra 5 in una cella di memoria, poi il 2 in una seconda cella di memoria e scriverà il risultato 7 in una terza cella di memoria, chiaramente in un solo passaggio

Ma se uso numeri di portata diversa ad esempio superiori a 4294967296 e chiedo alla CPU da 32 bit di fare:

4294967298 + 1024 che succede ?

Succede che una CPU a 32 bit non è in grado di gestire numeri superiori a 4294967296 e quindi dovrà dividere il primo numero in 2 ed eseguire il calcolo in 2 passaggi.

L’analogo calcolo fatto con una CPU a 64 bit la quale non ha problemi a gestire numeri più grandi di 4294967296 , verrà eseguito in un solo passaggio.

Quindi mi stai dicendo che su una architettura a 64 bit vado veloce il doppio rispetto ad una architettura a 32 bit ?

Non proprio, è in linea di massima un po’ più veloce ma non certo il doppio, perché dipende da quante volte la CPU dovrà elaborare dati complessi, oltre i 32 bit di registri di memoria.

In genere l’impatto sulle prestazioni in applicazioni di uso comune, si aggira mediamente dal 2% al 20%. Quindi per intenderci, nelle normali app da smartphone, per esempio whatsapp, facebook, email e simili, l’impatto sull’aumento di performance è minimo se non nullo.  Il vero guadagno in performance lo potremmo rilevare nell’ambito dell’elaborazione audio / video (encoding / decoding), grafica complessa, videogiochi 3D, calcolo scientifico e nella gestione di grandi database.

E in che modo questo avviene ?

Facciamo un esempio, ci troviamo su una strada provinciale a 2 corsie parecchio trafficata, dove il limite di velocità è di 70 Km/h, dovendo essere l’assessore alle infrastrutture e trasporti (competente, onesto e non corrotto ovviamente :-))) ), in che modo potrei tentare di risolvere i problemi del traffico, facendo in modo di dare ad un più grande numero di autovetture la possibilità di fare quella strada in minor tempo (e in minor bestemmie) ?

Fondamentalmente in 2 modi:

1. Innalzare il limite di velocità. Se io portassi il limite da 70 a 140 Km/h potrei fare teoricamente il doppio dei Km nello stesso intervallo di tempo (1 ora) e quindi il doppio della distanza rispetto a prima nello stesso tempo. Questo è quello che accade quando si innalza la frequenza di clock di un processore. La velocità o frequenza di clock è il numero di commutazioni tra i due livelli logici “0” e “1” (numerazione binaria appunto) che circuiti logici interni ad un’unità di calcolo o di un microprocessore sono in grado di eseguire nell’unità di tempo di un secondo, ed è espressa in cicli al secondo, o hertz, e suoi multipli (più comunemente le cpu indicano la loro velocità di clock in megahertz Mhz). Quindi più alta è la frequenza di clock di un processore, più saranno il numero di elaborazioni nella stessa unità di tempo (1 secondo).
2. Aggiungere più corsie. Magari se volessi fare in modo di mantenere una maggior prudenza negli automobilisti, lasciando il limite a 70 Km/h, però volessi raddoppiare comunque il numero di macchine che percorrono quella strada nello stesso tempo, potrei fare una bella opera di infrastruttura stradale, (senza tangenti ovviamente :))) ) raddoppiando le corsie. Quindi non ho fatto in modo che le macchine andassero più veloci, ho semplicemente raddoppiato le corsie per farne passare di più nello stesso tempo. Questo è quello che succede quando passiamo da un’architettura da 32 a 64 bit, in realtà non è aumentata la velocità di clock del processore ma è aumentato il throughput, ossia la quantità di dati trasmessi nell’unità di tempo.

Quindi unendo questi 2 concetti abbiamo che un processore da 64 bit con frequenza di clock pari alla metà è in grado di eseguire gli stessi calcoli nello stesso intervallo di tempo. In genere è la strada che si preferisce, poichè a più alte frequenze di clock c’è un maggior dispendio energetico, oltre che maggior produzione di calore.

In realtà ci sarebbe anche un’altra cosa che potrei fare per eseguire davvero un lavoro eccellente sulla mia infrastruttura stradale: aumentare anche i sensi di marcia delle corsie stradali della strada provinciale in oggetto.

Questo è quello che succede quando si passa da processori con un solo core, a processori con 2 o più core, definiti appunto, processori multicore.

In elettronica il termine multi core viene utilizzato per indicare una CPU composta, appunto,  da 2 o più core, ovvero da più nuclei di processori “fisici” (nuclei elaborativi) montati sullo stesso package.

Il package in parole molto semplici, è un “contenitore”  in cui sono racchiuse alcune tipologie di componenti elettronici.

L’aggiunta di un altro nucleo elaborativo (core) equivale quindi ad aggiungere un altro senso di marcia alla mia strada. Le automobili possono quindi salire e scendere contemporaneamente, proprio come i dati con i quali lavora un dispositivo come un computer o uno smartphone.

Nei sistemi multicore (quindi una CPU composta da 2 o più core, ossia più nuclei elaborativi montati sullo stesso package), dei dispositivi mobili, uno dei componenti che trae maggior beneficio da questa parallelizzazione è sicuramente la batteria, poiché avendo un’architettura hardware con più corsie e sensi di marcia, il processore è impegnato di meno e quindi si risparmiano preziosi cicli di clock che danno ossigeno alla batteria stessa.

C’è da considerare anche un altro vantaggio delle architetture a 64 bit in ambito sicurezza. Grazie al supporto di numeri molto più grandi, saranno infatti possibili crittografie ancora più complesse; infatti maggiore è la lunghezza della chiave, più difficile sarà la decifrazione della stessa. La funzione “crittografia dispositivo”, che permette di crittografare l’intera memoria dello smartphone, risulterà ancora più sicura e anche più veloce, per i motivi suddetti.

Quindi un’architettura a 64 bit è oggettivamente migliore di una a 32 bit ?

In linea generale si, ma come ho detto anche nel mettiamoci le facce, allo stato attuale dell’evoluzione in campo mobile, (ma comunque il concetto vale sempre in linea teorica), in alcune situazioni, si possono avere anche performance inferiori.

Come è possibile ?

Il problema nelle architetture a 64 bit, è che il consumo di memoria è maggiore: in linea teorica, portando la dimensione di default degli interi da 32 a 64 bit, ogni numero intero occuperà il doppio dello spazio nella RAM (anche se poi i vari produttori hardware sviluppano soluzioni per ottimizzare e ridurre al minimo l’impatto dell’architettura a 64 bit sulla memoria, ma questa è un’altra storia …).

Se per esempio seguendo la pura teoria, vogliamo rappresentare il numero 1 in formato binario in un sistema a 32 bit, sto scrivendo:

00000000000000000000000000000001

Se lo rappresento in un sistema a 64 bit, in realtà sto scrivendo:

0000000000000000000000000000000000000000000000000000000000000001

Ciò significa che useremo massivamente la memoria anche quando non è richiesto, quindi generalmente le istruzioni a 64 bit portano via più spazio di quelle a 32, per cui è possibile che certi programmi a 32 bit essendo “più snelli”, possono entrare nella velocissima memoria cache della CPU laddove quelli a 64 non ci riescono e quindi andare paradossalmente più veloci. In altri termini, usare 64 bit per effettuare operazioni che potrebbero essere gestite a 32, comporta un inutile spreco di risorse e a volte addirittura un degrado di prestazioni.

Insisto: quindi se non ho 4Gbyte o più di RAM l’architettura a 64 bit è inutile ?

Non è del tutto vero. Diciamo che è solo uno degli aspetti di cui tenere conto. Io posso tranquillamente avere un’architettura a 64 bit con un 1 Gb di RAM (come nell’iPhone ad esempio), ma certamente non ne sfrutto tutte le potenzialità e comunque visto il maggior dispendio di risorse nel codice a 64 bit, sicuramente avere più RAM aiuta molto in chiave prestazioni.

In questa fase, ritengo che si stia spingendo gli sviluppatori a fare il grande salto dei 64 bit anche in ambito mobile, per poi essere pronti, nelle prossime generazioni hardware a sfruttarne tutto il potenziale.

Ricordiamoci che l’utilizzo di uno smartphone o di un tablet è sempre più verso la multimedialità, con giochi sempre più complessi, video in 4k (e chissà cosa in futuro), foto di definizione sempre più alte e applicazioni sempre più pesanti, quindi è facile pensare che da qui a poco, le architetture a 64 bit si rendano necessarie.

Di seguito un esempio di benchmark effettuato su giochi eseguiti sia a 32 che 64 bit su un sistema Intel Core i5 e Windows 7 x64, direi che la differenza è piuttosto evidente.

E perché allora si insiste tanto sul fatto che se non hai almeno 4 Gb di RAM i 64 bit sono inutili ?

Faccio un esempio per tutti: ormai avere file di dimensioni superiori ai 4 Gbyte è cosa comune con film, video 4k o anche in alcuni giochi particolarmente complessi e la mappatura in memoria di tali file è diventata problematica sui sistemi a 32 bit, poiché è necessario tenerne in memoria solo una certa porzione per volta, e questo impatta negativamente sulle prestazioni generali, perché poi ci si deve appoggiare allo storage interno utilizzando la cosidetta “memoria virtuale” (o swap space), abbastanza più lenta della RAM. In questo caso un’architettura a 64 bit non ha problemi, a patto di avere RAM sufficiente per mappare in maniera efficiente in memoria, in un solo passaggio, file complessi e di grandi dimensioni.

Ecco perché i 4 Gbyte (o più) di RAM sono solo uno degli aspetti di cui tenere conto nei pro e contro dell’architettura a 64 bit.

E dal punto di vista software quali difficoltà possono esserci nel passare da 32 a 64 bit ?

In ambiente iOS 8, ad esempio, le app usano codice nativo, quindi per funzionare a 64 bit devono essere completamente ricompilate e ripubblicate. Discorso diverso in ambito Android, dove la app usano una virtual machine (che nella nuova versione di Android sarà ART per supportare la nuova architettura), la quale si occupa di compilare e far girare le app con il vantaggio di essere più facilmente portate ad essere a 64 bit con Android L e con meno lavoro da parte degli sviluppatori, ma qui magari il nostro Giancarlo potrà dirmi se davvero sarà così o meno ;-)).

Naturalmente anche le app a 32 bit potranno essere eseguite sui processori a 64 bit (non viceversa però), tramite un modulo di emulazione software, (come già succede per esempio in Windows 64 bit con il WoW64) però in quel caso le app a 32 bit sicuramente gireranno meglio su processori a 32 bit che su SoC a 64 bit, poiché non c’è uno strato software intermedio che deve interpretare il codice, rallentandone inevitabilmente l’esecuzione. Quindi per fare un esempio un gioco a 32 bit di una certa complessità, girerà meglio su uno Snapdragon 801 a 32 bit che su uno Snapdragon 810 a 64 bit.

Quindi se volete comprare uno smartphone e vi state chiedendo se non sia meglio aspettare quelli a 64 bit, vi dico spassionatamente che non è necessario attendere, poiché allo stato attuale, i vantaggi per l’utente sono minimi, quindi in questo momento, acquistate senza paura di restare indietro. Discorso diverso sarà da qui a 2 anni, in cui il passaggio alla nuova architettura a 64 bit, sarà completo, con terminali che avranno anche 4 Gb o più e allora l’esperienza utente sarà davvero diversa e più appagante (potremmo aspettarci addirittura una interfaccia TouchWiz performante come una Google Experience  :))) ).

Di cose da dire ce ne sarebbero ancora tante, ma credo che quanto finora espresso sia sufficiente, anche se ripeto, ho parlato in linea puramente teorica, poichè le architetture a 64 bit non rispettano completamente i concetti suddetti e andrebbero analizzate caso per caso. C’è infatti chi per esempio in ambito mobile rispetta le specifiche ARM e chi non le rispetta completamente, per cui confrontando i SoC di produttori diversi anche se entrambi a 64 bit, i risultati potrebbero essere molto diversi.

Spero comunque che questo articolo vi sia stato utile per chiarirvi le idee e nel caso avrò piacere di interagire con voi nei commenti.

A presto ! 😀