Link alla notizia: https://www.hwupgrade.it/news/cpu/cpu-meteor-lake-intel-pronta-a-introdurre-un-terzo-tipo-di-core-spunta-lp-e-core_108417.html

Un diagramma diffuso dal sito tedesco Igor's Lab sulle future CPU Core di 14a generazione mobile "Meteor Lake" ci svela l'esistenza di un terzo tipo di core chiamato LP E-core, ossia Low Power Efficient Core. Affiancherà P-core ed E-core rinnovati, oltre a una GPU integrata basata su architettura Xe2-HPG.

Click sul link per visualizzare la notizia.

la rincorsa infinita... ci vorrà un po' di tempo...

Quanto a P-core ed E-core, i primi dovrebbero essere basati su architettura Redwood Cove, mentre i secondi su un progetto chiamato Crestmont e andranno a prendere il posto dei design Raptor Cove e Gracemont che costituiranno le CPU Raptor Lake in arrivo nella prima parte del 2023.

Come se fosse la CPU antani con iperscappellamento destrogiro e gpu tapioca con core ipermaturati.

Siamo a questo livello. Se uno non segue TUTTO non ci capisce una fava.

:mc: :mc: :mc:
E certo tanto si sà che su PC l'ottimizzazione del software è proprio all'ordine dle giorno ......

Ma non dovevamo rendere più semplice la programmazione anzichè più complicata ?

Mitico Frankie!!

Dovevano adottare i 4nm o 7nm molto tempo prima invece di spararsi le seghe con le ottimizzazioni simil-ARM che possono andar bene per i notebook per ottimizzare la batteria. Agli utenti di processori per desktop non interessa avere + o - 7,84647589% di prestazioni in più ma il 100% nell'arco di 3 o 4 anni... e non di 10anni...

Mitico Frankie!!

Dovevano adottare i 4nm o 7nm molto tempo prima invece di spararsi le seghe con le ottimizzazioni simil-ARM che possono andar bene per i notebook per ottimizzare la batteria. Agli utenti di processori per desktop non interessa avere + o - 7,84647589% di prestazioni in più ma il 100% nell'arco di 3 o 4 anni... e non di 10anni...

Perchè non del 300% ogni 6 mesi o del 1000% ogni trimestre?

Ma come fa bene la concorrenza. Per via del pepe messo da AMD, noto che Intel sta procedendo bene e con velocità; da menzionare l'encoder av1 nella nuova integrata (ma che, se non erro, sarà disponibile anche nella gen.13), il continuo supporto in svt-a1 e soprattutto in linux (che negli ultimi tempi sta galoppando).

:mc: :mc: :mc:
E certo tanto si sà che su PC l'ottimizzazione del software è proprio all'ordine dle giorno ......

Ma non dovevamo rendere più semplice la programmazione anzichè più complicata ?

La programmazione non c'entra una fava, e' il thread director sulla CPU e lo scheduler dell' os a dover "indirizzare" il carico.

:mc: :mc: :mc:
E certo tanto si sà che su PC l'ottimizzazione del software è proprio all'ordine dle giorno ......

Ma non dovevamo rendere più semplice la programmazione anzichè più complicata ?

Il problema dell'ottimizzazione software è un problema che avremo a vita, ti spiego perché:

Se tu avessi 1 sola architettura a Intel basata su x86 a 64bit, faresti solo ad esempio (per dirne una semplice) variabili Int64 e dentro ci puoi mettere il numero: 9.223.372.036.854.775.807 (sia positivo che negativo)
Ma siccome hai anche PC con CPU anche a 32 (se va bene), hai bisogno di una Int32, ma purtroppo arriva a 2.147.483.648 (sia positivo che negativo)
Quindi, l'ottimizzazione in questo caso và a donnine perché devi fare accrocchi per arrivarci, aggiungendo istruzioni.

Così vale per tante altre cose, come ad esempio gli OS o le versioni di framework utilizzati per lo sviluppo, ad esempio se uso C# avrò .NET come framework, ma non posso sviluppare con la 6.5 perché XP o Windows 7 sarebbe tagliato fuori. Quindi per esempio non posso usare HTTP/3 per una WebApp, perché è stato aggiunto solamente a .NET 6 e sono costretto ad usare http2 e magari devo simulare un determinato comportamento dell'http3 su l'http2, ad esempio HTTP3 non utilizza più TCP come protocollo, ma usa UDP, quindi sono costretto a scrivermi o utilizzare librerie terze per usare HTTP3 su .NET 4 che è compatibile con i 32bit ed inoltre XP e 7 con la probabile problematica che su Windows 10 gira di merda, mentre su XP benino, ma è mal otimizzato, perché per mantenere la retrocompatibilità devo rinunciare a risorse e tempo, quindi alle performance.

I due core "LP E" sul SOC tile oltre ad essere implementati per consumare meno (probabilmente con clock più basso ecc.) permettono di lasciare il "compute tile" completamente spento quando il sistema ha poco carico computazionale.
Ma se non ci sono altre innovazioni per desktop/notebook è solo una cosa utile per ridurre i consumi quando il carico computazionale è basso.
D'altro canto potenzialmente potrebbero esserci versioni "industriali"/"embedded" denominate Celeron o Pentium dual core con giusto il SOC tile.

La programmazione non c'entra una fava, e' il thread director sulla CPU e lo scheduler dell' os a dover "indirizzare" il carico.
Ma anche no, Win11 in teoria dovrebbe sfruttare già gli E-cores
E invece ci sono moltissimi applicativi che non li sfruttano
altri invece li sfruttano senza fare distinzione.

Quindi di cosa stiamo parlando ?

Ma anche no, Win11 in teoria dovrebbe sfruttare già gli E-cores
E invece ci sono moltissimi applicativi che non li sfruttano
altri invece li sfruttano senza fare distinzione.

Quindi di cosa stiamo parlando ?

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.

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.

Il problema dell'ottimizzazione software è un problema che avremo a vita, ti spiego perché:

Se tu avessi 1 sola architettura a Intel basata su x86 a 64bit, faresti solo ad esempio (per dirne una semplice) variabili Int64 e dentro ci puoi mettere il numero: 9.223.372.036.854.775.807 (sia positivo che negativo)
Ma siccome hai anche PC con CPU anche a 32 (se va bene), hai bisogno di una Int32, ma purtroppo arriva a 2.147.483.648 (sia positivo che negativo)
Quindi, l'ottimizzazione in questo caso và a donnine perché devi fare accrocchi per arrivarci, aggiungendo istruzioni.

Così vale per tante altre cose, come ad esempio gli OS o le versioni di framework utilizzati per lo sviluppo, ad esempio se uso C# avrò .NET come framework, ma non posso sviluppare con la 6.5 perché XP o Windows 7 sarebbe tagliato fuori. Quindi per esempio non posso usare HTTP/3 per una WebApp, perché è stato aggiunto solamente a .NET 6 e sono costretto ad usare http2 e magari devo simulare un determinato comportamento dell'http3 su l'http2, ad esempio HTTP3 non utilizza più TCP come protocollo, ma usa UDP, quindi sono costretto a scrivermi o utilizzare librerie terze per usare HTTP3 su .NET 4 che è compatibile con i 32bit ed inoltre XP e 7 con la probabile problematica che su Windows 10 gira di merda, mentre su XP benino, ma è mal otimizzato, perché per mantenere la retrocompatibilità devo rinunciare a risorse e tempo, quindi alle performance.
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.

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 :)

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.

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.

Ma se non ci sono altre innovazioni per desktop/notebook è solo una cosa utile per ridurre i consumi quando il carico computazionale è basso.

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.


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?

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

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

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.

Se si potesse dire all'OS lo scopo (o il tipo) di thread creato sarebbe più facile .....
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?

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.
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.

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?

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.

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.


In pratica l'approccio P+E (e prossimamente P+E+"LP E") gli serve solo per tirare avanti in attesa di nuovi PP e magari una nuova microarchitettura.

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.

Parlando di questo, ci sarebbe quello a cui sta lavorando Tachyum:
https://www.eetimes.com/startup-tachyum-offers-universal-processor-for-evaluation/

Le informazioni sul processore di Tachyum sono date con il contagocce a chi non firma NDA, ma Chips&Cheese ha un articolo critico sull'architettura (facendo il confronto tra la prima iterazione e quella ormai definitiva che verrà messa in produzione nel 2023) in cui sono raccolti molti dettagli:
https://chipsandcheese.com/2022/06/28/tachyum-too-good-to-be-true/

In pratica i progetttisti di Tachyum Prodigy sono partiti dalla considerazione che in passato era il tempo di switching dei gate ad essere dominante nei ritardi di propagazione dei segnali sul chip, mentre ora a dominare è il ritardo dovuto alla resistenza intrinseca dei collegamenti (a causa della riduzione della loro sezione) e quindi ... hanno riprogettato tutto tenendo conto di questo, riutilizzando soluzioni architetturali abbandonate, ma che con i nuovi vincoli di progettazione gli sembrano più efficienti ecc. ecc.

La cpu risultante è pensata per essere usata in supercomputer ed per server farm, non certo per desktop o laptop, ma è decisamente interessante vedere su cosa puntano.

In poche parole, sembra che Prodigy sia un mix di soluzioni architetturali in parte implementate sugli Itanium, in parte tipiche di GPU, con esecuzione in-order con poison bits e parallelizzazione ad opera del compilatore.

Potrebbe essere un floppone disastroso oppure potrebbe prendere il controllo del mercato di fascia alta e non mollarlo più. :mbe:

Il motivo per cui penso questo è che (per quel che se ne sa ora) sembra che abbiano puntato ad avere core "relativamente semplici ed omogenei" (nonostante ogni core abbia due ALU vettoriali capaci di eseguire due FMA a 1024bit per ciclo :eek: ) delegando al compilatore un sacco di roba che fatta in hardware richiede l'aggiunta di gate e sopratutto di interconnessioni che influiscono negativamente sui ritardi di propagazione.
E' tutta una questione di equilibrio tra hardware e software, ma moolto difficile da ottenere se si guarda a tentativi simili fatti in passato.

In pratica l'approccio P+E (e prossimamente P+E+"LP E") gli serve solo per tirare avanti in attesa di nuovi PP e magari una nuova microarchitettura.
Come scritto sopra non c'è alcuna LP-E aggiunta a disposizione del programmatore. Sono core stand-alone nella SoC tile, governati da FW proprio per lavori extra general purpose.



Parlando di questo, ci sarebbe quello a cui sta lavorando Tachyum:
https://www.eetimes.com/startup-tachyum-offers-universal-processor-for-evaluation/

Le informazioni sul processore di Tachyum sono date con il contagocce a chi non firma NDA, ma Chips&Cheese ha un articolo critico sull'architettura (facendo il confronto tra la prima iterazione e quella ormai definitiva che verrà messa in produzione nel 2023) in cui sono raccolti molti dettagli:
https://chipsandcheese.com/2022/06/28/tachyum-too-good-to-be-true/

In pratica i progetttisti di Tachyum Prodigy sono partiti dalla considerazione che in passato era il tempo di switching dei gate ad essere dominante nei ritardi di propagazione dei segnali sul chip, mentre ora a dominare è il ritardo dovuto alla resistenza intrinseca dei collegamenti (a causa della riduzione della loro sezione) e quindi ... hanno riprogettato tutto tenendo conto di questo, riutilizzando soluzioni architetturali abbandonate, ma che con i nuovi vincoli di progettazione gli sembrano più efficienti ecc. ecc.

La cpu risultante è pensata per essere usata in supercomputer ed per server farm, non certo per desktop o laptop, ma è decisamente interessante vedere su cosa puntano.

In poche parole, sembra che Prodigy sia un mix di soluzioni architetturali in parte implementate sugli Itanium, in parte tipiche di GPU, con esecuzione in-order con poison bits e parallelizzazione ad opera del compilatore.

Potrebbe essere un floppone disastroso oppure potrebbe prendere il controllo del mercato di fascia alta e non mollarlo più. :mbe:

Il motivo per cui penso questo è che (per quel che se ne sa ora) sembra che abbiano puntato ad avere core "relativamente semplici ed omogenei" (nonostante ogni core abbia due ALU vettoriali capaci di eseguire due FMA a 1024bit per ciclo :eek: ) delegando al compilatore un sacco di roba che fatta in hardware richiede l'aggiunta di gate e sopratutto di interconnessioni che influiscono negativamente sui ritardi di propagazione.
E' tutta una questione di equilibrio tra hardware e software, ma moolto difficile da ottenere se si guarda a tentativi simili fatti in passato.
Non credo che quanto tu abbia scritto aiuti a superare il problema dell'ottimizzazione del codice general purpose.
Vero è che suo server HPC il codice è compilato ogni volta ad-hoc per ciascuna architettura su cui si fa girare, ma lasciare al compilatore l'intero peso dell'ottimizzazione storicamente non è mai stata una buona idea, perché anche a run time le condizioni delle risorse variano e un'ottimizzazione completa la puoi fare solo tramite HW apposito che al volo distribuisca carichi, istruzioni e dati come è meglio in quel momento. Ne è un esempio semplice ma efficace l'ordinamento delle istruzioni OoO che il compilatore può prevedere staticamente durante la compilata, ma che se non eseguito anche in HW non porta agli stessi benefici perché solo a run time sai esattamente il numero di stalli in corso e di occupazione delle unità di calcolo.

Rimane inoltre il problema che un codice compilato e ottimizzato dal solo compilatore diventa ingestibile nelle versioni successive dell'architettura HW. O non cambi le parti strategiche dell'architettura per evitare che il codice vecchio sia penalizzato, oppure devi over-complicare il tutto per tenere conto delle vecchie e delle nuove ottimizzazioni possibili.
Sarebbe un auto goal incredibile, e infatti nessuna architettura moderna ha mai fatto conto di lasciare l'ottimizzazione del codice in mano ad un compilatore. Le uniche architetture che mi vengono in mente sono le GPU, ma il codice che gira su di loro è compilato dal driver ogni volta e quindi il driver (aggiornato) è in grado di adattarsi al volo ai cambiamenti dell'HW sottostante. Per il codice compilato una volta sola e poi distribuito la cosa ha gravi ripercussioni, invece,

Ma anche no, Win11 in teoria dovrebbe sfruttare già gli E-cores
E invece ci sono moltissimi applicativi che non li sfruttano
altri invece li sfruttano senza fare distinzione.

Quindi di cosa stiamo parlando ?

Di qualcosa che non sai/capisci come per le altre cose che commenti, quindi meglio terminare qua :)

tra l'altro di Tachium qui su hwup non si è vista neanche mezza news, mentre sui figli di elon e altre baggianate da novella 2000 non mancano mai le news... :muro: