C'est par l'un de ses blogs qu'Intel vient d'annoncer une mise à jour de sa spécification AVX2 concernant Haswell, le prochain "Tock" d'Intel attendu pour 2013.Cette extension
Lire la suite ...

Eviter le partage d'une ligne de cache entre 2 CPU pour des raisons de performance est assez classique..

En l'occurrence ce n'est pas le problème, ici n'importe quel autre thread sur le système qui accède une ligne de cache sur lequel il y'a un lock l'invalidera.

des pertes de performances d'accès mémoire en applicatif, sont à prévoir ?
Ou le mécanisme à une élaboration pour le Miss-rate ?
(j'ai pas encore tout lu )

Pourquoi donc avoir remplacé "elision" par "elation" dans votre description du HLE (cf première illustration) ? "elation" voulant dire "allégresse", ça n'a pas trop de rapport avec le sujet !

Corrigé

Bonjour,  
Je ne voudrais pas défendre Intel mais je ne suis pas forcément d'accord avec vous sur le fait que ces nouvelles instructions n'apporteraient pas de facilités en terme de programmation (paragraphe sur HLE). L'auteur de la note sur le blog d'Intel prend le cas d'une table de hachage pour laquelle il explique qu'avec TSX il pourrait implémenter cette table avec la performance d'une table "lock-free" (implémentation sans mutex mais thread-safe ; à la manière des tables implémentées dans Intel TBB) et la facilité de programmation d'une table utilisant des locks. C'est non négligeable. Dans le cas de votre exemple de compteur, il est vrai qu'on voit mal ce que TSX apporte par rapport aux instructions atomiques.

Vous faites référence à cela : http://software.intel.com/en-us/bl [...] explained/ ?
 
Je ne pense pas qu'avec cet exemple l'on puisse dire que HLE facilite la programmation. En pratique utiliser un seul lock global sur la hashtable n'est pas une technique nouvelle, c'est même probablement l'implémentation la plus basique et classique qui existe.  
 
La différence à mes yeux est que HLE rend cette implémentation basique et lente très performante sur Haswell, c'est d'ailleurs ce que l'on a écrit en conclusion, en permettant un contrôle au niveau matériel des locks, un code qui n'a pas été écrit de manière optimale (avec des locks dont le scope est beaucoup trop large) va devenir performant via HLE.  
 
Dire que HLE apporte des facilités de programmation dans ce cas me parait un sacré raccourci. Si les performances de la hashtable sont critiques, implémenter un lock unique à scope large avec HLE ne sera efficace que sur Haswell. Dans le monde réel, c'est une mauvaise solution. Utiliser une lib tierce est probablement un meilleur choix.  
 
Si à l'inverse les perfs de la hashtable ne sont pas critiques, alors un lock à scope large tournera plus vite sur Haswell, avec un impact final sur les performances qui pourra être limité.

Merci pour l'article très complet comme toujours (pas tout tout compris mais je relirai à tête reposée ce soir ^^). Par contre je note quelques anglicisme dans l'usage de certains verbes :
"une ressource partagée peut être accédée de manière concurrente par plusieurs autres ressources. "
et
"Au lieu de lire 2, notre compteur lira toujours 1"
 
C'est peut être juste moi mais je trouve que ça sonne bizarre (alors que "can be accessed by" et "the counter reads 1" ça passe tout à fait en anglais).
 
Bref, pas bien grave mais j'avais envie de poster un commentaire XD

 
Je fais effectivement référence à cet article.  
 
Je suis tout à fait d'accord avec vous sur le fait qu'une table de hachage implémentée avec un unique lock n'est pas un truc nouveau et que ce n'est pas efficace en cas de forte contention.
 
Ce que je dis en revanche c'est que si on peut écrire un code aussi simple qu'une table de hachage avec un lock en obtenant la performance d'une implémentation bien plus évoluée, de type "lock-free", ça ressemble bien à une forte simplification de la programmation de la table efficace.  
 
J'ai l'impression que nous sommes d'accord mais que nous prenons la question depuis des points de vue différents. Nous sommes d'accord que HLE ne rend effectivement pas l'implémentation d'une table de hachage avec un lock plus simple. Ceci dit, ça l'est déjà assez. Par contre ça permet d'éviter la complexité d'une implémentation plus évoluée.

Penser qu'il s'agit d'une simplification de la programmation revient à dire qu'il faut uniquement se préoccuper des performances sous Haswell et non sur les autres architectures, alors même que l'intérêt de HLE est de proposer des binaires simplement compatibles avec les architectures qui n'implémentent pas TSX.  
 
Le programmeur qui prendrait la décision de "simplifier" son code de la sorte prendrait la décision d'agrandir l'écart de performances entre les architectures existantes et Haswell (ce qui, à n'en point douter, ravirait Intel dont on peut comprendre qu'ils militent pour que l'on présente les choses de la sorte sur leur blog ). Cela ne me semble pas cependant être une décision qu'un programmeur consciencieux doive prendre. Pour moi il ne s'agit donc pas d'une simplification. Si la zone de code est critique, c'est un mauvais compromis. Si par contre elle ne l'est pas, on aura un petit gain de performances gratuit sans avoir à implémenter mieux. Mais le programmeur ne l'aurait de toute façon pas fait.
 
HLE benifieciera a mon avis beaucoup aux programmeurs "qui ne cherchent pas a optimiser", et en cela Intel propose une réponse interessante.
 

D'une vous assumez que les performances de l'élision soient aussi bonnes que d'autres libs, de deux, il s'agit d'une solution qui ne marchera que sur une plateforme.

@C_Wiz: J'imagine que ma façon de penser est une sorte de déformation professionnelle... .

Trop de CUDA ?

Trop de CUDA sur Kepler...