Newsgroup: it.comp.hardware.cpu
Titolo: Processori Haswell nella roadmap Intel...

Del 10 febbraio:
 
http://www.hwupgrade.it/news/cpu/processori-intel-haswell-al-debutto-nella-primavera-2013_40679.html
 
 
se vi fidate, più comodamente con TinyUrl...
 
http://tinyurl.com/7tauu2w
 
 
Ciao

 
http://www.hwupgrade.it/news/cpu/processori-intel-haswell-al-debutto-nella-primavera-2013_40679.html
 
 
la roadmap lascia intendere che Ivy Bridge non avra' piu'
di 4 core fisici, e' indicato in modo generico ">= i7-3770K"
per Q3'12 , ho letto che anche AMD ha rinunciato ad un
modulo per i prossimi FX Piledriver che si fermeranno
ad 8 core (4m/8t)
 
tornando ad Haswell, segnalo una news sulla
memoria transazionale e sulle nuove istruzioni TSX :
http://www.tomshw.it/cont/news/cpu-intel-haswell-con-tsx-arriva-la-memoria-transazionale/35824/1.html
 
 
"TSX migliorerà l'efficienza nel calcolo su architettura multi-core. In
poche parole, queste istruzioni consentiranno una migliore gestione del
multi-threading, permettendo ai thread della CPU di lavorare
contemporaneamente, ma di non interferire l'uno con l'altro e creare colli
di bottiglia."
 
sembra interessante ma la frase conclude con :
 
"Per il consumatore probabilmente non cambierà molto, ma per i programmatori
potrebbe rivelarsi un buon passo avanti."
 
quindi i benefici li avremo nel 2014 ? compilatori e software
permettendo :)
 
ulteriori informazioni su questa tecnica da un'altra news
riguardante il processore BlueGene/Q di IBM (HPC):
http://www.tomshw.it/cont/news/cpu-ibm-con-una-nuova-memoria-nei-supercomputer/33053/1.html
 
 
"La memoria transazionale offre "un modo di organizzare attività correlate
in un unico grande lavoro per un'elaborazione più efficiente. Rimpiazza
l'attuale pratica di bloccare i dati fino a quando non è stata completata
un'operazione, un approccio che può rallentare le altre operazioni del
computer"
 
a quanto pare i conflitti vengono "taggati" nella cache L2 ,
se qualcuno volesse spiegare maglio sono tutto orecchi :)
 
ciao
luca
 
 
 

 se qualcuno volesse spiegare maglio sono tutto orecchi :)
 
Non so come funziona questo particolare sistema in dettaglio, ma
l'idea della memoria transazionale e' questa: oggi come oggi la
memoria non e' speculativa, cioe' una volta che un processore fa un
write nella gerarchia di memoria (nella sua cache L1, e poi da li'
verra' propagato a tutto il sistema) basta, e' andata, non si torna
indietro, non si puo' richiamare una write una volta che e' uscita dal
processore ed e' andata in memoria (*); con una memoria transazionale
invece un processore potrebbe dire alla memoria "qui comincia una
transazione: io leggo e scrivo questi indirizzi, ma queste modifiche
non devono essere rese effettive (cioe' visibili a tutto il sistema)
finche' non termino la transazione, e allora solo se la transazione e'
avvenuta con successo".
 
Quindi il processore potrebbe iniziae una transazione e scrivere nella
sua cache privata (L1 e L2); la cache a questo punto deve sapere che
quella e' una transazione e quindi il suo stato e' speculativo fino a
che la transazione non viene "committed". Puoi immaginare la
transazione in 3 passi:
* esecuzione: la transazione viene eseguita ma tutto il suo write-
state speculativo e' bufferizzato localmente (non visibile al resto
del sistema)
* validazione: il sistema verifica sia valida e consistente (cioe' in
soldoni non ha interferito con altre transazioni); se questa fase non
completa, la transazione viene abortita e il processo notificato (o la
transazione viene ritentata, eccetera)
* commit: il write-state della transazione viene reso visibile a tutto
il sistema (cioe' dal buffer viene scritto nella gerrachia di memoria
condivisa e non speculativa)
 
Un modo per farlo e' un sistema a token: nella fase di validazione il
singolo core chiede un token al sistema; questo token puo' essere
tenuto da un solo core alla volta, ed e' specifico per quell'area di
memoria che la transazione tocca; la transazione che ottiene il token
verifica e poi fa commit se tutto va bene. In pratica il token e' il
meccanismo per costruire un punto unico di serializzazione delle
transazioni.
 
 
 
(*) naturalmente il processore puo' eseguire read e write speculative,
mentre esegue codice speculato (ad es. dopo la predizione di un
salto), ma le write rimangono bufferizzate dentro il core e non sono
rese visibili alla cache fino a che quella scrittura non viene
validata (cioe' il branch da cui dipende non viene validato); allo
stesso modo potresti eseguire read speculative che causano eccezioni
di memoria, ma queste eccezioni non hanno effetto fino a che la read
non viene validata -- e se non lo e', l'eccezione non ha effetto e
scompare nel nulla perche' era farlocca

 scompare nel nulla perche' era farlocca
 
 
ti ringrazio per la spiegazione, posso approfittare e chiederti
un esempio pratico, sia con metodo tradizionale di accesso
alla memoria sia con TSX, ipotizzando il beneficio prestazionale ?
 
ciao
luca
 
 
 
 
 
 
 
 

 l'idea della memoria transazionale e' questa:  
 
CUT
 
Interessante...direi che questo approccio potrebbe risultare utile in 
contesti dove ci sia un elevato tasso di codice che esegue salti non 
condizionali e in generale in un ambiente intensamente multithreading 
:)
 
 

 
http://www.hwupgrade.it/news/cpu/processori-intel-haswell-al-debutto-nella-primavera-2013_40679.html
 
 
mi accodo qui per non aprire un nuovo thread, il 2013 e' lontano, eh :)
http://www.hwupgrade.it/news/cpu/nuovi-dettagli-sulle-cpu-intel-della-famiglia-haswell_40737.html
 
 
in evidenza le nuove istruzioni AVX2 e la grafica integrata
DX11.1 (OpenCL 1.2)
 
ciao
luca
 
 
 

2fast scriveva il 14/02/12 :

E ovviamente un nuovo Socket... stavolta ne ha 1150 :D
 
 

 alla memoria sia con TSX, ipotizzando il beneficio prestazionale ?
 
Il "metodo tradizionale" sono lock e mutex, e chiunque abbia
programmato multithreaded puo' dirti che mostruosa piaga sul culo
possono essere :)
In pratica devi fare a mano il meccanismo di cui sopra: in soldoni, se
piu' thread accedono alla stessa memoria e non devono andare in
conflitto, devi avere un lock. Il thread che vuole accedere alla
memoria acquisice il lock, fa quello che deve fare, poi lo rilascia.
GLi altri thread non possono acquisire il lock finche' l'altro thread
non l'ha rilasciato. Il meccanismo del lock (che e' in software) viene
costruito usando certe operazioni atomiche sulla memoria, garantite
essere atomiche dall'hardware.
 
Usare i lock puo' essere molto difficile, puo' causare deadlock (un
thread non rilascia un lock, gli altri aspettano questo lock che non
viene mai rilasciato, l'intero sistema si blocca), e' difficile
scrivere librerie e funzioni liberamente componibili, eccetera.
Spostare questa complessita' in hardware e' uan bazza per chi
programma. Per contro, devi pagare l'overhead hardware: adesso
l'hardware deve fare tutti quei check per tutte le scritture anche se
un programma non usa transazioni, il che puo' penalizzare un po' le
prestazioni. Inoltre diventa piu' difficile progettare e verificare
l'hardware e farlo scalare ad un numero di core piu' alto.
 
Per le prestazioni dipende moltissimo dal tipo di applicazione e dal
suo pattern d'accesso alla memoria e dal modo in cui i dati vengono
condivisi e bloccati tra i thread eccetera. Certe applicazioni possono
guadagnare parecchio in prestazioni, altre perdere un po'. IL grosso
vantaggio dovrebbe essere che scrivere software multithreaded diventa
piu' facile (ma qui dovrebbe commentare un softwarista, io sono un
hardwarista quindi poteri sbagliarmi su queste considerazioni sul
software).
 
 

 software).
 
beh, io sono "nothingwarista" quindi taccio ;)
 
ciao
luca
 
ps: curiosita' personale, puoi specificare le tue competenze da
"hardwarista" ?
 
 
 
 
 

 "hardwarista" ?
 
Digital ASIC Design Engineer per una compagnia della SIlicon Valley.
Non progetto CPU, ma lavoro su una classe di chip di quella taglia.

 Non progetto CPU, ma lavoro su una classe di chip di quella taglia.
 
chapeau :)
 
ciao
luca
 
 
 
 
 

 chapeau :)
 
riprendo dalla chapeau e segnalo un articolo di David Kanter
su Real World Tech :
http://www.realworldtech.com/page.cfm?ArticleID=RWT021512050738
 
le sue aree di competenza sono SpMT e TM
(SPeculative Multi Threading e Transactional Memory)
 
riprende alcuni argomenti fin qui illustrati, mi permetto di citare
alcune frasi particolarmente interessanti :
 
Academic Research
 
"Speculative multithreading (SpMT) focuses on using multiple hardware
threads (or multiple cores) to work together and accelerate a single
software thread. In essence, the single software thread is speculatively
split into multiple threads that can be executed in parallel. Transactions
are a natural fit for speculative threads, since it offers an easy way to
rollback incorrect speculation. The key advantage of SpMT is that it enables
existing single threaded code (which is the vast majority of all software)
to reap the benefit of multi-core processors. "
 
"Software TM has been available for a number of years, and many programmers
have played around with TM libraries. However, the performance overhead is
crippling large, 2-10× slowdowns are common, which precludes widespread use.
For TM to be more than a research toy, hardware acceleration and support is
necessary. "
 
"A technique related to transactional memory, called lock elision, was
pioneered by Ravi Rajwar and James Goodman in 2001. Rather than enabling
transactions, the idea was to design hardware to handle locks more
efficiently. If two threads are predicted to only read locked data, the lock
is removed (or elided) and the two threads can execute in parallel. Similar
to TM, if a thread writes to the data, the processor must rollback and
re-execute using locks for correctness. Lock elision has the advantage of
being easily integrated with legacy code, whereas TM requires substantial
changes to software. "
 
Commercial Developmet
 
"In 2009, AMD proposed the Advanced Synchronization Facility, a set of x86
extensions that provide a very limited form of hardware TM support. The goal
was to provide hardware primitives that could be used for higher level
synchronization such as software TM or lock-free algorithms. However, AMD
has not announced whether ASF will be used in products, and if so, in what
timeframe. "
 
"The most recent development is of course, Intels TSX and the implementation
in Haswell. Haswell is the first x86 processor to feature hardware
transactional memory. Intels TSX specification describes how the TM is
exposed to programmers, but withholds details on the actual TM
implementation. The first section of this article discusses the software
interfaces for Intels TM. The second section builds on this to analyze the
likely implementation details of Intels TM, based on my experience. "
 
tralascio pagina 2 e 3 ed arrivo all'analisi ed alle conclusioni: (pag.4) :
 
"There are immediate applications in a few areas particularly focused on low
level software systems. First, as Azul and Sun already demonstrated, lock
elision and TM are powerful tools for scalable garbage collection in Java,
and other dynamic languages. Additionally, all the existing research on
software TM systems can take advantage of Intels RTM to reduce overhead "
 
"Intel adopting transactional memory is a new era for computer architecture.
Haswell represents a nearly two decade journey from the initial
popularization of transactional memory in academia, to mainstream adoption
in a microprocessor. For those of us who have worked on transactional
memory, this is an exceptionally exciting moment. It is a time to look back
on the contributions that brought the industry here and begin to ponder the
opportunities that may unfold in the coming years. "
 
ricordo il link:
http://www.realworldtech.com/page.cfm?ArticleID=RWT021512050738&p=1
 
 
ciao
luca
 
 
 

 ad una CPU senza ? e' una domanda non un'affermazione :)
 
Come ho detto, non vedo alcuna correlazione tra le due cose.
 

 to reap the benefit of multi-core processors. "
 
 
L'idea e' quella di speculare che certe sezioni di codice sequenziale
siano in effetti parallele, ed eseguirle su thread diversi.
Il normale meccanismo superscalare out-of-order gia' cerca
parallelismo tra le istruzioni, ma la finestra entro cui cercare e'
abbastanza limitata (credo sia intorno a qualche decina di
istruzioni), e non e' speculativo -- viene proprio calcolato (in un
certo senso) il dataflow graph ed eseguito quello.
La tecnica descritta sopra invece cerca di speculare su scala piu'
ampia: ad esempio, un buon punto dove "tagliare" il codice sono
chiamate a funzione. Quando nel codice c'e' una chiamata a funzione
potresti speculare che quella funzione non interferisce con roba che
viene immediatamente dopo e lanciarla su un thread diverso. Ad
esempio, se nel mio codice avessi:
double a = f1(u, v, w);
double b = f2(x, y, z);
e le due funzioni non interferiscono l'una con l'altra, potrei
eseguirle in parallelo e poi fare merge dei risultati e continuare da
li'; questo tutto in hardware, trasparente al software. Se invece
durante l'esecuzione viene identificato un conflitto (ad esempio, nel
caso sopra, x e' uan variabile globale modificata da f1 nella sua
chiamata) allora l'esecuzione di f2 deve essere cancellata
("rollback") e ripetuta. Come vedi il meccanmismo transazionale si
adatta benissimo a questo caso: potresti "racchiudere" le due funzioni
in due transazioni e lanciarle su core diversi; la memoria
transazionale fara' i suoi check e ti dira' se c'e' stato conflitto o
no, e quindi se devi ripetere la computazione.

 Nella review che hai postato lo Xeon vince in prestazioni pure
 
ed infatti nessuno lo mette in dubbio :)
 
credo di aver espresso chiaramente le mie opinioni
in decine di post dopo le varie recensioni di BD
 
pero' e' anche chiaro che la soluzione SMT di Intel non offre
un margine di prestazioni considerevole in quei test specifici
(server) , qualcosina in piu' in ambito desktop/workstation
ma dipende dal software, ad esempio confrontando
un i5-2500K con un i7-2600K con applicazioni multithreaded
(fonte Anand) :
http://www.anandtech.com/bench/Product/288?vs=287
 
 
si nota che con 3ds e cinebench il guadagno e' risibile
(10-15%) mentre con povray e' ragguardevole (30-40%)
 
stessa differenza tra wme9 (risibile) ed x264 2nd pass
(ragguardevole)
 
non c'e' la controprova con un AMD FX con tutti i core
attivi rispetto alle sole unita' computazionali , su altri
siti c'erano prove del genere ma non li ho tra i preferiti,
se ti interessa li cerco ma andiamo fuori tema :)
 
ciao
luca