Processori moderni: come vengono gestiti i carichi di lavoro tra i vari tipi di core

La britannica ARM, con l’architettura big.LITTLE prima (2011) e con DynamIQ poi (2017; vedere ARM presenta la tecnologia DynamIQ, evoluzione di big.LITTLE) ha introdotto una filosofia nuova per quanto riguarda i suoi processori abbinando cluster composti da core più potenti a core a basso consumo energetico (i.e. quattro core di un tipo in un cluster, quattro core di un altro tipo nell’altro).
L’idea è quella di mettere un dispositivo (anche un device mobile come uno smartphone) nelle condizioni di eseguire e concludere rapidamente un compito che richieda una notevole potenza computazionale e, dall’altro, far sì che la batteria possa durare di più eseguendo le attività “ordinarie” facendo leva sui core a basso consumo energetico.

Con l’approccio big.LITTLE, quando si passa dall’utilizzo di un cluster ad elevate prestazioni a uno con maggiore efficienza energetica, si sperimenta sempre un consumo di energia addizionale: è il “costo” che si paga nel passare thread e informazioni connesse da un cluster all’altro. Con DynamIQ ARM ha superato queste problematiche grazie proprio alla possibilità di usare diversi tipi di core in uno stesso cluster.

DynamIQ permette di abbinare fino a 8 core di vario genere per cluster e ciascun core lavora a frequenze differenti per ridurre la temperatura e massimizzare le prestazioni.
Inoltre, vengono attivati solo i banchi di memoria necessari in un dato momento.

Adesso che anche Intel sembra essersi ispirata all’approccio big.LITTLE in vista del lancio dei suoi processori Alder Lake, i primi dell’azienda di Santa Clara a usare uno schema MCM (multi-chip module) per il mercato mainstream: Processori Intel Alder Lake in configurazioni da 6, 10, 14 e 16 core, è interessante mettere a fuoco le modalità con cui – durante l’utilizzo di un processore – viene scelto in maniera prioritaria l’uso di un cluster piuttosto che dell’altro (core a elevate prestazioni oppure core a basso consumo energetico).

Come considerazione di carattere generale, indipendentemente dalla tipologia di dispositivo col quale si ha a che fare (quindi dallo smartphone fino al server), la regolazione delle impostazioni energetiche influisce sulle prestazioni e non sempre in misura proporzionale.
L’efficienza energetica è il rapporto tra il lavoro svolto e la potenza media richiesta durante un determinato periodo di tempo. L’equazione di riferimento è la seguente: Efficienza energetica = Tasso di lavoro svolto / Media Watt richiesti.
È possibile utilizzare questa metrica per fissare obiettivi che tengano conto del compromesso tra potenza e prestazioni. Ed è proprio usando la metrica dell’efficienza energetica che è possibile prendere una decisione più consapevoli rispetto all’utilizzo di metriche basate esclusivamente sulla potenza o sulle performance.

In particolare, lo sviluppo di applicazioni mobili richiede un attento bilanciamento tra il consumo di energia e le prestazioni della CPU, operando entro specifici vincoli termici.
Come abbiamo accennato in apertura, l’architettura ARM big.LITTLE è stata una vera e propria pietra miliare.

Le ottimizzazioni per l’utilizzo dei processori che usano schemi MCM e blocchi di core differenti avvengono a livello hardware ma possono essere svolte in combinazione con il sistema operativo. Per raggiungere questo obiettivo, speciali API visibili e utilizzabili da parte dei programmatori consentono loro di fornire “suggerimenti” al sistema su come vorrebbero che la piattaforma controllasse il consumo di energia e le prestazioni.

Nello sviluppo di applicazioni mobili si desidera che la propria applicazione soddisfi prima di tutto i requisiti di consumo energetico e poi possa ottimizzare le sue prestazioni.
In ambito “mobile” i core a elevate prestazioni dovrebbero idealmente essere impiegati solo per brevi periodi di tempo e per compiti “pesanti”. Ma com’è possibile definire un’attività “pesante”?

La classificazione delle attività da svolgere a livello di processore come “pesanti” o meno può essere effettuata in diversi modi.
Si può ad esempio fare la media dei carichi di lavoro della CPU in un intervallo di tempo (ad esempio, entro finestre di 1 ms), impostando una soglia di carico di lavoro del processore al di sopra della quale un’attività è considerata “pesante” e/o classificando tutte le attività di esecuzione più brevi – svolte su base periodica – come “non pesanti”.
In alcuni casi potrebbe risultare necessario utilizzare strumenti di profilazione durante lo sviluppo delle applicazioni per aiutare a classificare correttamente ciascuna attività.
Va detto anche che alcune attività possono diventare da “pesanti” a “non pesanti” nel corso del tempo: ragione per cui è fondamentale trovare il bilanciamento ottimale.

Un’altra area da tenere d’occhio è l’eccessivo o inutile risveglio dei core inattivi che può comportare un maggiore consumo energetico. Una soluzione consiste nell'”impacchettare” le attività sullo stesso core cercando di scongiurare sovraccarichi.

Sulla piattaforma ARM, a partire dai SoC big.LITTLE, per gestire efficacemente le varie problematiche si usano diversi strumenti. I core “LITTLE” sono quelli che offrono una migliore efficienza energetica seppur sacrificando le prestazioni; i core “big” sono invece quelli più potenti e con il maggior appetito in termini energetici.

Il primo si chiama Core clustering: i core della stessa dimensione vengono trattati come un unico cluster; viene poi scelto il cluster più appropriato da usare in base alle esigenze del sistema.

Con la tecnica In-kernel switching core “big” e “LITTLE” vengono accoppiati a formare un core virtuale in cui viene utilizzato solo uno dei due core fisici che formano quello specifico core virtuale, a seconda delle esigenze. Un approccio che assicura una maggiore efficienza rispetto al Core clustering ma richiede che le caratteristiche dei core siano le stesse.

Con il Global task scheduling tutti i core fisici sono sempre disponibili ed è compito del task scheduler globale assegnare le attività da svolgere a livello di core a seconda delle esigenze. Anche i tecnici di Qualcomm indicano questo metodo come una scelta ottimale perché lo scheduler del sistema operativo può allocare il lavoro su qualsiasi core, tutti i core o qualsiasi combinazione, mentre i core non utilizzati vengono automaticamente disattivati. Questa soluzione non richiede configurazioni di core che abbiano una reciproca corrispondenza, può reagire più rapidamente alle variazioni dei carichi e il lavoro può essere allocato con un livello di granularità più fine rispetto all’utilizzo del Core clustering.

Una volta l’ottimizzazione era qualcosa che si faceva alla fine del progetto ma con i processori multi-core di oggi si tratta di un’attività da pianificare e svolgere sin dalle prime fasi dello sviluppo di un’applicazione.
Nel caso di Qualcomm, l’azienda mette a disposizione un pacchetto SDK per sviluppatori (Snapdragon Power Optimization SDK) progettato per supportare cinque modalità per l’utilizzo del processore tra le quali i programmatori possono scegliere.

La “modalità efficiente“, ad esempio, permette di raggiungere prestazioni vicine al migliore risparmio energetico possibile; “performance burst mode” supporta tutti i core alla massima frequenza per un breve periodo di tempo (utile per le elaborazioni più pesanti così da sfruttare le massime prestazioni); “modalità saver” fornisce circa la metà delle prestazioni di picco del sistema e aiuta quando i requisiti di prestazione dell’applicazione sono comunque contenuti; “modalità window“, per regolare con precisione il bilanciamento prestazione/potenza (si impostano percentuali di frequenza minima e massima rispetto alla frequenza massima che i core possono usare); “modalità normale“, per riportare il sistema allo stato di default.

Prestazioni, potenza e temperatura sono ora tutti i vincoli di progettazione di primo ordine. Bilanciare l’efficienza energetica, i vincoli termici e le prestazioni richiedono alcuni mezzi per trasmettere i dati sul consumo di energia e sulla temperatura in tempo reale – in hardware – ai gestori intelligenti delle risorse.

Poste le marcate differenze tra l’architettura ARM (vedere Differenza tra processori ARM e x86), sembra proprio che Intel, con i suoi Alder Lake, abbia in programma il rilascio di processori estremamente versatili ed efficienti che rompono in maniera netta con il passato.
Stando alle ultime indiscrezioni (Processori Intel Alder Lake in configurazioni da 6, 10, 14 e 16 core), pare infatti che alcune CPU useranno cluster con configurazioni assolutamente non speculari: in alcuni modelli 2 core ad elevate prestazioni sarebbero affiancati da un cluster composto da 8 core a risparmio energetico. Ma ci saranno configurazioni anche a 8+8 core per un totale di 16 core fisici.