Fino al 2021 tutti i core di un processore consumer erano identici. Con Intel Alder Lake questa certezza è saltata: per la prima volta un chip x86 mainstream monta due tipi di core radicalmente diversi sullo stesso die. È una svolta che cambia il modo di pensare alle prestazioni.
Il problema che i core eterogenei risolvono
Un processore moderno non fa sempre la stessa cosa. A volte esegue un gioco o un video in rendering che satura tutti i core. Più spesso, però, gestisce decine di processi leggeri in background — notifiche, sincronizzazione cloud, antivirus, servizi di sistema — che non richiedono potenza ma consumano risorse se non gestiti bene.
Con core omogenei hai due scelte: core grandi e potenti (ma che sprecano energia sui task leggeri) o core piccoli ed efficienti (ma che soffrono sui carichi pesanti). I core eterogenei risolvono il problema mettendo entrambi sullo stesso chip.
L'idea viene da ARM: big.LITTLE
Intel non ha inventato questa idea. ARM ha introdotto l'architettura big.LITTLE nel 2011, pensata inizialmente per i processori mobile. L'iPhone e i processori Android usano questa filosofia da oltre un decennio — è il motivo per cui uno smartphone riesce a durare tutto il giorno pur avendo un chip da diversi miliardi di transistor.
Intel ha portato lo stesso concetto nell'architettura x86, con le complicazioni che questo comporta: il set di istruzioni x86 è molto più complesso di ARM, e mantenere la compatibilità tra core diversi sullo stesso chip non è banale.
P-core: massima potenza per core
I Performance core sono i core "grandi". Hanno pipeline più profonde, cache L2 più ampie, unità di esecuzione più numerose e supportano l'Hyper-Threading — la tecnologia che permette a un singolo core fisico di gestire due thread in parallelo condividendo le risorse interne.
Sono ottimizzati per la latenza: completano ogni singolo task nel minor tempo possibile. Per questo sono la scelta giusta per giochi, rendering, compilazione e qualsiasi applicazione single-threaded o che richiede risposta immediata.
E-core: efficienza sopra tutto
Gli Efficiency core sono l'opposto. Sono fisicamente più piccoli — quattro E-core occupano circa lo stesso spazio di un P-core — e non supportano l'Hyper-Threading. Hanno cache più limitate e frequenze di boost inferiori.
In compenso consumano molto meno energia per operazione. Per i task in background — processi di sistema, aggiornamenti, sincronizzazioni — sono più che sufficienti e permettono di tenere i P-core in stati di risparmio energetico più profondi.
Il Thread Director: chi decide dove va ogni thread
Il problema dei core eterogenei è l'orchestrazione: come fa il sistema operativo a sapere su quale tipo di core eseguire ogni thread? La risposta di Intel si chiama Thread Director, un meccanismo hardware che monitora il comportamento di ogni thread e suggerisce al sistema operativo la classificazione ottimale.
Thread Director distingue quattro classi di thread: compute intensivo, non-compute intensivo (prevalentemente attesa I/O), con istruzioni AVX512, e con istruzioni in modalità risparmio. Windows 11 e i kernel Linux dalla versione 5.18 in poi sono in grado di leggere questi suggerimenti e assegnare i thread di conseguenza.
Arrow Lake: la versione attuale
Con Arrow Lake (2024) Intel aggiorna entrambi i tipi di core. I nuovi P-core Lion Cove abbandonano l'Hyper-Threading — una scelta controversa che Intel giustifica con una maggiore efficienza della singola pipeline. I nuovi E-core Skymont sono invece molto più capaci dei precedenti Gracemont, con prestazioni fino al 32% superiori per core.
Il risultato è un processore dove la distanza prestazionale tra P-core e E-core si è ridotta, rendendo l'orchestrazione più flessibile e la gestione termica più prevedibile.
Vale la pena per un uso generico?
Per la maggior parte degli utenti, la risposta è sì. I sistemi operativi moderni gestiscono la complessità in modo trasparente, e il guadagno in efficienza energetica è reale — specialmente nei portatili, dove i processori con core eterogenei reggono meglio sotto carichi misti.
La complessità emerge solo in scenari specifici: applicazioni che non sono state aggiornate per gestire la diversità dei core, o workload che richiedono latenza ultra-bassa e per cui l'assegnazione al core sbagliato fa differenza.