Editoriale | Quei benchmark su LG Nexus 4 che sembrano parlare da soli…
LG Nexus 4 risulta davvero lento nei benchmark usciti sulla rete. Come mai? Analizziamo un pò questa strana situazione che convince davvero molto poco.
Nei giorni scorsi abbiamo assistito alla pubblicazione di alcuni test di benchmark, effettuati dai ragazzi di Anandtech, i quali proponevano dei risultati davvero agghiaccianti: il nuovo top gamma LG Nexus 4 subiva in termini di performance, batteria e velocità anche contro l’ormai vecchio iPhone 4S. Andiamo a fare un pò di luce su questa strana situazione.
Non sto a pubblicare un’ennesima volta gli screen dei benchmark in questione, dato che se n’è parlato e riparlato sul 90% dei blog di telefonia mondiale, ma se volete comunque ridargli un occhio, ecco la pagina ufficiale su Anandtech. In ogni caso, partirei con l’editoriale vero e proprio.
Partendo dal presupposto e ammettendo che il risultato del test per iPhone 5 mi abbiano davvero sbalordito, riuscendo a farmi capire quanto sia valido a livello di performance lo smartphone di casa Apple, in questo editoriale voglio concentrarmi sul vero e proprio benchmark e sui risultati ottenuti da LG Nexus 4, il nuovo portabandiera di casa Google.
L’analisi in questione l’ho suddivisa in due grandi aspetti (che poi troppo grandi non sono

), veri punti chiave che riescono a fornire un quadro corretto della situazione su questo nuovo Google Phone.
Punto primo: Nexus 4 aveva già una versione stabile del firmware?
Il secondo punto chiave è l’aspetto software. Questi risultati benchmark sono stati svolti proprio sul finire di Ottobre, cosa che lascia pensare ad una versione software non ancora ottimizzata per il nostro Google Nexus 4. Ho letto anche su alcuni blog dei commenti in cui si affermava che la versione Android era la 4.2, quindi non in beta: ricordiamoci le 4.2 indica la versione del sistema operativo, non la versione del firmware finale per il dispositivo.
Tornando a noi, molti ora penseranno e diranno: “Cosa c’entra? I benchmark guardano unicamente l’aspetto hardware di un terminale!”. Niente di più sbagliato. A questo punto preferisco ricorrere ad un altro esempio: dovete acquistare una macchina.
Paragoniamo il motore, i filtri, i freni, le gomme, etc. alla parte hardware del terminale, ovvero ciò che muove veramente tutto. Gli interni, la comodità dei sedili, il grip sul volante, la posizione dei pulsanti del cruscotto, etc. è la parte software, cioè quello che vi permette di utilizzare il terminale. Voi dareste un parere positivo ad un auto che ha un motore da 500 cavalli, ma che ha i sedili con gli spuntoni, il volante scivoloso come la buccia di una banana e il pedale dell’acceleratore posizionato a 2 metri dal sedile guida? Direi proprio di no, proprio perché l’auto risulterebbe parzialmente inutilizzabile.
Questa teoria è anche alla base dei test di benchmark, i quali osservano anche come il firmware gestisca le risorse hardware durante il test: dunque una versione firmware non ottimizzata e finale non riuscirà mai a dare ottimi risultati in termini di performance.
Punto secondo: come lavora veramente questo tipo di benchmark?
Cosa nascosta da moltissimi blog, è proprio il modo in cui lavora il tipo di benchmark utilizzato da Anandtech per testare i terminali pubblicati, ovvero GLbenchmark. Questo tipo di test utilizza una serie di Javascript che vanno a sfruttare unicamente (o quasi sempre) solamente due core della CPU, proprio perchè l’applicazione sviluppata non va a sfruttare a pieno i chip quad-core. In poche parole una CPU a 4 core non viene spremuta come dovrebbe, non riuscendo a liberare tutta la propria forza: uno degli obiettivi principali di un chip multi-core infatti, è quello di stressare di meno ogni singolo core che compone la CPU stessa.
Per far capire meglio questo concetto, ricorrerò ad uno dei miei esempi: immaginiamo che dobbiamo effettuare un trasloco.
Un società A preferisce utilizzare due camion molto rapidi, che quindi sfruttano più benzina e spremono maggiormente il motore al fine di effettuare più viaggi in un determinato arco di ore. Questa è la nostra CPU dual-core.
Un’altra società B invece, decide di utilizzare quattro camion e chiedendo agli autisti di non scannare troppo, di non raggiungere velocità esagerate e di evitare di spremere troppo il motore.Presi singolarmente i camion della società B, essi fanno ovviamente meno viaggi in un determinato arco di tempo rispetto ad un camion della società A, ma essendo appunto un gruppo di quattro camion, riescono a portare a termine il lavoro in tempi comunque brevi. Questa è la nostra CPU quad-core.
Se noi utilizzassimo un metro di giudizio delle società basandoci unicamente sull’utilizzo di due camion a testa, ne risulterebbe vincitore sicuramente la società A, dato che ogni singolo camion viene sfruttato e stressato maggiormente.
Non penso servino conclusioni, ma diciamolo lo stesso: iPhone 5(ripeto…i risultati del test sono stati veramente buoni!) è risultato particolarmente avvantaggiato in questa sfida su Nexus 4 perchè il tipo di test utilizzato premiava il tipo di architettura scelto per la CPU di Cupertino, non valorizzando a pieno le doti del chip Snapdragon del Google Phone.
In pratica,
l'architettura di Cupertino, va a spremere ogni singolo core al massimo, prima di accedere a quello sucessivo. Così si hanno i primi core che vanno la massimo ( che sono quelli verificati con questo tipo di test ), e che danno un risultato OTTIMO!
Mentre per
l'architettura del chip Snapdragon, i 2 core analizzati dallo script del test, stanno andando alla META' della velocità (ma nel complesso, sta andando alla stessa velocità del rivale iPhone5), ed ecco il risultato pessimo ottenuto con quel test

.
Sicuramente, visto la mole di lamentele ricevute, staranno già aggiornando lo script del GLbenchmark utilizzato nel test, per poter sfruttare tutti i 4 core contemporaneamente così da ottenere risultati più validi ed equi su tutti gli smatphone !
Vi aggiorneremo quando il test sarà fatto con lo script aggiornato, e con un Nexu4 non in versione prototipo ma definitvo .
A presto .