Newsgroup: it.comp.hardware.cpu
Titolo: Presentate da Oracle le cpu di classe T4

A differenza delle soluzioni precedenti sono caratterizzate da un 
design del tipo out of order...anche se il n. di core totali risulta 
inferiore rispetto alla generazione precedente, ogni core è comunque in 
grado di gestire 8 thread e la frequenza operativa è stata portata a 
3GHz.
 
 
http://www.businessmagazine.it/news/oracle-presenta-le-nuove-architetture-cpu-sparc-t4_38692.html
 
 
 

 
http://www.businessmagazine.it/news/oracle-presenta-le-nuove-architetture-cpu-sparc-t4_38692.html
qual'e' l'efficienza di un core che gestisce 8 thread nei nuovi T4 ?
cioe' , e' paragonabile ad una soluzione Hyperthreading Intel Xeon,
AMD Opteron (core/moduli Bulldozer) o al pari di 8 core fisici ?
non c'e' il rischio che la potenza elaborativa dei 128 thread del
"vecchio" T3 (in order) rimanga superiore in certi ambiti ?
ho sempre letto che in un server e' meglio avere piu' CPU/core
a frequenza bassa che il contrario, anche se il cambio di tipo di
esecuzione (OoO) ed il raddoppio della frequenza rimescolano
le carte ..
grazie,
luca

 qual'e' l'efficienza di un core che gestisce 8 thread nei nuovi T4 ?
 
http://www.oracle.com/us/products/servers-storage/servers/sparc-enterprise/resources/index.html
 
 
C'e' un whitepaper (PDF, 1,8MB) sui nuovi server T4, che contiene 
informazioni sulla architettura T4.
 
 


 
Appunto... ihmo hanno fatto bene a cambiare approccio.
 
 

 ha scritto nel messaggio
news:ULAgq.77952$GZ3....@tornado.fastwebnet.it...

grazie per il link ma volevo discuterne sul gruppo , anche
perche' non sono bravo ad estrapolare le prestazioni da
un white paper
 
anche i bench comparativi non sono eseguiti nelle medesime
condizioni , cambia il software, lo storage, il numero di server
e CPU, ecc.. (ad esempio JD Edward EnterpriseOne Bench)
 
ciao
luca
 
 
 
 
 
 
 

 Appunto... ihmo hanno fatto bene a cambiare approccio.
 
a me rimane il dubbio, ovviamente Oracle/Sun non e' Intel (disastro P4)
 
anche i bench che ho letto sul sito, non mi entusiasmano,
ammesso che li abbia capiti :P
 
ciao
luca
 
 
 
 
 

 ammesso che li abbia capiti :P
 
:D
 
 

 mantenendo così un flusso di elaborazione continuo.
 
avevo gia' pensato ad un Atom (in piccolo) , pero' nei T3 c'e'
un'alta parallelizzazione (128 thread) , che in un server sono
piu' importanti, anche nei bench ho notato che l'occupazione
delle CPU e' sotto il 40% (per lasciare un buon margine)
e questo mi ha fatto pensare che 128 thread "lenti" In Order
siano migliori di 64 thread "veloci" Out of Order
(in ambito DB ad altissimo livello)
 
mesi fa avevo letto anche una news di molti core Atom in un
blade server , o ricordo male ?
 
ciao
luca
 
 
 


 
Si ci sono soluzioni del genere, ma vengono usate essenzialmente per 
avere bassi consumi a parità di performance x W...non certo per avere 
elevate prestazioni assolute.
 
 

 un white paper
 
Personalmente mi piace ragionare sempre con davanti un disegno dell' 
architettura.
 

 fornirà un ulteriore miglioramento.
Senza dimenticare che questo T4 (non conosco l' architettura 
precedente), ha features nativeper il ccNuma fino a 4 processori, ognuno 
dotato della propria RAM (con la moltiplicazione della banda).
Interessante l' integrazione dell' I/O (PCIEx 2.0) e un boh sull' 
integrazione della rete.
Personalmente mi sembra un progetto (questo del T4) rispetto a quello 
del Itanium2 (che conosco solo marginalmente) un processore piu' "in 
sintonia" con il lavoro al quale sono destinati e con costi (di 
produzione) inferiori.
Sarebbe interessante poter disporre di MB economiche per il mercato OEM...

 fornirą un ulteriore miglioramento.
 
ok, allora mi son lasciato ingannare dal minor numero di thread
per CPU
 
ciao
luca
 
 
 
 
 
 
 

 frequenza, i due approcci sono confrontabili
 
 
Ma il nuovo approccio migliora l'IPC.
 

 Ma il nuovo approccio migliora l'IPC.
 
se e' maggiore del 20% ci puo' stare, pero' poi ritorno
alla mia perplessita' iniziale sulla diminuzione dei thread
totali a favore dell'aumento della frequenza
(sempre nell'ambito DB "continentali")
 
ovviamente se Oracle/Sun ha scelto questa strada ci sara'
un ottimo motivo (o piu' d'uno) , mi piacerebbe leggere dei
bench meno ostici da interpretare, per confrontare le
differenti architetture a parita' di processore
 
ciao
luca
 
 
 
 
 
 

 (sempre nell'ambito DB "continentali")
 
 
Il whitepaper parla di un aumento di 5x delle prestazioni single-
thread. Se e' vero, compensa piu' che adeguatamente il fatto di avere
meta' dei thread :)
Quindi direi che circa 2x viene dal raddoppio di frequenza, e il resto
viene dal dual-issue out-of-order, miglioramenti architetturali e
miglioramenti al sottosistema di memoria (terzo livello di cache,
prefetching, etc.)

Pleg ha detto questo venerdì :

Questo T4 penso che "spaccherà"...:)
 
 

> Questo T4 penso che "spaccher "...:)
 
Aspetta che arrivino al T-1000, poi vedi chi e' che spacca :)

 prefetching, etc.)
 
sul single thread sono daccordo anche io ma le applicazioni
che gireranno sui server allestiti con questi processori
sono altamente parallelizzati, quindi il vantaggio si riduce
tantissimo
 
pero' non vorrei essere frainteso, il mio dubbio non e' sul T4
ma sulla scelta di andare in un'altra direzione architetturale,
se avessere continuato lo sviluppo del T3 , a che punto sarebbero
arrivati ? per esempio un ipotetico "super T3" con 16 core e
256 thread a 2-2,5GHz , come si sarebbe comportato contro
l'attuale T4 ?
 
ciao
luca
 
 
 
 
 
 
 

 l'attuale T4 ?
 
 
Evidentemente peggio :)  avranno fatto un sacco di simulazioni
architetturali e avranno deciso che e' meglio cosi'.
Per dire, le prestazioni single-thread contano sempre molto per la
maggior parte dei carichi di lavoro. Non conosco di preciso che
workload abbiano, ma e' possibile che nel T3 fossero limitati dalle
prestazioni single-thread invece che multi-thread, da cui la scelta di
pompare le prime.
 
C'e' da chiarire cosa significa esattamente "8 thread per core" (o 16,
o 256). Non e' che sono tutti in esecuzione contemporaneamente, quella
e' solo la dimensione del "thread pool" da cui il core va a pescare in
ogni ciclo di clock. Non riesco a trovare online uno schema della
pipeline del Niagara (T1), se ricordo bene era una pipeline classica
semplice a 5 stadi con uno stadio in piu' (quindi 6 in tutto): lo
stadio in piu' era il "pick", cioe' ad ogni ciclo di clock veniva
scelto 1 thread sui 4 di cui eseguire una istruzione; la logica
sceglieva un thread in grado di eseguire in quel ciclo di clock (cioe'
che non avesse una richiesta di accesso alla memoria pending, ad
esempio) e garantiva la "fairness" dei thread (cioe' il non far
eseguire sempre un threada  scapito degli altri, ma dare spazio ad
ognuno). L'idea e' la stessa delle GPU, che hanno decine di migliaia
di "thread" (virgolette d'obbligo) di cui una piccola frazione in
esecuzione: usano questo meccanismo per mascherare le latenze di
accesso alla memoria e massimizzare il throughput.
 
Aumentare i thread nel pool e' il modo piu' semplice per mascherare le
latenze, ma ha un suo costo. Per ogni thread dovrai mantenere
quantomeno il set di registri, magari la TLB e altre cose cosi'.
Inoltre piu' thread hai piu' problemi hai di "cache contention": tutti
vogliono portare in cache i loro dati, a danno dei dati degli altri
thread ("cache trashing"). Questo puo' ridurre parecchio le
prestazioni. Meno thread piu' potenti risentono meno di questo
problema: meno thread che contendono per le stesse risorse, e sfrutti
meglio la localita' dei dati. Le GPU possono farcela ad alimentare
cosi' tanti "thread" perche' hanno una banda mostruosa verso la
memoria (le prossima generazioni, in arrivo nel 2012, possono superare
i 300 GB/s verso la RAM nei modelli top) e pattern di accesso molto
regolari, un normale processore non ha questi lussi.
 
 
PS: quello a cui credo tu stia pensando, un'infinita' di thread a
bassissime performance single-thread, era stato investigato nel Tera
MTA (e.g.: 
http://cseweb.ucsd.edu/~carter/Papers/tera2.html
 ).
PPS: il Niagara deriva dall'Afara chip, nato dal progetto Hydra.
Ricche informazioni (tecniche) le trovi sul sito del suo ideatore (in
fondo):  
http://ogun.stanford.edu/~kunle/
 
 

2fast ha usato la sua tastiera per scrivere :

Sarebbe andato peggio... per i motivi che ti ha giò spiegato Pleg.
La cosa importante è che in pratica è abbastanza raro che tutti i 
thread gestibili da un core del T3 possano andare a buon fine, perciò a 
quel punto hanno fatto bene a cambiare approccio architetturale, 
rendendo il design generale più simile alle moderne cpu.
 
 

 fondo):  
http://ogun.stanford.edu/~kunle/
 
 
si puo' approssimare alla tecnologia "Many Core" di Intel ?
 
grazie per le spiegazioni e per i link , ho iniziato a leggere
il sito del Tera MTA , quello di Kunle l'ho aggiunto ai preferiti,
non si sa mai che riesca ad iscrivermi ad un suo corso (LOL)
 
ciao
luca
 
 
 
 
 

 design generale più simile alle moderne cpu.
 
certo ma l'esempio che ho fatto non era aumentando i thread per
core ma i core per CPU (da 8 a 16 core)
 
che poi l'OoO porti benefici e' chiaro ma e' facile confrontare
un'architettura nuova contro una precedente e non ulteriormente
sviluppata (sempre ipoteticamente)
 
ciao
luca
 
 
 
 
 
 
 

2fast ha pensato forte :

Hanno scelto l'approccio migliore per scalare in prestazioni senza 
avere la necessità di sviluppare ulteriormente la vecchia architettura 
in order, sciaffandoci dentro un n. esagerato di core e di thread per 
core che non sarebbero mai andati totalmente a regime per i motivi già 
spiegati.
 
 

 non si sa mai che riesca ad iscrivermi ad un suo corso (LOL)
 
Le lezioni sono registrate, ma temo ti serva un account di Stanford
per vederle :D
 

 non si sa mai che riesca ad iscrivermi ad un suo corso (LOL)
 


 (aiuta a scalare il numero di core).
 
Con Bulldozer comunque anche la cache L2 diventerà del tipo condiviso 
tra i diversi moduli...sarà interessante vedere come cambierà 
l'efficienza globale.
 
 

gestire 8 thread e la frequenza operativa è stata portata a 3GHz.
 
Ok, il mio intervento non riguarda la singola potenza della singola CPU,
ma attualmente il computer *più potente (non distribuito)*
che figura in  top500 è basato su SPARC.
http://en.wikipedia.org/wiki/Top500
 
http://en.wikipedia.org/wiki/K_computer
 
 
Sbaglio o  erano anni che non accadeva di vedere
lo SPARC nelle primissime posizioni? 
 
 

 per vederle :D
 
no problem .. many (core) problems :D
 
ciao
luca
 
 
 
 
 
 
 
 
 

 lo SPARC nelle primissime posizioni?
 
che numeri, 500K core :D
 
ciao
luca
 
 
 
 
 
 
 
 

 le CPU o il numero di server per cluster
 
Non cambia niente: stai comunque migliorando il throughput e non le
performance del singolo thread.
Se erano quelle il collo di bottiglia, non guadagni nulla.
 

 Se erano quelle il collo di bottiglia, non guadagni nulla.
non abbiamo la controprova quindi non si puo' dimostrare ;)
credo che il cambio di architettura sia stato fatto in prospettiva,
in futuro ci sono margini per migliorarla aumentando anche le
prestazioni e la scalabilita' dei sistemi (aumento della frequenza,
diminuzione del processo produttivo ed aumento dei core, ecc..)
evidentemente la vecchia architettura era "alla frutta" e non
avrebbe potuto garantire questi miglioramenti
ciao
luca