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

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/cpu/cp...re_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.

[hackaro75]

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

[frankie]

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.

[nickname88]

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 ?

[Pkarer]

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

[the_joe]

Originariamente inviato da Pkarer

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?

[Nui_Mg]

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

[Gello]

Originariamente inviato da nickname88

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.

[SpyroTSK]

Originariamente inviato da nickname88

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.

[LMCH]

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.

[nickname88]

Originariamente inviato da Gello

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 ?

[SpyroTSK]

Originariamente inviato da nickname88

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.

[nickname88]

Originariamente inviato da SpyroTSK

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.

[CrapaDiLegno]

Originariamente inviato da SpyroTSK

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.

[SpyroTSK]

Originariamente inviato da CrapaDiLegno

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

[SpyroTSK]

Originariamente inviato da nickname88

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.

[sbaffo]

Originariamente inviato da LMCH

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.

Originariamente inviato da CrapaDiLegno

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?

[CrapaDiLegno]

Originariamente inviato da sbaffo

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.

[sbaffo]

Originariamente inviato da CrapaDiLegno

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?

[nickname88]

Originariamente inviato da SpyroTSK

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.