Processore multicore

Fino al 2005 quasi tutti i microprocessori (dall'Intel 8086, fino agli Athlon 64 e Pentium 4) sono sempre stati single core e i miglioramenti nelle prestazioni sono passati attraverso aumenti della frequenza di funzionamento, maggiori dimensioni della cache, funzionalità aggiuntive, e miglioramenti dell'efficienza della microarchitettura, grazie anche al continuo progresso dei processi produttivi che ha consentito di ridurre progressivamente l'energia necessaria al funzionamento e offrire le condizioni necessarie per l'aumento della frequenza.

Intel cercò già con il Pentium 4 Northwood, che introduceva la tecnologia Hyper-Threading, di migliorare questo limite dei processori single core, sfruttando in maniera più razionale la lunga pipeline tipica dei suoi processori basati su architettura NetBurst; si trattava in buona sostanza di simulare la presenza di due core, rendendo disponibile al sistema due core "logici". In realtà nell'esecuzione delle applicazioni il contributo di tale tecnologia era marginale ma si otteneva un discreto miglioramento nella reattività del sistema, ottimizzando il multitasking, cioè l'esecuzione di più operazioni contemporaneamente.

Con il progredire dei processi produttivi (fino ad arrivare a quello a 90 nm) e il raggiungimento di frequenze di funzionamento sempre più elevate e vicini ai limiti fisici della tecnologia a semiconduttore, i due principali produttori di chip, Intel e AMD decisero di migrare gradualmente^[2] all'architettura dual core (a due core). In pratica, non potendo aumentare più la frequenza massima si cerca di migliorare il parallelismo, mettendo a disposizione del sistema operativo una configurazione molto simile a quella dei tradizionali sistemi multiprocessore.

Difatti si giunse a un punto tale per cui aumentare ulteriormente le frequenze delle CPU, malgrado le dimensioni minime dei transistor, comportava ormai consumi troppo elevati in relazione al modesto aumento di prestazioni^[3] e questo ovviamente aveva serie ripercussioni anche sul gravoso problema del raffreddamento dei circuiti.

La soluzione che sembrò più ovvia ai progettisti di microprocessori fu quella di puntare tutto sul parallelismo in modo da poter aumentare il numero di operazioni eseguibili in un unico ciclo di clock. Questo nuovo approccio comunque non era del tutto indolore e comportava anche alcuni svantaggi, in quanto i programmi dovevano essere ottimizzati per un utilizzo multi-thread ovvero parallelizzati anch'essi per poter sfruttare appieno le caratteristiche di questi processori, in caso contrario essi avrebbero impegnato solo uno dei core, lasciando l'altro pressoché inutilizzato. Paradossalmente, era anche possibile che un programma applicativo non pensato per un'esecuzione di tipo parallelo risultasse di più lenta esecuzione su un processore multicore rispetto a uno single core, e infatti al momento del lancio dei primi esemplari, erano veramente pochi i software già pronti per queste nuove architetture. Tale incapacità di raggiungere i livelli di prestazione teorici dei sistemi a parallelismo massiccio è nota come "sindrome di von Neumann".

Diversi analisti software, infatti, prevedevano già allora che se il software pensato per un utilizzo parallelo in ambito dual core fosse stato realizzato in maniera oculata, tenendo conto non del funzionamento su un sistema dual core, ma su un sistema a più core, esso non avrebbe richiesto poi grosse modifiche per essere utilizzato su un dual core o su un più generico processore multicore. Secondo altri, invece, gli sforzi necessari per realizzare software multi processore che avrebbe funzionato in maniera ottimale saturando tutti i core e non occupandoli in modo disomogeneo sarebbero stati esagerati in relazione con i reali vantaggi, soprattutto di impatto di costi. Su una materia tanto nuova in ambito desktop, ai tempi non si poteva fare altro che attendere maggiori dettagli, ma il tempo ha poi portato gli sviluppatori ad acquisire sempre maggiore esperienza e dimestichezza con la programmazione parallela e molti dei timori dei primi giorni risultano ormai superati.

I primi esemplari di CPU multicore vennero presentati da IBM con l'introduzione linea POWER4 nel 2001. Tuttavia fu solo nel 2005 che l'interesse del mercato mondiale verso la tecnologia multicore divennne rilevante: in quell'anno i due maggiori produttori di CPU al mondo, Intel e AMD, misero in commercio i primi esemplari di una nuova generazione di microprocessori per il mercato consumer, basati sui rispettivi prodotti esistenti ma contenenti due core. Si trattava delle famiglie di processori Pentium D dalla parte di Intel, e di Opteron e Athlon 64 X2 dalla parte di AMD.

Intel estese progressivamente l'utilizzo della tecnologia dual core a tutti i segmenti di mercato, incluso quello mobile, di cui il primo esponente fu il Core Duo Yonah e successivamente Merom, entrambi evoluzioni del Pentium M, e ovviamente al settore server. In questa categoria i primi dual core furono Montecito evoluzione del processore a 64 bit Itanium 2 con cache L3 che raggiunse in alcune versioni i 24 MB di capacità, mentre per i server x86 basati sul processore Xeon, videro la luce Dempsey e Paxville, pensate rispettivamente per i sistemi workstation e server a 2 e 4 processori. Da Conroe venne derivato anche lo Xeon Woodcrest, per sistemi server di fascia bassa dotati di 2 socket.

I primi processori con più di due core vennero presentati sul mercato già verso la fine del 2005: si trattava del Cell, sviluppato congiuntamente da IBM, Sony e Toshiba per il mercato console e blade server e composto da 8 core eterogenei; e l'UltraSPARC T1, sviluppato da Sun Microsystems per il mercato server, composto da 8 core omogenei.

Nel 2006 Intel continuò ad investire sul mercato consumer introducendo i processori Core 2 Extreme e Core 2 Quad, a quattro core in architettura Kentsfield.

Esistono differenti approcci attraverso i quali si possono realizzare chip multicore, ciascuno con precise peculiarità.

Ci sono casi in cui ci possono essere prodotti con un numero dispari di core, come il triple core di AMD (Athlon II X3 435). Questo tipo di architettura, rispetto alla single core, consente di aumentare la potenza di calcolo di una CPU senza aumentare la frequenza di clock di lavoro, a tutto vantaggio del calore dissipato (che diminuisce rispetto nel caso di più processori separati) così come l'energia assorbita.

Ogni sistema operativo gestisce in modo differente le potenzialità dei processori multicore, in alcuni casi queste gestioni variano anche a seconda della versione del sistema operativo (Windows XP, Windows XP SP2 professional, ecc), tuttavia pur implementando il supporto a varie tecnologie hardware e soluzioni software non è detto che si possa assistere a reali vantaggi, in quanto i programmi non sempre supportano queste architetture hardware in modo efficiente, limitando i vantaggi all'utilizzo di più programmi contemporaneamente, per questo bisognerebbe riscrivere il kernel per poter sfruttare le potenzialità multicore a pieno.^[4][5]

Le prime implementazioni nei sistemi Microsoft si ha con la versione SP2 professional di Windows XP, con un supporto limitato all'architettura hardware SMP (Symmetric multiprocessing o Symmetric multiprocessor) dove i core o processori accedono ad uno spazio di memoria condiviso, mentre dal punto di vista software viene usata la funzionalità processor affinity che identifica i core come Core0 e Core1, consentendo all'utente di decidere su quale di essi avviare ed eseguire l'applicazione, successivamente l'approccio venne rivisto prima con Windows Vista poi con Windows 7, quest'ultimo supporta soluzioni hardware NUMA (Non-Uniform Memory Access)^[6].

Nei sistemi Apple macOS con la versione 10.6 c'è l'introduzione del Grand Central Dispatch per implementare il parallelismo a livello di thread, migliorando il supporto ai multicore.

Nei sistemi basati su kernel Linux, si ha il primo supporto all'hardware SMP con la versione 2 del kernel, che comprendeva un big kernel lock (BKL) per la gestione degli interrupt, successivamente con la versione 2.2 i gestori d'interrupt avevano spinlock differenziati, alcune distribuzioni e ottimizzazioni inclusero il codice di supporto per sistemi NUMA. Nella versione 2.4 sempre più sottosistemi vennero gestiti al di fuori del BKL, grazie all'introduzione di nuovi database lock, ma presenta ancora spinlocks che coprono interi sottosistemi, questo permise di migliorare la scalabilità, che migliorò ulteriormente con la versione 2.5 del kernel, che ottimizzò la cache della pagina dei lock di conversione da un singolo blocco di codice a più blocchi di dati.
Con la versione 2.6 il BKL venne relegato ad una piccola parte del codice del kernel, in quanto la maggior parte del BKL venne convertito in database lock con elevata sintonizzazione e scalabilità per eliminare il ripetersi della linea di cache condivisa, mentre nei sottosistemi critici c'è un certo uso di approcci di lock meno avanzati, quali Read-Copy-Update (RCU), venne introdotto un nuovo programmatore multi CPU di coda, risolvendo le contese sulle code di esecuzione globali condivise da più CPU, riducendo il sovraccarico dei processi di pianificazione in parallelo. Questo scheduler venne introdotto anche su alcuni kernel 2.4 delle ultime distribuzioni.^[7][8] Questa strategia ha permesso al kernel linux in elevata scalabilità ed effettivi miglioramenti con sistemi multicore^[9]

In ambito videoludico e in particolar modo delle librerie grafiche le DirectX 12, Vulkan (API) e Mantle hanno permesso il migliore sfruttamento dei diversi core del processore, permettendone il dialogo attivo e diretto con la GPU, cosa che in precedenza non era attuabile se non in modo limitato^[10]

Lo sfruttamento da parte delle applicazioni e situazioni operative varia molto a seconda degli stessi e a seconda del sistema operativo utilizzato^[11]

• Architetture di sistemi multiprocessore
• Calcolo parallelo
• Scalabilità
• Sindrome di von Neumann

• Architetture multicore: solo moda o reale necessità?, su appuntidigitali.it.