Processori Xeon Sandy Bridge-EP: nuovi dettagli architetturali

Processori Xeon Sandy Bridge-EP: nuovi dettagli architetturali

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

di Paolo Corsini pubblicata il , alle 13:58 nel canale Mercato
 

Entro la fine dell'anno Intel immetterà in commercio la prossima generazione di processori Xeon per sistemi a due socket, quelli che per volumi rappresentano la quota principale nel mercato delle soluzioni server basate su architettura x86. Queste soluzioni, indicate con il nome in codice di Sandy Bridge-EP, saranno basate sulla microarchitettura base adottata dalle proposte Sandy Bridge per sistemi desktop attualmente in commercio, con alcune funzionalità specifiche implementate pensandone alla destinazione d'uso.

La tecnologia produttiva resterà quella a 32 nanometri delle proposte Sandy Bridge desktop, con un numero massimo di core che sarà pari a 8 in alcune versioni mantenendo l'approccio con last level cache, o cache L3, unificata e memory controller DDR3, affiancati da controller PCI Express 3.0 e nuova generazione di interconnessione Quick Path.

Stando alle informazioni anticipate dal sito Real World Technologies a questo indirizzo, queste soluzioni verranno implementate con due differenti tipologie di socket in funzione della potenza di elaborazione del processore e quindi del tipo di server abbinato: quello LGA 2011, indicato anche come socket R, per le proposte di fascia più alta e quello LGA 1356 o socket B2 per le soluzioni maggiormente mainstream.

In termini di frequenza di clock mancano indicazioni precise ma ci possiamo attendere valori attorno a 2,66 GHz per le versioni con TDP entro i 130 Watt di massimo; in presenza di soluzioni con TDP di 150 Watt ci si potrà indicativamente spingere sino ad una frequenza di clock di 3 GHz.

Nell'architettura di base ritroviamo ovviamente il ring bus, attraverso il quale i vari componenti interni del processore sono collegati tra di loro e a loro volta alla cache di last level o L3; quest'ultima potrebbe essere proposta in quantitativo sino a 20 Mbytes quale massimo, variabile a seconda delle versioni di processore e del numero di core integrati. Onde ottimizzare i trasferimenti interni tra i vari componenti della CPU il  nuovo ring bus sarà di tipo bidirezionale, a differenza dell'approccio unidirezionale adottato da Intel sulle attuali versioni di processore Sandy Bridge in commercio.

Nonostante siano basate su questa architettura, le soluzioni Sandy Bridge-EP non implementeranno la componente GPU al proprio interno in quanto giudicata non importante in ambito server. A questa considerazione concorre ovviamente la natura della GPU integrata da Intel nelle soluzioni Sandy Bridge, non in grado di poter venir efficacemente utilizzata quale alternativa di una tradizionale CPU in ambito server per elaborazioni di GPU computing.

7 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
XMieleX29 Luglio 2011, 14:34 #1

secondo me...

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.
AceGranger29 Luglio 2011, 14:56 #2
Originariamente inviato da: XMieleX
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.
XMieleX29 Luglio 2011, 15:01 #3

in effetti...

...ho scritto di getto...ciò che dici non fa una piega.
jappilas29 Luglio 2011, 15:47 #4
Originariamente inviato da: XMieleX
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...
~efrem~29 Luglio 2011, 17:25 #5

Minoranza...

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...
marcyb5st31 Luglio 2011, 17:24 #6
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.
~efrem~04 Agosto 2011, 13:19 #7
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 :-)

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^