HardWare.fr


Haswell et mémoire transactionnelle
Processeurs
Publié le Mercredi 8 Février 2012 par Guillaume Louel

URL: /focus/61/.html


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 d'AVX2 baptisée TSX apporte de nouvelles instructions qui permettent de gérer ce que l'on appelle mémoire transactionnelle. Contrairement à ce que son nom indique, la mémoire transactionnelle n'est pas un type de mémoire différent, il s'agit plutôt d'une manière différente d'accéder à la mémoire. Le principe de transaction n'est pas nouveau en informatique et se pose dans les cas où une ressource partagée peut être accédée de manière concurrente par plusieurs autres ressources.

Dans le cas qui nous intéresse, il s'agit de la mémoire système qui est partagée de nos jours entre de multiples cœurs de processeurs. Chaque cœur peut accéder à tout moment à l'intégralité de la mémoire du système, et la modifier. Si l'on ne fait pas attention, un cœur peut donc corrompre la mémoire pour un autre cœur, un problème fondamental pour les programmeurs qui est l'un des problèmes principaux de la programmation parallèle. Pour contrer cela, un tas de mécanismes ont été mis en place de manière logicielle, que ce soit dans le système d'exploitation, les langages de programmation, ou par les programmeurs eux même. Ils ont tous en commun d'être couteux et c'est à cela qu'est censé répondre l'implémentation matérielle de la mémoire transactionnelle dans Haswell.

TSX introduit deux modes distincts pour réaliser ce que l'on appelle des transactions. Il s'agit de regrouper ensemble un bloc d'instructions qui sera considéré comme indivisible (on parle d'atomicité). L'intérêt d'une transaction est d'assurer que le bloc soit exécuté dans son intégralité, ou pas du tout. Pour comprendre l'intérêt il faut revenir à un exemple d'un programme qui aurait besoin d'effectuer 100 fois de suite un même gros calcul sur des données différentes. Dans ce cas, les programmeurs ont divisé leur programme, lançant autant de thread qu'il y a de cœur disponible dans la machine. Chaque cœur effectue sa tâche puis en effectue une nouvelle, puis une autre, jusqu'à ce que le nombre de 100 soit atteint. Le programme doit donc maintenir un compteur du nombre total de gros calculs effectués : à chaque fin de tâche, le thread lancé sur un cœur lit ce compteur magique en mémoire, lui ajoute un, puis sauve cette donnée en mémoire. Si le concept peut paraitre correct, en pratique dans cette approche, il y a de fortes chances pour que plus de 100 calculs soient effectués, à cause d'un problème de concurrence. En effet, si deux threads finissent en même temps, il est possible qu'ils lisent tous les deux la même valeur (0), y ajoutent un, puis réécrive la valeur modifiée (1). Au lieu de lire 2, notre compteur lira toujours 1. Ici, une transaction résout le problème en regroupant dans un même bloc indivisible l'opération de lecture du compteur et son écriture. Dans ce cas, un thread attendra que l'autre ait terminé avant d'incrémenter le compteur. Une implémentation typique concernera l'utilisation d'un "lock", l'équivalent d'un verrou qui vous indique qu'il faut attendre son tour et que la ressource ait été libérée avant de pouvoir y accéder.
 

Hardware Lock Elision


Le premier mode de transaction proposé par TSX s'appelle Hardware Lock Elision (HLE). Il a la particularité d'utiliser deux instructions (XACQUIRE et XRELEASE) qui permettent de définir (d'entourer) les blocs que l'on souhaite considérer comme atomiques. Le programmeur devra toujours implémenter manuellement son système de "lock", il sera cependant désormais accéléré et surveillé par le processeur.


Ainsi, dans le cas de locks plus complexes, Haswell sera capable d'effectuer les opérations non mutuellement bloquantes en simultanée, le lock inutile étant alors omis ("elision" en anglais) sur Haswell. On notera que dans le cas ou une transaction est impossible (par exemple, le programmeur a oublié d'utiliser le lock a un endroit de son programme avant d'utiliser une ressource partagée, créant un conflit), Haswell exécutera le code atomique de manière non transactionnelle. HLE n'apporte donc pas de bénéfice direct côté sécurité ou facilité de programmation, mais permet d'améliorer les performances dans certains cas (les programmeurs tendant très souvent à abuser des locks lorsque cela n'est pas nécessaire) sur Haswell tout en laissant le code fonctionnel sur d'autres plateformes.
 

Restricted Transactional Memory


Le second mode proposé par Intel est baptisé Restricted Transactional Memory (RTM). Il s'agit cette fois ci d'une implémentation complète de mémoire transactionnelle. Trois instructions sont disponibles, XBEGIN, XEND et XABORT.


Contrairement au mode HLE où le programmeur devait toujours créer ses propres locks, RTM permet de s'en passer et d'entourer simplement les blocs que l'on souhaite devenir atomiques : ils seront alors exécutés comme des transactions. Cependant, dans le cas où une transaction est impossible, le programmeur doit impérativement proposer un plan de secours. L'implémentation du plan de secours (une adresse où l'on reroute le programme) n'est pas optionnelle car de nombreuses choses peuvent faire rater une transaction. La première est le programmeur lui-même qui peut utiliser l'instruction XABORT pour l'arrêter. La seconde concerne des opérations à l'intérieur du bloc qui ne sont pas compatibles. Dans certains cas, mixer des instructions SSE et AVX (qui utilisent les registres XMM et YMM du processeur) peut causer un arrêt de la transaction. D'autres instructions sont définies dans la documentation d'Intel comme dépendant de l'implémentation. On comprendra qu'il s'agit des instructions qui causeront un arrêt de transaction sous Haswell :


Le dernier cas concerne les événements externes. Le cas le plus gênant que nous ayons noté concerne la manière dont Haswell gère les transactions par rapport à la mémoire cache. Afin de simplifier l'implémentation, le processeur ne vérifie pas les adresses exactes des opérations d'écritures qui pourraient entrer en conflit mais se contente de vérifier la ligne de cache utilisée.

Bien entendu si ces instructions supportées par le processeur sont disponibles manuellement en assembleur, dans la majorité des cas c'est le compilateur qui devra implémenter les instructions. Intel, en collaboration avec IBM et Sun avait définit un modèle mémoire transactionnel  pour la norme C++11 qui sera implémenté entre autre par GCC (à partir de la version 4.7). Intel proposera également dans son compilateur C/C++ des intrinsèques (des fonctions C qui indiquent au compilateur d'utiliser une instruction assembleur donnée).
 

Conclusion


Au final ces premières informations sur l'implémentation de la mémoire transactionnelle dans Haswell nous laissent un sentiment partagé. Le mode HLE, de par sa rétrocompatibilité est particulièrement intéressant et devrait permettre de simplifier l'exécution de code qui n'a pas été écrit de manière optimale en apportant des gains de performances. Il faudra bien entendu que les programmeurs recompilent leur code en ajoutant les intrinsèques nécessaires pour en profiter mais le gain peut être intéressant. Le mode RTM de son côté montre aussi les limites du standard x86 qui, à force d'être étendu dans tous les sens pose le problème de l'interopérabilité.

Contrairement à des instructions mathématiques où un compilateur peut décider tout seul de dispatcher des instructions SSE ou AVX pour certains calculs en fonction du modèle de processeur sur lequel le programme tournera, la mémoire transactionnelle requiert soit une intervention du programmeur (par le biais d'intrinsèques, ce qui peut aussi être le cas pour les instructions mathématiques), soit un nouveau modèle mémoire pour le langage de programmation (le modèle mémoire transactionnel proposé plus haut pour C++11). Si l'on ajoute à cela l'inconnue en ce qui concernera l'implémentation éventuelle d'AMD, le mode RTM risque d'avoir encore plus de mal à s'imposer que les autres extensions au jeu d'instruction x86.



Copyright © 1997-2024 HardWare.fr. Tous droits réservés.