Link alla notizia: http://www.businessmagazine.it/news/processori-xeon-sandy-bridge-ep-nuovi-dettagli-architetturali_37936.html

Ring Bus rinnovato rispetto alle soluzioni Sandy Bridge in commercio; aarchitettura a 8 core e frequenze di clock che potrebbero raggiungere i 3 GHz. Questi gli elementi base delle future soluzioni Xeon per server dual socket

Click sul link per visualizzare la notizia.

IMHO non mettono la gpu integrata nei processori server perchè venendo spesso usati in soluzioni multiprocessore dovrebbero inventarsi e sviluppare un protocollo per disattivare tutte le gpu tranne una o usarle in combo senza violare più o meno volontariamente i brevetti per SLI e CrossFire.

IMHO non mettono la gpu integrata nei processori server perchè venendo spesso usati in soluzioni multiprocessore dovrebbero inventarsi e sviluppare un protocollo per disattivare tutte le gpu tranne una o usarle in combo senza violare più o meno volontariamente i brevetti per SLI e CrossFire.

potrebbero essere tranquillamente disattivate da bios; e 2 schede video possono coesistere tranquillamente senza lo SLI che serve praticamente solo per giocare, profesisonalmente parlando, lo SLI è utilizzabile in programmi che conti sulle dita di una mano; nel GPGPU non serve in SLI.

...ho scritto di getto...ciò che dici non fa una piega.

IMHO non mettono la gpu integrata nei processori server perchè venendo spesso usati in soluzioni multiprocessore dovrebbero inventarsi e sviluppare un protocollo per disattivare tutte le gpu tranne una o usarle in combo senza violare più o meno volontariamente i brevetti per SLI e CrossFire.più che altro, un server è un sistema tipicamente headless, non necessitante di monitor o tastiera locali dal momento che il grosso delle interazioni avverrà via rete, comprese la maggior parte delle operazioni di gestione (che si potranno svolgere attraverso sessioni SSH remote) - tranne rare casistiche (come l' installazione iniziale del sistema da parte del sysadmin), in cui però sarà sufficiente una console in modalità testo
quindi da una parte una gpu su un server (contrariamente al caso di una workstation grafica) è effettivamente inutile,
dall' altra, essendo imperativo massimizzare le prestazioni assolute (oltre che l' efficienza), qualora si riesca a superare la difficoltà tecnica di produrre chip di grosse dimensioni o integrati in numero maggiore (su package mcm) non ha senso integrare componenti che non verrebbero sfruttati e non core di cpu che consentirebbero alle applicazioni di scalare...

Purtroppo faccio parte di quella minoranza a cui, invece, la presenza della GPU sui processori di classe B, farebbe molto comodo.
E' altresì vero che preferirei e di parecchio le soluzioni AMD da questo punto di vista, sicuramente meno performanti, ma molto più valenti dal punto di vista grafico.

Sarebbe, oltretutto a mio avviso, un bel boost per lo sviluppo e l'integrazione di codice OpenCL (l'eventualità di CUDA avrebbe dei presupposti ben diversi), all'interno del parco software.

In pratica si avrebbe un coprocessore dedicato e specializzato, integrato nel package della CPU, un approccio sicuramente molto stimolante.

Almeno lo sarebbe per chi, come me, lavora su server che devono svolgere pesanti compiti di tipo multimediale h24.
Si avrebbe un risparmio molto netto in termini di spazio e costi, e col tempo un'adeguamento logico su uno standard, che aiuta sempre lo sviluppo...

Hai ragione, il fatto è che nvidia spinge su cuda da molto prima e le differenze si vedono. Cuda ha a disposizione molte librerie che permettono lo sviluppo molto più agevolmente ( thrust, opencv in parte, cuvi... ), ad esempio proprio l'altro giorno ho finito di scrivere un algoritmo basato su l lavoro di chan-vese per estrapolare da un'immagine gli active countours. Praticamente per fare una riduzione su tutti i pixel dell'immagine. Con openCL avrei dovuto scrivermi un kernel che avrebbe fatto ciò, cosa non facile visto che è un tipo di computazione notorialmente seriale, con thrust mi sono bastate 3 righe di codice:

thrust::device_vector<float> vec (n_pixel);
thrust::copy(imgData, imgData+n_pixel, vec.begin());
float m_intesity = thrust::reduce(vec.begin(), vec.end(), 0.0f, thrust::sum<float> () )/n_pixel;

Magari avendolo scritto io il codice avrei ottenuto uno speedup maggiore, ma già così sono passato, per immagini da 32MPixel da 63 secondi a 2 e rotti.

E così vedo che in ambito di ricerca Nvidia la fa da padrona, anche se è risaputo che una soluzione open sarebbe meglio per tutti.

x marcyb5st

Il fatto è che i boost prestazionali ci sono e sono indubbi, nel mondo dei sogni ci sono CPU con APU nvidia integrati nei package su schede madri multi piastra che posso utilizzare all'abbisogna per incrementare le prestazioni là dove ne ho bisogno (praticamente sempre).
Solo che la prospettiva è quanto meno remota.
Anche se intel "comprasse"nVidia oggi, prima di tre anni non ci sarebbero prodotti in commercio.
Ecco perche l'unica speranza di un approccio del genere è AMD, anche se la scrittura del codice sarebbe cmq diversa e, forse, non così agevole.
In fondo, andrebbero bene anche CPU consumer per quello che facciamo qui in azienda, il vero problema solo le implementazioni su scheda madre, che devono essere il più possibile simili a quelle Server. Il che ci restringerebbe ancora di più il campo di lavoro e di scelta, ma ripeto, ben vengano, tutto fa brodo in questo campo :-)