Newsgroup: it.comp.hardware.cpu
Titolo: Inverse threading for AM2?

Pare che le attuali cpu AM2 abbiano già implementato questa funzione....
http://sharikou.blogspot.com/2006/06/inverse-threading-for-am2.html
-- 
Ciao mine
http://metropolis.blogs.com/
BMW 120d Attiva driver 

 
http://sharikou.blogspot.com/2006/06/inverse-threading-for-am2.html
Accidenti, sarebbe una rivoluzione non da poco.
Ma chissa' se e' vero.
-- 
BArrYZ
[_Sign?_]

 
http://sharikou.blogspot.com/2006/06/inverse-threading-for-am2.html
Per la miseria! E Lorenzo Micheletto diceva che non poteva averlo così 
presto! :-)
No, a dire il vero la sua supposizione rispondeva al fatto che non poteva 
esserci sul K8L dal momento che non c'era sui K8 normali, ma poco ne poteva 
sapere che in realtà c'era già sui dual core. Come mai è stato tenuto così 
nascosto? Pare una cosa sorprendente.
MaxArt 

 
http://sharikou.blogspot.com/2006/06/inverse-threading-for-am2.html
Si ma leggete anche i commenti...
Ciao,
fadeh 

> Si ma leggete anche i commenti...
In effetti credo che trovare due "pezzi" di codice (non 2 istruzioni)
sicuramente indipendenti, fatto a run time in hardware, sia non poco
complicato!
Pleg


E' questo il succo dell'Out of Order Execution.
MaxArt 

> E' questo il succo dell'Out of Order Execution.
Non credo sia la stessa cosa. Nell'esecuzione fuori ordine io cerco
istruzioni vicine indipendenti, non interi blocchi di decine/centinaia di
istruzioni che possano essere eseguite in parallelo.
E' questa la mia perplessita': il parallelismo a livello di istruzione lo
sfrutto, per quanto possibile, con le pipeline parallele dedicate, ma mi
sembra poco efficiente estendere la cosa (cioe' parallelismo delle singole
istruzioni) a livello di core paralleli: cioe', per eseguire due somme in
parallelo ne sposteresti una sull'altro core, ne calcoleresti il risultato e
la risposteresti indietro sul core primario? Mi sembra un grande overhead
per eseguire solo un'istruzione in piu'!
Magari sono riusciti a "fondere insieme" i due core in modo cosi' stretto
che, per dire, un thread riesce a vedere "direttamente" 6 pipeline per gli
interi invece di 3. In tal caso sarei molto contento :-) ma ho i miei dubbi.
E cmq, nell'articolo citato (ed e' la cosa che credo poi tutti gli
contestavano) il tipo non parlava di _istruzioni_, ma di _funzioni_.
L'esempio era
"v1=f1(..)
v2=f2(..)"
con f1, f2 indipendenti. Beh, Suppongo che quelle "funzioni" coinvolgano
decine di linee di codice (almeno!) e un po' di variabili, e quindi sia
assai difficile in hardware, in runtime essere sicuri che le due funzioni
siano indipendenti (forse anche a compile time non e' facile, ma non so
nulla di tecnologia dei compilatori).
Questa era la mia obiezione.
Pleg

Ah, mi e' venuta un'idea: potrebbero ad esempio usare i due core (o piu' :-)
per eseguire contemporaneamente le diverse ramificazioni di un salto
condizionato? Credo che l'Itanium faccia qualcosa del genere, giusto? Poi
semplicemente scartano le opzioni sbagliate, e non dovresti mai pagare la
penalita' di branch misprediction.
Boh, tanto per aggiungere un po' di carne al fuoco :-)
Pleg


Sinceramente non credo. E penso che in sostanza l'approccio di AMD sia 
piuttosto simile all'OOE.
C'č da dire che alcune istruzioni, ad esempio le SIMD (anzi, direi solo 
quelle), possono essere scisse molto bene tra i due core. Di un vettore o 
matrice, un core si occupa della prima parte, l'altro della seconda parte. 
E' giusto un esempio.
Tra i commenti nel blog di Sharikou, ce ne č uno molto tecnico ma 
interessante:
http://sharikou.blogspot.com/2006/06/inverse-threading-for-am2.html#c115086818479036008
MaxArt 

 presto! :-)
Per ora di certo si sa solo di quel brevetto (ma molti altri
ne hanno di simili) e che AMD stava lavorando alla cosa.
Se controlli (thread "4x4, nuova Panda o anti-Conroe?", con mio messaggio
di risposta postato il 4 giugno) io avevo parlato di una
implementazione multiscalare *decente*.
Per poter parallelizzare su piu core degli spezzoni di codice relativamente
corti servono delle funzionalita di fork & join molto efficienti
(e magari link dedicati, se possibile).
Questo perche piu c'e' overhead di "commutazione" e piu grandi
devono essere gli spezzoni da far eseguire in parallelo.
Il guaio e' che con software generico piu grandi sono gli spezzoni
e piu difficile risulta parallelizzarli (perche e' piu alta
la probabilita che vi siano dipendenze a livello di dati).
E' da anni che vari compilatori implementano funzioni
di auto-parallelizzazione, incluso il compilatore Intel
e quello del Portland Group (su cui AMD a suo tempo
ha investito), sarebbe assai strano che AMD abbia realizzato
una buona implementazione con supporto hardware e poi
"l'abbia lasciata li" dopo tutto questo tempo
che gli X2 sono in circolazione.
Sono due le possibilita piu probabili:
a) La funzionalita c'e' ma non fornisce un guadagno di prestazioni
    sufficientemente elevato a parte casi specifici
    (e per quelli AMD si limita a suggerire l'utilizzo del
     compilatore del Portland Group) ed AMD non vuole
     "bruciare" la tecnologia come Intel ha fatto con
     il Multithreading Simultaneo (con quell'implementazione
     mal riuscita chiamata Hyperthreading).
    In tal caso AMD sta aspettando di eseguire opportuni
    ritocchi architetturali e rendera' pubblico il tutto
    se e quando il guadagno di prestazioni sara' tale
    da essere interessante per una parte significativa
    di applicazioni.
b) AMD sta lavorandoci sopra e forse ci sara' qualcosa
    di pronto con le "nuove" cpu
    (il K8 a 65nm nel caso migliore, oppure
     il K8L o qualcosa che seguira' dopo).
In ogni caso per quel che se ne sa ora
per avere il massimo guadagno di prestazioni
serve il supporto della cosa a livello del compilatore
oppure qualche vero miracolo di implementazione
a livello del decoder delle istruzioni
(per spostare in hardware una parte notevole
  del lavoro di analisi del codice che negli
  auto-parallelizzatori attuali viene fatta
  tutta in software), ma il brevetto di cui si parlava
era riferito solo al meccanismo di fork & join
non a "miracoli" sul decoder.
L. Micheletto

 non a "miracoli" sul decoder.
Ok, grazie della spiegazione :-)
MaxArt 


Si, ma e' basata su dati incompleti, probabilmente
bisognera' attendere luglio e la commercializzazione
ufficiale dei Conroe per capire la portata
della "sorpresa" che AMD ha preparato per rovinare
la festa ad Intel.
L. Micheletto

 
http://sharikou.blogspot.com/2006/06/inverse-threading-for-am2.html#c115086818479036008
Per ulteriori dettagli tecnici consiglio di date un occhiata qui:
http://www.cs.wisc.edu/~mscalar/publications.html
Parecchie di quelle pubblicazioni valutano vari aspetti delle
implementazioni multiscalari e di cosa ci si puo fare praticamente.
Ovviamente non mi aspetto che l'ipotetica implementazione
dell'inverse threading fatta da AMD sia "completa"
ma con quello che ho linkato sopra ci si puo fare un idea
di quanto lo sara' nella "versione 1.0" e di quanto
possa crescere ulteriormente in implementazioni successive.
Ma in particolare per quel che riguarda la "versione 1.0"
cosiglio di dare un occhiata a
"Master/Slave Speculative Parallellization and Approximate Code"
dove si spiega nel dettaglio come "appaiare" 2 core spendendo circa
un 5% di area del chip ed ottenendo in cambio un incremento di prestazione
*medio* del 25% e massimo del 75% con codice single threaded.
Se il famigerato reverse hyperthreading di AMD e' quello descritto
sopra (ma potrebbero aver implementato anche roba
descritta nelle altre pubblicazioni nel link) come minimo
i K8 "abilitati" dovrebbero fare terra bruciata dei
Conroe con 2MB di cache L2, mentre a presidiare la fascia
alta in attesa dei K8L ci saranno i 4x4 (che con il reverse ht
  abilitato "a 2 a 2" dovrebbero reggere bene il confronto
con i Conroe con 4MB di cache L2).
Giusto per rendere l'idea, guardate ad esempio
i benchmark dei Conroe pubblicati su 
www.pcper.com
e fate caso che i dati degli E6400 ed E6300
sono "falsi" perche riferiti a Conroe con 4MB di cache L2
mentre gli E6400 e E6300 dovrebbero uscire solo con cache L2 da 2MB.
In altre parole gli E6400 ed E6300 "veri" andranno piu lenti
ed in vari benchmark le piglieranno anche da K8 "normali"
di pari prezzo.
Ora, immaginiamo un implementazione reverse ht
"decente" prendendo i benchmark single threaded dei K8
ed aggiungendo un 25% di prestazioni moltiplicando per 1.25
dove ci sono "punteggi" e moltiplicando per il suo inverso
(ovvero 0.8) dove invece si da il tempo in secondi.
Dopo questo ricalcolo un X2 a 2.4Ghz con reverse HT, in roba
single threaded se la gioca alla pari con un E6700 a 2.67Ghz.
Facendo lo stesso calcolo per i 4x4 con reverse ht abilitato
"a due a due" (benchmark multithreaded degli X2
con punteggi per 1.25 e tempi per 0.8) succede
altrettanto (con in realta' qualcosa in piu a favore
dei 4x4 a causa del raddoppio della banda di I/O
verso la ram).
IMHO e' improbabile che tutto questo sia gia presente
sugli attuali X2 AM2 senza che vi siano gia ulteriori dettagli
in circolazione, se fosse cosi' AMD starebbe per segnare
il colpo dell'anno (rovinando "l'evento" della
commercializzazione ufficiale dei Conroe e costringendo
Intel a riprendere l'inseguimento a livello tecnologico).
Ripeto, piu probabile che si tratti di roba che
sara' implementata sui K8 a 65nm
[ anche se non mi dispiacerebbe essere smentito :-) ].
L. Micheletto

 Intel a riprendere l'inseguimento a livello tecnologico).
Lo penso pure io. E questo silenzio di AMD fino al lancio di Conroe e' molto 
sospetto proprio se letto in questa chiave. Se se ne escono al momento 
giusto con questa tecnolgia per Intel la vedo veramente molto male, come 
molti analisti stanno gia' prevedendo visti i tagli del 60% sui prezzi che 
non verranno mai coperti in tempi utili e con una cosa cosi' rivoluzionaria 
sul piatto, tutti sono concordi nel dire che AMD avra' per la prima volta il 
coltello dalla parte del manico.
Tra l'altro la storia che i modelli Conroe usati nei test fossero taroccati 
si rafforza, visto che quelli in commercio avranno 2 MB e non 4 di cache, 
come tu stesso sottolineavi. Per un processore del genere e' una differenza 
fondamentale e i test a questo punto si dimostrano per quello che erano 
realmente: degli specchietti per le allodole, puro Hype per creare leggende.
Questa dell'Inverse Threading (i Direct Connect 2.0?) veramente potrebbe 
essere una cosa rivoluzionaria per l'informatica, perche' di fatto creerebbe 
dei sistemi scalabili a qualsiasi livello e si sfrutterebbe infinitamente 
meglio la potenza di calcolo rispetto a quello che si puo' fare oggi. Se 
veramente AMD sta per tirare fuori una cosa del genere, non vedo come Intel 
possa controbattere a livello tecnologico nell'immediato anche pompando 
ancora di piu' la cache o il processo produttivo.
A questo punto tutto dipende dalla tempistica, e da quanto tempo serva ad 
AMD per riuscire a perfezionare e commercializare questa sua creatura. Ma se 
addirittura gia' negli AM2 c'e' traccia di questa roba, insomma mi sa che 
sono davvero assai piu' avanti di quanto ci si possa immaginare e aspettano 
solo il momento giusto per massimizzare la botta a Intel.
Vedremo.
-- 
BArrYZ
[_Sign?_]

 Vedremo.
Chi vivrà vedrà...;D