Newsgroup: it.comp.hardware.cpu
Titolo: UltraSparc T1: 8 processori?

Salve a tutti, mi date delle delucidazioni
sul nuovo UltraSparc T1, ho letto che si
compone di 8? processori.
Ma come fanno a far stare 8 cpu su un unico die?
Grazie
Ciao

Max ha scritto:

il fatto di aver un'architettura migliore (scusami per la mia antipatia 
nei confronti degli x86) :)
penso che ci sia abbontante posto per un paio di core nella parte del 
die dedicata alla mostruosa cache L3 che accompagna gli itanium...
magari ho sparato una grandissima stronxata

"Max" <m...@max.max> ha scritto nel messaggio
news:437b8f19$0$13253$4faf...@reader2.news.tin.it...

http://www.sun.com/processors/UltraSPARC-T1/specs.xml
http://arstechnica.com/news.ars/post/20051114-5569.html
I singoli core sono semplici Risc a basso IPC, con un basso numero di
transistor. Assomiglia almeno un pò, concettualmente, al Cell di IBM, anche
se i core sono tutti uguali, senza core "madre", e general purpose. La
frequenza è fissata a 1-1,2 Ghz. Il TDP è a 72W, valore accettabile.
Dovrebbe eccellere nelle applicazioni multithread tipiche dei server, ma
sono da verificare, però, le prestazioni sul campo.

... vi ringrazio.
Ciao


oddio, "architettura migliore" e "spark" non e' che vadano proprio
bene sula stessa riga - stessimo parlando di alpha o power...
-- 
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Coloro che sono disposti a farsi togliere alcune liberta' 
essenziali per ottenere un piccolo, temporaneo senso di sicurezza
non meritano ne liberta' ne sicurezza. [B. Franklin]


Perche sul T1 un core Sparc puo essere molto meno complesso di
un core x86 "recente".
Visto che affermano che ogni singolo core puo gestire QUATTRO thread
simultaneamente (in modo simile all'HyperThreading) e' molto probabile
che le prestazioni su singolo thread siano relativamente basse
anche rispetto alle cpu UltraSparc precedenti (tanto le "bolle"
prodotte nelle pipeline da un thread vengono utilizzate per
infilarci operazioni degli altri thread).
Questo significa che gli bastano dei decoder istruzioni "semplici"
che mandano in esecuzione 1 istruzione per thread per avere
comunque minimo 4 istruzioni inviate in esecuzione simultanea su ogni core.
I decoder x86 attuali riescono ad arrivare a 3..4 istruzioni inviate
in esecuzione *per thread*, ma quello e' solo il valore di picco
e viene ottenuto con un decoder *molto* piu complesso.
Oltre a questo tutte le sub-pipeline nel core possono essere
molto piu semplici, perche imponendo che tra due operazioni
consecutive appartenenti ad un thread vengano inserite almeno
N (3 in questo caso) operazioni appartenenti ad altri thread
si puo eliminare molta della circuiteria di controllo che serve
per inserire bolle/stalli nelle pipeline per permettere la corretta
gestione di operazioni consecutive che hanno dipendenze tra i dati.
Si noti inoltre che si tratta di una cpu per server dove
ci si aspetta una gestione differente dei thread e dei task
in esecuzione.
Anche su un pc "desktop" attuale con XP o Linux ci sono
molti processi e thread in esecuzione, ma all'utente "desktop"
di solito interessano le prestazioni di un singolo processo e/o
di pochi thread, quindi li un T1 sembrerebbe "lento" ad una
istruzione per thread mentre invece su un server con molti
processi e thread  "tutti importanti" (per i vari utenti
collegati o che hanno avviato dei lavori da eseguire), la
differenza e' notevole (un T1 ad 8 core  puo arrivare ad
avere 32 thread in esecuzione simultanea).
Infatti Sun punta molto sulle "prestazioni sotto carico"
piu che a quelle "con una singola applicazione di calcolo
su pochi thread".
L. Micheletto

 bene sula stessa riga - stessimo parlando di alpha o power...
dipende sempre da cosa devi fare...
poi comunque gli spark rimangono ottimi processori, magari non veloci 
nel singolo tread, ma ottimi per le applicazioni multitreading e per i 
per server blade dato il ridotto consumo in relazione al numero di core.
Inoltre sono sicuro che solaris e java siano ottimizzati molto per 
questa architettura.
ciao hp