Link alla notizia: https://www.hwupgrade.it/news/cpu/alder-lake-m-p-e-s-nel-settore-mobile-il-futuro-ibrido-di-intel-per-sfidare-amd_96064.html

Una slide apparsa in rete sembra svelare la composizione della futura offerta mobile Alder Lake di Intel. I Core di 12esima generazione, successori di Tiger Lake, punteranno su un design ibrido fatto di core ad alte prestazioni, insieme a core più efficienti, per coprire varie fasce di mercato.

Click sul link per visualizzare la notizia.

Il gigante si è svegliato dal lungo letargo? Grazie concorrenza (leggi AMD, M1 etc)

Ottimo, adesso bisogna solo aspettare quei 3-4 anni per far si che gli scheduler dei vari SO vengano ottimizzati per supportare questi proci pseudo-bigLITTLE :stordita:

Ottimo, adesso bisogna solo aspettare quei 3-4 anni per far si che gli scheduler dei vari SO vengano ottimizzati per supportare questi proci pseudo-bigLITTLE :stordita:

intel ha lavorato su uno scheduler hardware che non richiede modifiche all' os

intel ha lavorato su uno scheduler hardware che non richiede modifiche all' os
Di fatto gli 8c vengono visti dall'OS come Thread Aggiuntivi dell'8C in assenza di "Switch Software" rendendo di fatto compatibile tutto il software pre esistente.

Per il software classico verrà visto come 8C con 24 Thread al posto di 16
Per il software scritto ad hoc potrà scegliere di indirizzare dei task ben specifici per gli 8c avendo più prestazioni e non ingolfando gli 8C

Ottimo, adesso bisogna solo aspettare quei 3-4 anni per far si che gli scheduler dei vari SO vengano ottimizzati per supportare questi proci pseudo-bigLITTLE :stordita:
Per il supporto da parte del S.O. ci vuole poco, semmai bisogna vedere cosa succederà con le applicazioni che usano il multithreading e/o più processi che girano in parallelo.
Se è vero che i core "little-x86" non supportano certe estensioni tipo AVX-512 mentre i core big le supportano, immaginate cosa succede quando un software che usa le AVX-512 identifica 6 core virtuali (4 "little" ed 1 "big" con hyperthreading) e lancia 6 processi che usano AVX-512.
In pratica si ottiene un processore con le prestazioni di risparmio energetico di un Atom quad core quando è poco carico e che con software "pesante" gira come un i3 single core con hyperthreading (e che mi sa dopo poco cala pure di frequenza per stare dentro l'inviluppo termico dichiarato).
Ma questo significa anche che il supposto risparmio energetico grazie ai little ... non avviene se c'è un applicazione "leggera" che usa AVX512 e che risveglia il core big ogni volta che gira anche quando basterebbe un core little con una implementazione di AVX-512 "meno performante ma a basso consumo". :muro:

Possibile che Intel non si sia resa conto del perchè ARM supporta lo stesso set di istruzioni sia sui core big che quelli little?!?!?
Una possibile spiegazione è che intenda abbandonare AVX-512 ed implementare a sua volta delle estensioni vettoriali scalabili come ARM, ma è più probabile che abbiano improvvisato la cosa per uscire sul mercato il prima possibile.

Il gigante si è svegliato dal lungo letargo? Grazie concorrenza (leggi AMD, M1 etc)
Questi sono progetti in cantiere da anni...
Per il supporto da parte del S.O. ci vuole poco, semmai bisogna vedere cosa succederà con le applicazioni che usano il multithreading e/o più processi che girano in parallelo.
Se è vero che i core "little-x86" non supportano certe estensioni tipo AVX-512 mentre i core big le supportano, immaginate cosa succede quando un software che usa le AVX-512 identifica 6 core virtuali (4 "little" ed 1 "big" con hyperthreading) e lancia 6 processi che usano AVX-512.
In pratica si ottiene un processore con le prestazioni di risparmio energetico di un Atom quad core quando è poco carico e che con software "pesante" gira come un i3 single core con hyperthreading (e che mi sa dopo poco cala pure di frequenza per stare dentro l'inviluppo termico dichiarato).
Ma questo significa anche che il supposto risparmio energetico grazie ai little ... non avviene se c'è un applicazione "leggera" che usa AVX512 e che risveglia il core big ogni volta che gira anche quando basterebbe un core little con una implementazione di AVX-512 "meno performante ma a basso consumo". :muro:
Bisogna vedere come vengano visti i singoli core (thread hardware) dalle applicazioni: se sono tutti uguali, oppure se per ognuno è possibile ottenere le specifiche proprietà (AVX-512). L'istruzione CPUID eseguita su specifici core può benissimo riportare valori diversi.

Questa potrebbe essere una soluzione: le applicazioni allocano i processi/thread soltanto su specifici core/thread hardware.

Ovviamente la soluzione più semplice è che tutti i core siano uguali. Anche quelli "piccoli" potrebbero tranquillamente implementare le AVX-512, senza necessariamente diventare troppo grandi.
Possibile che Intel non si sia resa conto del perchè ARM supporta lo stesso set di istruzioni sia sui core big che quelli little?!?!?
Sei sicuro di questo? Ricordo di aver letto di core eterogenei, ma dopo tanto tempo potrei sbagliarmi.
Una possibile spiegazione è che intenda abbandonare AVX-512 ed implementare a sua volta delle estensioni vettoriali scalabili come ARM,
Non credo proprio. Anzi, potrebbe anche tirare fuori delle AVX-1024 in futuro, visto che è rimasta l'ultima codifica disponibile per indicare la dimensione dei vettori.

Comunque potrebbe anche trasformare le AVX-512 in un'estensione vector-length-agnostic senza dover cambiare tanto a livello di ISA.
ma è più probabile che abbiano improvvisato la cosa per uscire sul mercato il prima possibile.
Non credo nemmeno a questo: sono progetti che richiedono anni di progettazione.

Sei sicuro di questo? Ricordo di aver letto di core eterogenei, ma dopo tanto tempo potrei sbagliarmi.

Che io ricordi tutti, gli ARM big-Little hanno i core big e little che supportano lo stesso set di istruzioni.

A quanto mi risulta, si usano core ARM con differenti set di istruzioni nello stesso chip/package solo in SoC in cui hai dei core dedicati a far girare S.O. ed applicativi di alto livello (tipicamente Cortex A) ed altri core ottimizzati per il lato embedded (tipicamente Cortex M) ma con latenze più basse che fanno girare solo codice con requisiti hard realtime su un S.O. realtime oppure baremetal.

Ad esempio, ultimamente è uscita la famiglia STM32MP1 che integra 1..2 core Cortex-A7 (in base al modello specifico) con interfaccia per ram esterna ed un core Cortex-M4F con 448KB di ram dedicata; si tratta di chip automotive grade con range di temperatura -40°C ... +125°C , con gli A7 che viaggiano a 650MHz e l'M4F a 209MHz, con ethernet ad 1Gbps, CAN FD, ecc. ecc.

Se ricordo bene, pure parecchi SoC usati su smartphone e tablet di solito oltre ai core big-LITTLE senza metterlo nelle specifiche del prodotto finale integrano 1..2 core Cortex-M "di servizio", ma tali configurazioni sono più diffuse per applicazioni embedded, visto che in passato si usavano configurazioni a due schede ("applicativo/frontend/server" e "controller hard realtime"), poi diventate a "due cpu su sezioni separate della stessa scheda" per arrivare ora a SoC che di solito integrano quasi tutto il lato digitale eccetto le memorie.