Con "l'avvento" del Samsung Galaxy S4, non c'è stata molta chiarezza sulla piattaforma che utilizza, e sul suo hardware. Ciò nonostante, sarà commercializzato in 2 versioni, una con supporto LTE e utilizzante piattaforma Qualcomm Snapdragon 600 (Quad Core), e una variante solo 3G basata sulla nuovissima piattaforma Exynos 5 Octa (4+4 core).
Ma cosa vuol dire veramente una piattaforma Octa Core su uno smartphone di queste dimensioni?
In molti si chiedono che senso abbia, e in effetti 8 core non vengono nemmeno sfruttati in ambito desktop, figuriamoci in ambito mobile dove il multithreading è ancora poco gestito (o gestito relativamente). Il motivo per cui ha spinto Samsung ed ARM a progettare una piattaforma del genere, è che non si tratta di un VERO Octa Core a singola CPU come molti pensano, ma l'architettura dell'Exynos di nuova generazione è molto più complessa ed elaborata, e permette di essere sfruttata in diverse modalità.
Il nuovo Exynos 5 Octa Core sfrutta una nuova architettura progettata da ARM denominata big.LITTLE, che permette di sfruttare la potenza di calcolo di una CPU Cortex A15, abbinata al risparmio di una CPU Cortex A7, entrambe sulla stessa scheda, e gestite intelligentemente dallo scheduler del kernel.
Come si traduce tutto questo in parole semplici? Con l'utilizzo dell'architettura big.LITTLE, il telefono decide da solo quali core attivare, in base al carico necessario al sistema per muovere i processi in corso. Tutto questo si traduce in maggior efficienza energetica del sistema (fino al 70% di risparmio energetico a parità di potenza di calcolo), ma anche il poter sfruttare la potenza pura erogata dalla CPU Cortex A15 che, seppur esosa di energia, possiede una architettura tale da poter gestire un'enorme mole di dati e processi.
Nella maggior parte dei casi, quindi durante l'uso di task leggeri, vengono utilizzati solamente i core Cortex A7, che garantiscono un ottimo rapporto prestazioni/consumi, incentrandosi principalmente sui consumi. Nell'architettura presentata sull'Exynos Octa, la CPU Cortex A7 presenta un range di frequenze da 200Mhz a 1.2Ghz, ovviamente in base al carico designato.
Ogni core A7 è "linkato" in coppia ad un core A15, in questo modo solo uno dei due core della coppia può essere attivo allo stesso momento (questo nella implementazione corrente del kernel).
Quando il carico di un core A7 è molto elevato, e richiede più potenza, i processi "migrano" sul corrispettivo core A15 della coppia, beneficiando di una velocità nettamente maggiore, ma richiedendo anche più dispendio energetico; da qui il termine "CPU Migration" per indicare il funzionamento dell'architettura big.LITTLE.
Entrambe le CPU sono interconnesse tra loro mediante il CoreLink CCI-400, una sorta di bus dati che permette una veloce e facile migrazione di qualsiasi processo tra le due CPU, il tutto gestito dal kernel scheduler mediante driver appositi.
Questa immagine riassume la struttura interna dell'architettura big.LITTLE (mostrata nel caso di un 2+2 core), denotando come tutto il sistema sia interconnesso mediante il CCI, ma i due processori sono a loro volta interconnessi mediante il GIC-400, che permette una gestione indipendente delle sole CPU, a differenza del CCI che deve tener conto di una coerenza attraverso tutto il SoC.
Come si è potuto facilmente dedurre, lo scopo principale di questa architettura è fornire ottime prestazioni generali, ottimizzando drasticamente i consumi, fino ad un risparmio che varia dal 50 al 70% (in base alle caratteristiche del SoC e alla implementazione software).
Ad ogni passaggio di CPU/Core, ogni coppia di core passa da una curva ad un'altra, migliorando l'aspetto energetico o l'aspetto performance.
Ogni CPU opera con tutti i suoi core alla stessa frequenza (architettura ARM standard), cosicché ogni task di ogni CPU è accelerato allo stesso modo. Quando avviene la migrazione dei processi, le frequenze di migrazione spesso coincidono, in modo da ottimizzare ulteriormente l'accelerazione di quel task preciso senza sbalzi di frequenza notevoli (che sprecano cicli della CPU).
Esistono due implementazioni principali di questa migrazione, entrambe valide ma con conseguenze diverse.
La prima, utilizzata correntemente nella piattaforma Exynos Octa, accoppia ogni core A7 con un A15, e migra i processi da un core all'altro in base alle esigenze.
Nella seconda implementazione, più complessa, non avviene il CPU Migration ma il Task Migration, cioè ogni CPU viene gestita a se stante, e quando tutti i core A7 sono carichi, viene trasferito il carico sulla CPU A15, lasciando sui core A7 i task più leggeri. Questo permette altissime prestazioni nel caso di enormi carichi di lavoro, ma ha lo svantaggio di rallentare il sistema ai carichi medio/bassi, proprio dovuto all'implementazione.
Ogni architettura CPU ha degli svantaggi, e la complessità hardware e software del big.LITTLE fa si che possano continuamente sorgere dei problemi se non implementato a dovere.
In primis, ogni migrazione tra una CPU e l'altra di ogni processo, spreca cicli della CPU, mediamente intorno ai 20.000 cicli (calcolato a 1Ghz di frequenza), che potrebbero essere impiegati per altri tipi di calcoli. Questo causa i cosiddetti "microlag" durante il passaggio di CPU, probabilmente impercettibili vista la velocità con cui avviene lo switch, ma se lo scheduler del kernel si rivela poco ottimizzato, allora ciò potrebbe palesarsi durante l'esperienza d'uso dell'utente finale.
Un altro svantaggio risiede nella implementazione software. Nonostante l'architettura sia un REALE 8 core, ne vengono usati solo 4 alla volta, perdendo quella consistenza che potrebbe teoricamente avere una architettura di questo calibro. Spiegheremo più avanti come si è riusciti ad ovviare a questa limitazione.
Per finire, il processo produttivo di un SoC che utilizza questa architettura è più lungo, complesso e dispendioso di architetture "normali" a singola CPU. Ed è questo il motivo per cui, da come si è visto in molte notizie, il Galaxy S4 arriverà in scorte limitate nel mondo per quanto riguarda il modello 3G Exynos.
Come avevamo accennato nella pagina precedente, questa architettura in realtà è un VERO 8 core, nonostante abbia 2 CPU separate.
Il secondo tipo di implementazione di cui si è citato sempre nella pagina precedente, permette una migrazione totale di tutti i task da una CPU all'altra, in base alla loro pesantezza, e non sfruttando la coppia di core. Questo tipo di gestione però presenta un problema sostanziale a livello software.
Infatti lo scheduler del kernel non riesce a capire preventivamente se il nuovo processo necessita della potenza di calcolo offerta dai core A15, o basterebbe solo l'A7.
Il Team Linaro (famoso per le ottimizzazioni riportate in ambito Linux e android) è riuscito ad implementare questo tipo di algoritmo nel kernel Linux 3.8 (sarà aggiunto in seguito al mainstream), che permette l'utilizzo di entrambe le CPU presenti nel SoC come se fossero "fuse" assieme: i task leggeri migreranno verso i core A7, mentre quelli pesanti migreranno verso i core A15, utilizzando tutti gli 8 core assieme, ed ottimizzando la velocità del sistema.
Purtroppo questo nuovo algoritmo è ancora in fase preliminare di testing, e sarà pienamente funzionante e attivo tra qualche mese, ma le aspettative sono molto alte e trasformerebbe qualsiasi big.LITTLE in un sistema che può tener testa ad un desktop come gestione del multitasking.
Una ulteriore evoluzione della piattaforma big.LITTLE, che avanzerà nei prossimi anni, è l'utilizzo delle nuove architetture di CPU denominate Cortex A53 e A57, basate su architettura ARMv8 a 64 bit (AArch64), che permettono di sfruttare un massimo di 16 core totali mediante l'utilizzo del CoreLink CCN-504 come bus di interconnessione. Questa evoluzione inoltre permette l'utilizzo di memorie RAM DDR4 ad alta velocità, che contribuiscono alle performance estreme della piattaforma.
Di sicuro possiamo considerare questo nuovo tipo di architettura come un grande passo in avanti in ambito mobile, soprattutto nella gestione dei consumi, che si rivela uno dei maggiori problemi che si riscontrano nei terminali mobili odierni. ARM e la sua relativa architettura sono in continua evoluzione, quindi non possiamo fare altro che attendere per una corretta implementazione di questa tecnologia, in modo da beneficiarne al massimo dei suoi vantaggi, minimizzando i lati negativi.
Per chi fosse interessato alle prestazioni REALI di questa piattaforma, invito a visionare alcune video recensioni del Galaxy S4 variante I9500 (l'unica con l'Exynos Octa), in modo da farsi una idea su come la gestione dei core sia implementata su un vero terminale, e come gli svantaggi influiscano sull'utilizzo giornaliero.
Per ulteriori approfondimenti, dettagli tecnici e qualsiasi altra informazione in merito all'argomento dell'articolo, rimando direttamente al sito ufficiale ARM, e a quest'altro file PDF ufficiale ARM che spiega le principali differenze tra una architettura omogenea e una eterogenea (come il big.LITTLE).
MegaLab.it rispetta la tua privacy. Per esercitare i tuoi diritti scrivi a: privacy@megalab.it .
Copyright 2008 MegaLab.it - Tutti i diritti sono riservati