CPU Meteor Lake, Intel pronta a introdurre un terzo tipo di core? Spunta LP E-core

Bisogna vedere perché quegli applicativi non li usano.
Librerie obsolete? Framework obsoleto?

ci sono moltissime possibilità, sì può essere un problema software, ma come ho scritto prima dipende molto dal target della sh e non sempre vuole le ultime features proprio perché può voler dire perdere parte del proprio target aggiungendo una feature non essenziale.

Ma non facciamo finta di vivere nel mondo delle fate caspita.

E' da 20 anni che nel mondo PC l'hardware non è mai sfruttato appieno e tu ti chiedi ancora il perchè ? Non sarà mai sfruttato, è l'HW che deve andare incontro al SW nel mondo PC Desktop, se aspetti il contrario fai prima a crepare di vecchiaia.

La questione dell'ottimizzazione del codice si spinge ben oltre a quanto hai detto tu, visto che le ottimizzazioni di carattere architetturale come quelle che hai descritto relativamente agli Int64 sono a carico del compilatore o delle librerie di calcolo già pronte che creano due path, uno per la versione che non supporta i dati a 64 bit nativamente e uno che li supporta.

Sono ottimizzazioni che sono sempre state fatte, basta pensare a tutte quelle applicazioni che fanno uso delle istruzioni nuove/avanzate che non sono disponibili su tutti i proc, a partire dalle istruzioni MMX per finire con le AVX-512.

Ma ci sono 2 tipi di ottimizzazioni, quelle a basso livello e quelle di alto livello, o progettuale. Le prime se le smazzano come detto percorsi separati di codice per eseguire quello migliore per l'HW su cui gira l'applicativo.
Le seconde invece sono a carico dell'architetto che disegna l'applicativo e può essere subordinato all'uso (coercitivo o meno) da parte dell'OS/Framework di definire certi comportamenti a priori.
Per fare un esempio, su Android definisci lo scopo di una azione, non solo il codice dell'azione, il che permette a framework usato di capire cosa vuoi fare con quell'azione e la ottimizzerà rispetto alle risorse in quel momento a disposizione.
Quindi saprà se è utile o meno svegliare un mega core per fare l'operazione il più velocemente possibile oppure lasciarla sul core più lento e risparmioso che tanto non serve che venga svolta in un picosecondo. Android si è sviluppato su architetture che avevano core ibridi e un sacco di estensioni non standard da supportare.
Su x86 non c'è questa cosa, perché storicamente non è mai esistito un core a basso consumo per svolgere compiti in background.
Quindi non è solo questione di usare il giusto set di istruzioni, ma anche di sfruttare al meglio l'architettura intesa come tutte le risorse messe a disposizione. Non essendoci una indicazione da parte del programmatore sull'intenzione dell'azione, Intel si è inventata il Thread Director che su base statistica / AI / euristica o chissà cosa deciderà come trattare una certa azione in maniera autonoma. E non è detto che lo faccia sempre correttamente, perché un task che lavora continuamente non è detto che debba necessariamente aver bisogno di un P-Core così come un'azione semplice non è detto che sia meglio eseguirla su un E-core perché magari la latenza è importante per il risultato. Ma se non c'è una indicazione di scopo, una scelta vale l'altra.
Storicamente anche il semplice sfruttamento dell'HT è stato un problema: un'applicazione crea 4 thread su un quad core con HT, come li allochiamo i thread? A coppie di 2 su uno stesso core fisico per sfruttare la coerenza spaziale dei dati, o su core fisici separati per sfruttare al meglio le unità di calcolo?

Ogni evoluzione porta a questi problemi. O si rimane dove si è per usare al meglio quello che è sviluppato fino a quel momento, oppure se ci si porta avanti inevitabilmente qualcosa non funziona al meglio perché si lascia lo sviluppo indietro (e quindi non ottimizzato).

Complice di tutto questo è anche la ristrettezza di visione di MS che nei suoi OS piace cambiare le icone, i bordi delle finestre e gli effetti di trasparenza (ora sì, ora questa versione un pochino, in questa no assolutamente, in quest'alta rimettiamoli va che al versione precedente era uno schifo) e i model driver così da rendere incompatibile le cose senza davvero migliorare nulla con il driver nuovo (ma se non rendi incompatibile nessuno aggiorna, regola di marketing) ma non ha mai sviluppato qualcosa che fosse realmente una astrazione tra le idee dello sviluppatore e la macchina (che non è semplicemente una astrazione tra il codice e la macchina).
Per fare un esempio di sviluppo andato a male, neanche le librerie che dovrebbero essere standard lo sono, ve ne sono 20 mila versioni e ovviamente ogni programma usa la propria versione di .dll (quando erano nate come Dynamic Link Library, con l'idea che ce ne fosse una sola sul filesystem e il programma andava a caricare quella e basta, ora praticamente sono delle .lib separate). Se sono .dll messe a disposizione dall'OS ce ne sono 20 versioni installate in altrettante sottocartelle con tracciamento infinito nel file di registro e se qualcosa va sorto in un update...

In tutti questi anni di "nuovi OS" lucidi, trasparenti, colorati e infine minimalisti, MS non ha sviluppato nemmeno un sistema di priorità degli I/O, per cui il masterizzatore ha la stessa priorità del browser e se li usi insieme, con tutta la porcheria che quest'ultimo scrive e legge per ogni pagina, il buffer underrun è assicurato.

Non ci sarà soluzione all'"ottimizzazione" finché non si passerà ad usare framework intelligenti (che non sono certo i .NET di MS, pure quelli è riuscita a rendere incompatibili tra di loro con mille mila versioni diverse) che sanno cosa fare e non lasciare il programmatore a indovinare che cosa ci sarà sotto a far girare il suo applicativo.
Altrimenti ritorniamo al tempo del C64 e dell'Amiga, computer fatti e finiti per i quali si scriveva codice apposito che non era destinato ad essere compatibile con nient'altro.

Sò benissimo come funziona la cosa, era per definire in modo "terra-terra" le problematiche di ottimizzazione HW-SW e sul perché spesso i SW non sono ottimizzati e come software, intendo dal calc.exe al sistema operativo

E' esattamente il contrario
Se è l'hardware ad andare avanti, il software può essere migliorato con un'update se fosse il software ad andare più veloce come features l'hardware che hai lo butti ad ogni update e ne compri di nuovo.

Per capirsi, è inutile cercare di avere un motore da 10.000 CV se poi hai le ruote di ferro, come vice versa è inutile montare delle gomme slick della Ferrari da F1 su una carrozza trainata da cavalli, ci dev'essere una "molla" che ti permetta di stare in sicurezza: gomme con ferro-legno/gomma sulla carrozza e gomme slick della ferrari da f1 sull'auto con motore da 10.000CV, idem così per il SW e HW, però magari in questo coso il vantaggio lo DEVE avere l'hardware, per ovvie ragioni.

Magari funzionasse! Ma la serie 12 con gli E-core sui notebook attualmente in commercio consuma ancora il 50% in più di AMD, soprattutto in carichi medio-leggeri dove invece dovrebbero entrare in gioco gli e-core, basta vedere la prova dell'ultimo Matebook 16s qui su hwup:
vado a memoria, in sintesi consumo navigazione web +28%, consumo netflix +64% (alla faccia del nuovo decoder hw).
Dai dati sembra che invece di migliorare i consumi peggiorino proprio nei carichi intermedi, cosa che succedeva anche su android nei primi tempi delle arch big.little, ma probabilmente anche dopo, solo che non ho più seguito.


Esatto, me lo ricordavo anche io questo problema, sono passati 20 anni e non è cambiato nulla?

Ma non c'è una soluzione ideale. Dipende da cosa fanno e che dati usano i thread
Se si potesse dire all'OS lo scopo (o il tipo) di thread creato sarebbe più facile per lui capire se è un thread ad alta computazione che necessita tutte le unità di calcolo per se stesso oppure lavora sullo stesso tipo di dati di un altro thread e quindi vale la pena tenerli insieme.
Vero anche che i due thread potrebbero avere entrambi i comportamenti in fasi diverse e quindi sarebbe ancora tutto più complicato.
Ora estendiamo questi problemi elementari ad avere a disposizione 2 tipi di core diversi con risorse diverse e latenza diverse e frulliamo tutto per benino... Ne deriva che se non si cambia l'approccio allo sviluppo in atto da 30 anni non si riuscirà mai a sfruttare fino in fondo l'HW per quanto potente sia.
Il livello di complessità è così alto che servirebbe un AI assieme ad un simulatore per decidere come astrarre sequenze di codice degli algoritmi di elaborazione.
Credo che tra un po' si arriverà a questo con i compilatori.

e non è proprio quello che si può fare su android, a quanto dice qualcuno sopra? Suppongo anche su iOS da quando sono arrivate le arch big.little con A10.
Su Win l'HT è arrivato ai tempi di Xp, ben prima che esistesse sulle altre piattaforme, nel frattempo sono cambiati 5 s.o., e non hanno fatto nulla?
Con Win11 hanno dato un taglio al passato, è uscito quasi insieme alla 12 intel, hanno dichiarato di aver lavorato insieme MS e Intel sullo scheduler, e il risultato mi dici che è praticamente zero?
Non potevano copiare da android?

La maggior parte non sfrutterà mai appieno nessun HW su PC.

L'unica è rendergliela più semplice.
Non era sbagliata l'idea di un HT al contrario, idem quella di fornire accessi a più livello di memoria da parte di CPU o GPU.

Che poi non esiste nessun terzo tipo di core. Sono core nella SoC tile dedicati a lavori diversi da quelli del computing tile e non accessibili dall'utente.
Potrebbero essere core di qualsiasi tipo e architettura, persino ARM o RISC-V che fanno girare FW scritto ad hoc per coadiuvare il lavoro della VPU.

La CPU viene sempre descritta in configurazione 6+8 e 4+8 (P+E).
Di questi fantomatici LP E-core non c'è traccia.



Sinceramente non so cosa abbiano fatto con Win11, ma non è così semplice.
Serve creare un (ennesimo) framework nuovo, incluso l'aggiornamento di tutte le librerie di terze parti usate oggi, e imporne l'uso a tutte le nuove applicazioni perché tra 5 anni ci sia una quantità decente di applicazioni che sappiano sfruttare la nuova architettura big.LITTLE di Intel.
Rimane comunque tutto il pregresso, e sono più di 30 anni di programmi, che girerebbero in maniera non ottimale, nella speranza che il Thread Director li posizioni sul cluster corretto.

Windows non è Apple, nel bene e nel male, le dimensioni dei due mercati e la varietà d'uso dell'utenza sono ben diverse.