Threading Building Block est une librairie qui a pour but d'offrir une interface agréable pour les développeurs en C++ qui souhaitent paralléliser leur code. Agréable, car vous avez la liberté de rester à un haut niveau d'abstraction, garder une formulation objet fonctionnelle et de ne pas vous intéresser aux détails d'implémentation. Le croirez-vous, modélisation objet et performance ne sont cette fois-ci pas incompatibles, bien au contraire.

Le fait de définir avec précision les données du problème en mode objet sans entrer dans les détails techniques donne à la librairie tout ce dont elle a besoin pour être performante sans lui imposer un cadre trop strict. Dans d'autres systèmes comme OpenMP vous ne définissez (pour simplifier) que votre modèle de données, la librairie n'a donc pas autant d'informations. La programmation fonctionnelle vous permettra elle de définir des architectures logicielles naturellement adaptées au multi-core. Vous pouvez être au summum, à la fois de la performance et de la modélisation, pourquoi se priver ?

Essayons de faire nos premiers pas parallèles avec TBB en commençant par un cas simple. Dans les exemples, vous trouverez "GettingStarted/sub_string_finder". Si vous êtes en ligne de commande il suffit de dézipper les sources et en-têtes et taper "make". Des projets pour Visual Studio et Xcode sont aussi disponibles. Il s'agit d'un problème simple de traitement de chaînes : pour chaque position dans une chaîne, savoir la longueur de la sous-chaîne qui se retrouve ailleurs dans la chaîne principale. Le problème n'est pas fondamental mais le code est simple à comprendre et à paralléliser. TBB vous évite certes d'avoir à coder les détails d'implémentation, mais il vous reste tout de même à définir à quel niveau de votre algorithme vous souhaitez inclure du parallélisme. Nous observons que l'algorithme peut être parallélisé au niveau du "pour chaque position dans une chaîne". En effet, chaque analyse peut s'effectuer sans connaissance du résultat des autres, tout ce qui est demandé est que chaque unité de traitement ait une copie de la chaîne en entrée et puisse agréger les résultats en sortie.

Il faut tout d'abord déplacer votre code de calcul dans une classe, ici "SubStringFinder". La définition d'une classe permet d'avoir une vision claire des variables qui sont utilisées dans la partie parallèle de votre code. Ce point est un grand classique de la programmation parallèle. L'opérateur de la classe est lui la partie "calcul". Constructeur :

Nous avons donc les données d'entrée (une chaîne) et une classe de calcul, il ne nous reste plus qu'à les associer pour lancer le traitement. Habituellement nous ferions directement appel à la classe en donnant une partie de la chaîne comme argument, le tout à partir d'une boucle pour couvrir toute la chaîne. Avec TBB je remplace la boucle par un appel à un "parallel_for" associé a un "blocked_range". La fonction lance le calcul, et le "range" est l'équivalent des limites de la boucle, avec des subtilités. La gestion de la classe de calcul reste identique. Appel TBB :

parallel_for(blocked_range(0, to_scan.size(), 1),
SubStringFinder( to_scan, max, pos ) );

Du point de vue du développeur, rien de révolutionnaire, il s'agit juste de reformuler dans un style de programmation fonctionnelle. La formulation est abstraite et simple à utiliser. Pour la librairie, par contre, cela change tout : TBB a maintenant le contrôle total du lancement de la partie parallèle d'une part, une partie calcul bien isolée et des données présentées sous une forme bien détaillée d'autre part. Le style n'est pas accessoire, il est à la base du fonctionnement de TBB.

Quelques changements stylistiques, une recompilation, et voila que votre code s'exécute en parallèle. Magique non ? En pratique la librairie a d'abord créé un pool de threads adapté à l'environnement d'exécution et matériel. Il a ensuite fallu gérer les allocations mémoire nécessaires localement pour chaque thread et transférer les données nécessaires vers chaque thread. Puis gérer une queue de travail ou les différentes classes de calcul puisent leurs données. Enfin, rapatrier les résultats dans une variable unique du thread principal avant de rendre la main à la partie non parallèle de votre code.

Il est toujours possible que chaque calcul prenne un temps différent en fonction de la donnée qui lui est fournie en entrée, ou qu'il y ait une granularité optimale pour découper vos données. Ces imperfections de parallélisme sont nuisibles à la sociabilité de votre logiciel parallèle, c'est-à-dire sa capacité à utiliser un grand nombre de coeurs efficacement. Si vous savez le prédire, renseignez TBB, le temps d'exécution n'en sera qu'amélioré. Ici nous avons opté pour un "blocked_range" pour distribuer en morceaux identiques la charge de travail entre threads, mais testez d'autres systèmes de répartitions. Idem pour la granularité. Il ne suffit après tout que d'un changement minime dans votre code et d'une recompilation.

Nous venons de voir un cas simple ou les calculs exécutés en parallèle sont indépendants et où le résultat final n'est que l'agglomération des résultats unitaires. Prenons un exemple plus complexe pour comprendre le réel apport de TBB : calculons combien de nombres premiers se trouvent dans un intervalle en utilisant le crible d'Ératosthène (fichiers dans "parallel_reduce/primes"). Savoir si chaque nombre est premier est un calcul indépendant, mais le nombre final est lui une valeur commune. Il faut calculer une opération à la fin des blocs parallèles pour obtenir le résultat composite. La fonction TBB parallel_reduce va donc faire un appel à une fonction de jonction en plus de l'operateur de calcul dans votre classe. Ici la classe "Sieve" (crible en anglais) a donc une fonction "join" en plus d'"operator".

Rien de bien spectaculaire pour les habitués de la programmation parallèle, la réduction est un classique. Mais la méthode par crible d'Ératosthène provoque un fort déséquilibre dans les calculs, qui plus est, dur à prévoir. L'implémentation qui vous est proposée utilise une méthode de division et conquête. En pratique, si un intervalle de nombres s'avère trop lourd à calculer pour un seul thread il est possible de le diviser entre plusieurs, dynamiquement au cours de l'exécution. Notez le second constructeur pour "Sieve", il est utilisé lors d'une division de tâche. Une réponse simple et stylée à un problème complexe. Vous voyez alors l'apport de la programmation fonctionnelle et comment TBB vous permet de l'utiliser pour paralléliser efficacement. TBB n'est pas seulement une énième interface vers la même couche de parallélisation mais bien un cadre qui fait le lien entre les dernières innovations en architecture logicielle et matérielle.

Nous avons vu un exemple de parallel_for et parallel_reduce mais TBB ne se limite pas à ces deux cadres. Vous pouvez par exemple travailler sous forme de pipelines linéaires, c'est à dire définir des dépendances entre opérations et un degré de traitement parallèle. TBB fera le reste et gérera l'équilibre entre différentes phases de votre traitement. L'appel à parallel_do permet, lui, de gérer les cas ou le nombre d'itérations est inconnu à l'avance tout en maximisant la capacité à travailler en parallèle. Outre ces cadres de parallélisations, TBB vous propose des structures de données utilisables en parallèle. Des HashMap Vector et Queue accessibles en parallèle en toute sécurité ? C'est maintenant possible, même si vous utilisez des threads sans passer par TBB dans votre code. Vous pouviez déjà synchroniser et protéger tous les accès à ces structures pour assurer la validité de vos données, mais les structures de TBB le font avec un minimum de dégradation de performance.

Avoir une librairie qui cache la complexité des threads logiques est utile, mais les threads ne sont pas toujours le bon outil pour paralléliser. Avec certains algorithmes il est nécessaire d'avoir beaucoup plus d'unités de calcul que de coeurs disponibles. Si vous programmez un jeu vidéo ou chaque personnage voit son intelligence artificielle gérée par un thread, vous risquez d'avoir des problèmes pour un grand nombre de personnages. Alors que si vous utilisez des tâches, elles se partageront plus aisément les coeurs. La ou le gestionnaire de l'OS gérait la priorité entre threads, c'est TBB qui la gère entre tâches. Or TBB a plus d'informations sur les besoins réels des tâches et peut donc repartir de manière optimale. La tâche est donc l'outil rêvé pour programmer en fonctionnel sans tenir compte des ressources matérielles tout en les exploitant à leur optimum. J'espère que vous saurez maintenant mieux situer TBB dans l'éventail des technologies logicielles de parallélisations. TBB offre un rare potentiel de performance à ceux qui maîtrisent la programmation fonctionnelle (attention c'est addictif).

Paul Guermonprez
Sr. Software Engineer - Intel Software EMEA

IntelliJ IDEA 12.1

Intel : vers de meilleurs expériences mobiles

Arrêtez le chasse-neige, programmez parallèle avec TBB
Threading Building Block est une librairie qui a pour but d'offrir une interface agréable pour les développeurs en C++ qui souhaitent paralléliser leur code. Agréable, car vous avez la liberté de rester à un haut niveau d'abstraction, garder une formulation objet fonctionnelle et de ne pas vous intéresser aux détails d'implémentation. Le croirez-vous, modélisation objet et performance ne sont cette fois-ci pas incompatibles, bien au contraire. Le fait de définir avec précision les données du problème en mode objet sans entrer dans les détails techniques donne à la librairie tout ce dont...

Pourquoi passer à la programmation parallèle ? (2ème partie)
Nous poursuivons ce mois-ci les raisons pour passer à la programmation parallèle et surtout les pièges à éviter et à maîtriser. Et ils sont nombreux ! Deadlock Parfois nommé étreinte fatale, le deadlock est provoqué par des threads mutuellement verrouillés. Cette situation peut être comparée à deux personnes dessinant des diagrammes tout en se partageant un crayon et une règle. Si une personne prend le crayon et l'autre prend la règle, un blocage se produit lorsque la personne avec le crayon a besoin de la règle pour terminer son travail alors que la personne avec la règle a besoin...

Pourquoi passer à la programmation parallèle
A l’occasion de la sortie d’Intel Parallel Studio et des nombreuses avancées que les éditeurs préparent pour 2009 et 2010, Programmez ! vous propose de mieux comprendre la programmation adaptée aux processeurs à plusieurs coeurs. C’est ce que l’on appelle la programmation parallèle. C’est- à-dire capable d’exécuter plusieurs opérations, instructions, parallèlement sur plusieurs processeurs ou plusieurs coeurs. Complexe à maîtriser, le parallélisme est le mont Everest du développement. Nous vous proposons de l’aborder méthodiquement en posant les fondamentaux pour bien l’assimiler et éviter...

Version finale : Intel Parallel Studiodébarque
La programmation est l’art de schématiser et simplifier un processus pour l’automatiser. Nous aboutissons donc le plus souvent à un code sériel. Avec l’arrivée de puces multi-core, et bientôt massivement multi-core cette approche atteint ses limites : Il vous faut passer à la programmation parallèle. N’ayez crainte, Intel est là pour vous aider avec un ensemble logiciel aussi convivial que complet : Intel Parallel Studio. Le parallélisme se conçoit à plusieurs niveaux, mais celui qui nous intéresse ici est le " thread ". Intel Parallel Studio est un ensemble de logiciels pour vous aider à...

Intel Parallel Studio : Vous ne reconnaîtrez plus votre C++
Dans les deux précédents articles sur Intel Parallel Studio, nous nous sommes intéressés aux outils Inspector et Amplifier qui permettent respectivement de corriger et accélérer vos logiciels parallèles. Mais nous n'avons pas encore abordé Composer, qui est le compilateur associé à diverses librairies comme Intel Threading Building Blocks et Intel Performance Primitives (TBB et IPP). De nos jours, un compilateur ne peut se contenter de produire un binaire minimaliste, même optimisé. Il doit vous aider à adopter une syntaxe plus claire, apporter un éclairage nouveau sur votre code et...

Plus de coeurs, plus rapide, plus scalable : du multi-core au " many-core ”
Ecrire des applications parallèles se simplifie, et nous avons vu précédemment que chasser les bugs parallèles était rapide et intuitif avec Intel Parallel Inspector. Reste maintenant le principal problème : utiliser pleinement tous les coeurs simultanément. Une station de travail multi-core a typiquement 8 coeurs, 16 vus par l’OS avec la nouvelle technologie SMT (Simultaneous Multi Threading) et dans l’avenir beaucoup plus. Le consensus actuel dans l’industrie des processeurs est que les gains de performance viendront essentiellement par l’ajout de coeurs : nous sommes à l’orée de l’ère...

La chasse aux bogues parallèles avec Intel Parallel Inspector
Nous avons été formés à programmer en mode sériel et passer à la programmation parallèle n'a rien d'évident, mais plusieurs technologies existent pour vous faciliter la vie : Intel Threading Building Blocks ou le standard OpenMP par exemple. Une fois les concepts de base assimilés, implémenter un programme parallèle qui utilise à peu près efficacement un processeur à deux ou quatre coeurs va assez vite si votre algorithme s'y prête. Mais il est surtout très facile de transformer un logiciel sériel sans bogue en un logiciel multithreadé fortement bogué sans que ce soit évident, ni à...

Intel Parallel Studio: simplifier le développement parallèle !
Alors que les processeurs multi-cores (multi-coeurs) prolifèrent, améliorer les performances logicielles, et mieux utiliser la puissance processeur, demeure un enjeu important pour rester compétitif, surtout pour les applications développées en C ou C++. Mais jusqu’à présent le développement parallèle restait complexe à aborder pour le développeur. Programmez ! vous invite à découvrir en avant-première la nouvelle solution Intel, avec un tout nouveau plug-in Visual Studio, qui va radicalement changer votre vision du développement parallèle. L’année 2009 sera non seulement l’année de la...