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

[CrapaDiLegno]

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.

Originariamente inviato da sbaffo

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.

[LMCH]

Originariamente inviato da sbaffo

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.

Originariamente inviato da CrapaDiLegno

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-tach...or-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/2...od-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ù.

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

[CrapaDiLegno]

Originariamente inviato da LMCH

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.

Originariamente inviato da LMCH

Parlando di questo, ci sarebbe quello a cui sta lavorando Tachyum:
https://www.eetimes.com/startup-tach...or-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/2...od-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ù.

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

[Gello]

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 ?

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

[sbaffo]

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