Link alla notizia: http://www.hwupgrade.it/news/cpu/110-core-per-il-nuovo-processore-del-mit-rivolto-a-desktop-e-dispositivi-mobile_48445.html

Il MIT ha realizzato un nuovo microprocessore da 110 core con un occhio di riguardo all'efficienza energetica

Click sul link per visualizzare la notizia.

Mi sa tanto di annuncio per ricevere finanziamenti privati da colossi come Intel , AMD e produtti di chip , chipset mobile.

... che probabilmente già finanziano in altri modi il MIT. ;)


Il punto è che non credo siano interessati... alla fine è un "misero" 25%, cosa può fare che una GPU non può?
Inoltre credo abbiano già i loro progetti interni per questo tipo di cose, non credo siano interessati. Intel qualche anno fa aveva sviluppato un processore scalabile con più di 100 core, non si saranno mica fermati lì...

... che probabilmente già finanziano in altri modi il MIT. ;)


Il punto è che non credo siano interessati... alla fine è un "misero" 25%, cosa può fare che una GPU non può?
Inoltre credo abbiano già i loro progetti interni per questo tipo di cose, non credo siano interessati. Intel qualche anno fa aveva sviluppato un processore scalabile con più di 100 core, non si saranno mica fermati lì...

Sicuramente, dimenticavo anche il tentativo di mettersi in luce da parte di neo ingegneri et simila

Il punto è che non credo siano interessati... alla fine è un "misero" 25%, cosa può fare che una GPU non può?

Tutto quello che può fare una CPU e che una GPU non può o non è conveniente. :rolleyes:

Sicuramente, dimenticavo anche il tentativo di mettersi in luce da parte di neo ingegneri et simila

Può anche essere, ma loro sono riusciti a mettere un processore da 100 core con un pool di memoria condiviso al posto delle cache per aumentare l'efficenza in UN (1) cm2 di package a 45 nm (quindi un die verosimilmente più piccolo. Non mi sembra che AMD, Intel e ARM possano fare altrettanto. ;)
Laddove le CPU/APU/SoC più moderni dei tre produttori/licenziatori sono fatte a 32nm (gli AMD FX e Intel SB-E). Quindi se fosse portato a 32/28 nm il package potrebbe diventare ancora meno esoso di spazio e l'efficenza aumenterebbe notevolmente.
Magari a livello di IPC non è granchè, ma IMHO è già un gran bel risultato per essere solo una ricerca (quindi verosimilmente molto migliorabile).

Sì ma....

ci girerà Crysis?:D

alla fine è un "misero" 25%

Un misero 25%? Se fosse vero (ed ho i miei dubbi che sia applicabile ad altre architetture) è un risultato strepitoso sia in ottica performance che risparmio energetico. Immagina un processore che rimane in uno stato di idle più profondo di quanto oggi permesso.

La parte dell'articolo da analizzare è questa:

Per ridurre il traffico dei dati all'interno del chip, l'intera cache del microprocessore è stata sostituita da un pool di memoria condiviso. Il processore prevede il trasferimento dei dati, riducendo il numero di cicli necessari per trasferire ed elaborare gli stessi. Un'architettura di questo tipo potrebbe essere applicata nei dispositivi mobile, ma anche all'interno di server database.

Se fosse così semplice da implementare, come mai un colosso come Intel non lo ha mai applicato nei processori moderni?
Comunque questo articolo è fonte di spunti interessanti.

Sì ma....

ci girerà Crysis?:D

ROFL

Tutto quello che può fare una CPU e che una GPU non può o non è conveniente. :rolleyes:Ad esempio?

Questi sono 100 core, i processori odierni hanno 8 core? Oppure confrontavano con i 16 core? Già questo non si sa. Potrebbero aver fatto il confronto con un Pentium 4 per quanto ne sappiamo...

110 core significa che è una piattaforma di calcolo parallelo, o in questo caso gestione di dati. Cosa cambia dalla GPU? Le GPU odierne sono CPU che fanno calcoli paralleli, e sono molto più potenti che solo il 25%.

I programmi invece normalmente non sono così parallelizzabili, per questo motivo questi 100 core non sono molto utili, soprattutto in ambito telefonico, anche l'esperimento Intel non ha poi avuto riscontro...

Non sappiamo neanche quali temperature raggiunge o quanto consuma... insomma, sono belle affermazioni quando non abbiamo un solo metro di paragone... né il processore utilizzato, né il consumo, né il sofware utilizzato...

1 cm di lato a 45 nm, per avere 110 core... probabile che sia efficiente in alcuni casi, ma come se la cava in altri? Se le CPU hanno 8 core e sono più o meno di quelle dimensioni, è anche perché la circuteria è molto più complessa ed è efficiente in una serie di compiti particolari per macinare calcoli non parallelizzabili.
Come può cavarsela questa CPU se l'algoritmo non è parallelizzabile?

Le APU sono fatte per avere una GPU che gestisca le situazioni parallelizzabili automaticamente, che hanno ben più di 110 "core".


Ma alla fine lo sanno anche loro che non è niente di che, visto che hanno scritto che non è qualcosa che si può comprare a Natale.

La parte dell'articolo da analizzare è questa:

Per ridurre il traffico dei dati all'interno del chip, l'intera cache del microprocessore è stata sostituita da un pool di memoria condiviso. Il processore prevede il trasferimento dei dati, riducendo il numero di cicli necessari per trasferire ed elaborare gli stessi. Un'architettura di questo tipo potrebbe essere applicata nei dispositivi mobile, ma anche all'interno di server database.Anche una GPU alla fine è così...

....

Se fosse così semplice da implementare, come mai un colosso come Intel non lo ha mai applicato nei processori moderni?
Comunque questo articolo è fonte di spunti interessanti.

anche Intel ha fatto ben 2 anni fa una CPU così; solo che dal parlarne ad usarla realmente in un Desktop ce ne passa!

In effetti, nonostante una riduzione del traffico dati on-chip di ben 14 volte ed un altro ordine di grandezza dei core (100 contro gli attuali 10), l'IPC (parlando a spanne) aumenta di "soli" 25%.

Il problema rimane il saper sfruttare il parallelismo e l'uso im mutua esclusione della memoria...

Bello che terze parti tornino a studiare e progettare nuove piattaforme, è sempre una cosa positiva che aumenta la concorrenza e le prestazioni.
La cosa anormale sono stati gli ultimi 30 anni con il quasi monopolio di una sola piattaforma di una sola azienda.

Io la rivoluzione non la vedo nei 110 core, la vedo nel pool di memoria condivisa. Cioè usare questo tipo di architettura significherebbe eliminare la ram per sostituirla con la cache del processore, cosa mai fatta per problemi di costi (la cache costa molto più della ram). Ma con un sistema on-die, che permette agli elettroni di fare percorsi molto più brevi, e con chip di ram sufficientemente veloci come la futura DDR 4 potrebbe essere una strada percorribile. Elimini un passaggio da: HDD->ram->cache->CPU->cache->ram a HDD->ram/cache->CPU->ram/cache. Il tutto sarebbe molto più veloce ed efficiente, il problema sinora sono stati i costi dei chip usati per la cache.

Io la rivoluzione non la vedo nei 110 core, la vedo nel pool di memoria condivisa. Cioè usare questo tipo di architettura significherebbe eliminare la ram per sostituirla con la cache del processore, cosa mai fatta per problemi di costi (la cache costa molto più della ram). Ma con un sistema on-die, che permette agli elettroni di fare percorsi molto più brevi, e con chip di ram sufficientemente veloci come la futura DDR 4 potrebbe essere una strada percorribile. Elimini un passaggio da: HDD->ram->cache->CPU->cache->ram a HDD->ram/cache->CPU->ram/cache. Il tutto sarebbe molto più veloce ed efficiente, il problema sinora sono stati i costi dei chip usati per la cache.

non cambieranno mai le architetture cpu-> ram (apparte alcuni errori di concetto nel percorso che hai messo sopra). la questione Ram è fondamentale per tamponare le latenze dei HDD. ho fatto già all'epoca di win 98 esperimenti di assenza di HDD con Ramdisk...la Ram basterebbe come storage finale ma resta il fatto che anche fosse fattibile i dati hanno un peso e questo non è sostituibile completamente in Ram.
Avere 16GB di Ram non conclude il ciclo di stoccaggio dei dati...serve un HDD.
la cache non è un tramite con la ram ma è uno stack elaborativo prettamente interno (in pratica non memorizza Dati ma istruzioni elaborative e valori di elaborazione)...se viene condivisa questo vuol dire che i core possono vedere le istruzioni da eseguire e possono elaborare un processo in maniera indipendente ognuna. questo velocizza il lavoro ma ciò non toglie che al termine dell'elaborazione cpu<->cache sia necessario rimemorizzare dati che vengono spediti in RAM (->HDD se si tratta di dati fissi come una foto o un testo)

Visto che il 90% del software è ancora mono-thread è inutile avere 2 core o 8 o 100... tanto nulla potrebbe sfruttarli!

La vera rivoluzione sarebbe se la CPU fosse in grado di "trasformare" codice mono-thread in multi-thread in realtime... ovvero trovare parallelismi che il programmatore non ha saputo trovare!

Allora sì che avrebbe senso avere 2-4-8... o 100 core, così com'è oggi è solo tecnologia non sfruttata, purtroppo :cry:

Visto che il 90% del software è ancora mono-thread è inutile avere 2 core o 8 o 100... tanto nulla potrebbe sfruttarli!

La vera rivoluzione sarebbe se la CPU fosse in grado di "trasformare" codice mono-thread in multi-thread in realtime... ovvero trovare parallelismi che il programmatore non ha saputo trovare!

Allora sì che avrebbe senso avere 2-4-8... o 100 core, così com'è oggi è solo tecnologia non sfruttata, purtroppo :cry:

questi come i core Intel sono ancora in modalità Develop quindi tutto è possibile; in particolare Intel studiava un OS (kernel linux) che facesse lui stesso la scomposizione multicore del SW garantendo sempre la massima efficienza sia di potenza che di energia spesa.

Ricerca molto interessante, a mio avviso per almeno i seguenti punti:

1) General porpouse processing, per meglio dire, fa qualcosa di generico, cosa che le GPU non riescono (ho seguito qualche lezione sulla tecnologia CUDA, un incubo da programmare hehe). E qui possiamo arrivare a gestione di interrupt (magari un core può gestire lo scheduler, un altro le usb ecc...).

2) "Come può cavarsela questa CPU se l'algoritmo non è parallelizzabile?" beh nel peggiore dei casi, il sistema operativo (che deve essere adattato, secondo me uno scheduler round robin non è adatto al caso) gestisce per lo meno l'assegnazione dei vari processi ai core. Contando che ogni OS ha almeno un centinaio di processi attivi, anche in idle, lo vedo come un ottima opportunità. Non parliamo poi dei server e dei vari processi di apache / inetd.

3) L'approccio cache / ram di cui si parla nell'articolo. Che tra l'altro è simile all'approccio utilizzato nelle GPU.

Riassumendo, rimane sempre un esperimento. Ma anche i transistor all'epoca erano degli esperimenti :)
Credo inoltre che non siano risorse sprecate quelle nello studio dei consumi energetici, assolutamente, al giorno d'oggi abbiamo potenza PIU' che a sufficienza per i bisogni della maggior parte delle persone, e quindi anche se queste CPU non garantiscono magie rispetto ad oggi, è pur sempre importante che i consumi diminuiscano vertiginosamente.

...mi sono dilungato un po' :D

non cambieranno mai le architetture cpu-> ram (apparte alcuni errori di concetto nel percorso che hai messo sopra). la questione Ram è fondamentale per tamponare le latenze dei HDD. ho fatto già all'epoca di win 98 esperimenti di assenza di HDD con Ramdisk...la Ram basterebbe come storage finale ma resta il fatto che anche fosse fattibile i dati hanno un peso e questo non è sostituibile completamente in Ram.
Avere 16GB di Ram non conclude il ciclo di stoccaggio dei dati...serve un HDD.
la cache non è un tramite con la ram ma è uno stack elaborativo prettamente interno (in pratica non memorizza Dati ma istruzioni elaborative e valori di elaborazione)...se viene condivisa questo vuol dire che i core possono vedere le istruzioni da eseguire e possono elaborare un processo in maniera indipendente ognuna. questo velocizza il lavoro ma ciò non toglie che al termine dell'elaborazione cpu<->cache sia necessario rimemorizzare dati che vengono spediti in RAM (->HDD se si tratta di dati fissi come una foto o un testo)

L'HDD non l'ho escluso dall'equazione, ovviamente uno spazio di memoria non volatile è fondamentale. Però pensa ad avere una memoria che possa contenere sia istruzioni che dati, in modo da sostituire ram e cache, sarebbe molto più veloce ed efficiente ;)

Sono perplesso...a livello desktop o mobile...che me ne faccio di 100 core? Già uno smartphone ne usa 2 si e no...su pc 4 o 8 che siano fisici o virtuali non li sfrutti fino in fondo...

L'HDD non l'ho escluso dall'equazione, ovviamente uno spazio di memoria non volatile è fondamentale. Però pensa ad avere una memoria che possa contenere sia istruzioni che dati, in modo da sostituire ram e cache, sarebbe molto più veloce ed efficiente ;)

non ha alcun senso fondere le due cose perchè le due cose sono estremamente diverse e le esigenze HW seguono queste esigenze...è come pretendere di fondere una videocamera con una tastiera e che il risultato faccia esattamente alla perfezione entrambe le cose...
tecnicamente con la cache presente oggi una CPU fa girare dentro se stessa un intero sistema DOS o Win3.0...ma sono passati 30 anni e questo vorrebbe dire che ci vogliono almeno 15/20 anni per avere valori di cache sul GB (sempre che abbia senso dato che si tende ad ottimizzare il codice e quindi a ridurre le esigenze in termini di spazio istruzione/risultato)...contando poi che la stessa ram aumenta di velocità ogni anno non è quello il collo di bottiglia (che per anni è stato l' HDD ora con l'SSD è diverso)

With compliments, non sarai stato breve, ma di argomenti importanti ne hai toccati parecchi.

Per completare se vuoi c'è quanto originalmente affermato da fano
"La vera rivoluzione sarebbe se la CPU fosse in grado di "trasformare" codice mono-thread in multi-thread in realtime... ovvero trovare parallelismi che il programmatore non ha saputo trovare!"

Non è una strada percorribile nell'esecuzione del codice, bensì nella sua ottimizzazione in sede di programmazione con tool di sviluppo adatti alla bisogna.
Anche qui nulla di nuovo, ma d'importante e spesso trascurato da chi linee di guida e tool di sviluppo dovrebbe fornire.

nella vita quotidiana e con un uso anche intensivo non ha sempre senso creare codice multicore anche perchè i threads sono molti e spesso usano risorse saltuarie e poco intense dal lato potenza...quindi il concentrarsi su tutto il SW non ha senso, solo alcuni SW come foto e video montaggio o elaborazioni particolari meritano l'attenzione al multicore.

la menzione interessante potrebbe essere sul fatto che windows in tutte le versione NT gestirebbe facilmente l'assegnazione ad uno specifico core dei processi ma che al momento nessuno sfrutta se non a mano ed in casi particolari; io ad esempio quando devo garantire sia una elaborazione audio che una registrazione live video assegno 2 core alla gestione video, 1 core a quella audio e il restante core al sistema; così sono sicuro nessun processo si interrompa o rallenti.
sfruttare il SO in questi termini migliora senza dubbio l'uso del multicore altrimenti spesso inutile o impercettibile come miglioramento (differenze tra CUP 2 o 4 core spesso sono invisibili)

@M47AMP esattamente quello che intendo! Programmare con threads è tutt'altro che semplice, se si voglio fare le cose per bene. Tralasciando i vari problemi di sincronizzazione e memoria condivisa, è facile poi ritrovarsi pieni di semafori che messi assieme è come se tutto fosse in un thread singolo ^^ Spesso e volentieri i threads vengono usati anche per comodità e miglior tecnica di sviluppo (per es. manutenzione, semplicità)

Ad ogni modo senza dilungarsi troppo in dettagli tecnici, come dice anche @djfix13, è assolutamente positivo avere più core in modo da far girarci su più processi *in contemporanea* anziché avere thread che continuano a interrompersi e a riprendersi.
Ed è anche vero (mondo mobile...) che 2-4 core messi cosi allo sbaraglio servono a tutto e nulla. Faccio anche il "classico" (mio) esempio del Pentium 4 con Kubuntu 13.04 che mi brucia in avvio rispetto a un dual core stessa configurazione (per l'appunto ordine di avvio parallelizzato poco, molto sequenziale, soprattutto nel kernel, immagino).

Concludo che hardware e software sono molto vicini, spesso non lo si considera...in altri termini l'efficienza è determinata a conti fatti dal software, oltre che dalla potenza "bruta" ;)