Newsgroup: it.comp.hardware.cpu
Titolo: 4x4, nuova Panda o anti-Conroe?

http://www.hwupgrade.it/news/cpu/4x4-la-nuova-piattaforma-anti-conroe-di-amd_17572.html
Sinceramente non credo sia un vero diretto concorrente: questo è un sistema 
da élite pura, più di quella che si può permettere un processore FX o EE. Si 
parla di 2400 euro solo per i processori, più un alimentatore (o forse due?) 
da elevata potenza, e di schede video per un sistema quad SLI. E RAM a 
sfarne. E' più qualcosa per riprendersi lo scettro delle prestazioni 
assolute più elevate, sempre che le applicazioni siano abbastanza 
parallelizzate.
Tuttavia, in relazione con quest'altra news:
http://www.hwupgrade.it/news/cpu/un-hyperthreading-al-contrario-per-amd_17088.html
tutto questo panorama assume dei connotati decisamente più interessanti...
Ah, naturalmente, è già interessante il fatto che due processori "desktop" 
(su socket AM2) possano operare in dual senza scomodare schede madri per 
Opteron e memorie registered.
MaxArt 

 tutto questo panorama assume dei connotati decisamente più interessanti...
Sicuramente il fatto di poter utilizzare l'altro core quando questo si 
rigira i pollici per fargli fare i conti del primo sarebbe davvero 
rivoluzionario, e aprirebbe orizzonti decisamente più interessanti.


L' esecuzione multiscalare (di cui "l'hyperthreading al contrario"
e' una delle possibili varianti) richiede modifiche ai core
e possibilmente un link diretto tra i core
o magari le unita di esecuzione in comune tra i due core.
Il 4x4 e' una versione "economica" dual socket
simile ai sistemi dual socket per Opteron 2xx
(ma senza la ram piu costosa ma piu affidabile, ecc. ecc.)
Potrebbe essere solo una contromisura temporanea
oppure potrebbe anche essere un nuovo segmento di mercato
in pianta stabile (un dual socket ben differenziato
dalla linea Opteron).
Piuttosto, il 4 giugno scade il veto sulla pubblicazione di benchmark
sui Conroe a 2.6Ghz ma ci sono gia stati degli "spifferi" riguardo
il Core 2 Extreme Edition a 2.93 Ghz
http://www.extremetech.com/article2/0,1697,1970201,00.asp
La cosa piu interessante/preoccupante e' che per overclockare
il Core 2 EE a 3.2Ghz hanno dovuto usare il raffreddamento a liquido.
Questo unito al fatto che i benchmark del 4 giugno sono *tutti*
relativi a 15 sistemi testati a Monaco il 22/23 maggio
(15 pc messi a disposizione per due giorni da Intel
  su cui gli "esterni" hanno potuto far girare
  il software preinstallato da Intel) fa pensare che
Intel abbia qualche problema di cui non vuole parlare
(o forse sono i tipi del marketing che stanno applicando
  qualche nuova strategia per tenere alta l'attenzione
  sul prodotto).
Mi riferisco a:
http://www.theinquirer.net/?article=32026
http://www.theinquirer.net/?article=32000
Probabilmente si tratta dei classici problemi di basse rese
iniziali che verranno risolti in step successivi, ma e' strano
che si comportino in quel modo.
A partire dall' autunno 2006 probabilmente si sapra' che cosa
sta effettivamente succedendo.
L. Micheletto

 sta effettivamente succedendo.
Infatti è quello che dico io da tempo, e cioè che bisogna attendere che 
i processori siano resi disponibili al mercato, almeno per avere dei 
test validi e non faziosi. In ogni caso, Intel ha puntato molto 
sull'hype generato da questa "anteprima", e mi accorgo in giro che molti 
lamer ci cascano ancora. Ora può anche darsi che Conroe sarà davvero un 
ottimo processore, ma lasciarsi prendere in giro con le promesse... :)

 (ma senza la ram piu costosa ma piu affidabile, ecc. ecc.)
Quindi escludi che l'esecuzione multiscalare sarà implementata in quel 
sistema 4x4?
MaxArt 


Per avere un implementazione multiscalare decente servirebbe
un core riprogettato a livello di decoder istruzioni
e di collegamento tra i due core, il K8 non ha questo
e per quel che se ne sa ora, neppure il K8L integra
roba simile.
Essenzialmente un sistema multiscalare lo si puo pensare
come una forma estrema di cpu che esegue istruzioni out-of-order.
Invece di eseguire out-of-order "piccole sequenze"
ne identifica spezzoni piu grandi e li esegue su core distinti
con capacita di rollback molto piu sofisticate rispetto
al semplice annullamento delle istruzioni pendenti
e/o flush della pipeline quando una sequenza di istruzioni
va scartata (perche puo "scartare" pure roba che nel frattempo
e' stata scritta in cache L1/L2 ma non ancora scritta
sulla memoria esterna perche "trattenuta" in attesa
di convalida di esecuzione corretta).
Ovviamente quella descritta sopra sarebbe la versione
piu sofisticata e' probabile che un implementazione reale
non sara' cosi "completa" o magari richiedera' il
supporto del compilatore per la generazione di opportune
istruzioni che fanno da "marcatori" e da write barrier
per ottenere un esecuzione corretta su sequenze
che altrimenti non potrebbero essere gestite dalla sola
logica interna del decoder istruzioni.
Sarebbe anche possibile ottenere funzionalita' multiscalari
"solo software" ma quello che e' possibile fare
senza apposito supporto hardware viene gia fatto
da alcuni tipi di compilatori (es: "spezzare" automaticamente
loop su matrici in piu thread).
L. Micheletto

 Bah, a me non piace questa opzione. Fa tanto fanatico.
Infatti se ci se ci si pensa il nome 4x4 fa "molto SUV". ;-)
Come Intel ha le cpu Extreme Edition
e' probabile che pure AMD voglia mantenere una presenza
nel "segmento SUV" delle cpu con i 4x4 visto che gli FX
con core K8 non sembrano bastare piu contro i Conroe
(ed i Woodcrest su cui si baseranno i Core 2 EE).
Se poi la differenza di prezzo rispetto ai sistemi
basati su Opteron 2xx fosse sufficientemente discreta
la cosa potrebbe interessare pure i non-fanatici.
L. Micheletto

 loop su matrici in piu thread).
Mi citeresti qualche nome di questi compilatori.


Il compilatore Octopiler per Cell di IBM, tanto per citarne
uno di qui si e' parlato tempo fa in questo newsgroup.
Ci sono poi i compilatori C/C++/Fortran di Intel, Portland Group,
Fujitsu/Lahey (solo Fortran) e prossimamente pure il GCC 4.2
(in cui verra' integrato il GOMP) tanto per citare i nomi piu noti.
Di solito tali funzionalita multiscalari vengono descritte come
auto-parallelizzazione (auto-parallelization)
oppure parallelizzazione automatica (automatic parallelization)
e si appoggiano su un runtime che implementa l'API OpenMP.
Nota comunque che sino ad ora le prestazioni migliori
si ottengono con applicazioni che vanno giu pesanti
con operazioni su matrici relativamente grosse oppure
con loop relativamente facili da sbrogliare, infatti
i primi compilatori/traduttori furono realizzati per la
parallelizzazione automatica di applicazioni scritte
in Fortran.
Ma le cose potrebbero cambiare considerando che certe feature
delle prossime cpu un arrivo sono state pensate tenendo presente
quel che serve per avere prestazioni migliori con codice
auto-parallelizzato.
L. Micheletto