Question

La

bibliothèque de Threading Building Blocks (TBB) d'Intel semble vraiment intéressante. Même s'il existe même un livre O'Reilly sur le sujet, je n'en entends pas beaucoup parler En l'utilisant. Je suis intéressé par son utilisation pour certaines applications parallèles multi-niveaux (MPI + threads) dans les environnements Unix (Mac, Linux, etc.). Pour ce que cela vaut, je suis intéressé par les types d'applications hautes performances en calcul numérique / méthodes numériques.

Quelqu'un at-il des expériences avec TBB? Ça marche bien? Est-il assez portable (y compris GCC et d’autres compilateurs)? Le paradigme fonctionne-t-il bien pour les programmes que vous avez écrits? Y a-t-il d'autres bibliothèques sur lesquelles je devrais me pencher?

Était-ce utile?

La solution

Je l'ai introduit dans notre base de code car nous avions besoin d'un malloc parieur à utiliser lorsque nous sommes passés à une machine à 16 cœurs. Avec 8 ans et moins, ce n'était pas un problème majeur. Cela a bien fonctionné pour nous. Nous prévoyons d’utiliser les conteneurs simultanés à grain fin. Idéalement, nous pouvons utiliser la vraie viande du produit, mais cela nécessite de repenser la manière dont nous construisons notre code. J'aime beaucoup les idées de TBB, mais il n'est pas facile de les intégrer à une base de code.

Vous ne pouvez pas considérer TBB comme une autre bibliothèque de threads. Ils ont un tout nouveau modèle qui repose vraiment sur les threads et les abstient. Vous apprenez à penser en tâche, en parallèle pour les opérations de type et les pipelines. Si je devais construire un nouveau projet, j'essaierais probablement de le modéliser de cette manière.

Nous travaillons dans Visual Studio et cela fonctionne très bien. Il a été écrit à l'origine pour linux / pthreads, il fonctionne donc très bien là-bas également.

Autres conseils

Je ne fais pas de calcul numérique, mais je travaille avec l'exploration de données (pensez au regroupement et à la classification), et nos charges de travail sont probablement similaires: toutes les données sont statiques et vous les avez au début du programme. J'ai brièvement étudié le TBB d'Intel et je l'ai trouvé excessif pour mes besoins. Après avoir démarré avec du code brut basé sur pthread, je suis passé à OPENMP et j'ai obtenu le bon compromis entre lisibilité et performance.

Portabilité

TBB est portable. Il prend en charge les processeurs Intel et AMD (c'est-à-dire x86), les processeurs IBM PowerPC et POWER, les processeurs ARM et éventuellement d'autres. Si vous regardez dans le répertoire de construction , vous pouvez voir toutes les configurations de la construction le support système, qui comprend un large éventail de systèmes d'exploitation (Linux, Windows, Android, MacOS, iOS, FreeBSD, AIX, etc.) et de compilateurs (GCC, Intel, Clang / LLVM, IBM XL, etc.). Je n'ai pas essayé TBB avec le compilateur PGI C ++ et je sais que cela ne fonctionne pas avec le compilateur Cray C ++ (à partir de 2017).

Il y a quelques années, je participais aux efforts visant à porter TBB sur les systèmes IBM Blue Gene. La liaison statique était un défi, mais elle est maintenant traitée par le big_iron. inc construire un assistant système. Les autres problèmes supportaient des versions relativement anciennes de GCC (4.1 et 4.4) et garantissaient le bon fonctionnement de l'atomique PowerPC. Je m'attends à ce que le portage sur une architecture actuellement non prise en charge soit relativement simple sur les plates-formes fournissant ou compatibles avec GCC et POSIX.

Utilisation dans les codes de communauté

Je connais au moins deux frameworks d'application HPC qui utilisent TBB:

Je ne sais pas comment MOOSE utilise TBB, mais MADNESS utilise TBB pour sa file d'attente de tâches et son allocateur de mémoire.

Performances par rapport aux autres modèles de threads

J'ai personnellement utilisé TBB dans le projet Parallel Research Kernels , au sein duquel j'ai comparé TBB à OpenMP, OpenCL, Kokkos, RAJA, STL parallèle C ++ 17 et autres modèles. Consultez le sous-répertoire C ++ pour plus de détails.

La figure suivante illustre les performances relatives des modèles susmentionnés sur un processeur Intel Xeon Phi 7250 (les détails ne sont pas importants - tous les modèles utilisaient les mêmes paramètres). Comme vous pouvez le constater, TBB se débrouille plutôt bien, sauf dans le cas de problèmes plus petits, pour lesquels la surcharge de la planification adaptative est plus pertinente. TBB a des boutons de réglage qui affecteront ces résultats.

 gabarit PRK

Divulgation complète: je travaille pour Intel dans le domaine de la recherche et de la recherche de solutions.

J'ai utilisé le TBB brièvement et l'utilisera probablement davantage à l'avenir. J'ai aimé l'utiliser, surtout parce que vous n'avez pas à traiter avec les macros / extensions de C ++, mais que vous restez dans le langage. Aussi son joli portable. Je l'ai utilisé à la fois sur Windows et Linux. Une chose cependant: il est difficile de travailler avec des threads utilisant TBB, il faudrait penser en termes de tâches (ce qui est en fait une bonne chose). Intel TBB ne prend pas en charge votre utilisation de verrous nus (cela rendrait cela fastidieux). Mais dans l’ensemble, c’est mon expérience préliminaire.

Je vous recommanderais également de regarder openMP 3 également.

ZThread est LGPL, vous êtes limité à l’utilisation de la bibliothèque en liaison dynamique si vous ne travaillez pas dans un projet open source.

Les blocs de construction de threads (TBB) dans la version open source (il y a une nouvelle version commerciale, 299 $, ne connaissent pas encore les différences) est la licence publique générale GNU version 2 avec une soi-disant "exception d'exécution" (qui est spécifique à l'utilisation uniquement pour la création de logiciels libres.) J'ai vu d'autres exceptions d'exécution qui tentent d'approcher la LGPL, mais l'activation d'une utilisation commerciale et la liaison statique de ce n'est pas est désormais le cas.

J'écris ceci uniquement parce que j'ai saisi l'occasion d'examiner les licences des bibliothèques. Celles-ci devraient également être prises en compte lors de la sélection en fonction de l'utilisation que l'on entend leur donner.

Messieurs, Jihn pour avoir signalé cette mise à jour ...

J'ai examiné le TBB mais je ne l'ai jamais utilisé dans un projet. Je ne voyais aucun avantage (pour mes besoins) sur ZThread . Vous trouverez un bref aperçu un peu daté ici .

Il est assez complet avec plusieurs options de répartition des threads, toutes les classes de synchronisation habituelles et un thread très pratique basé sur des exceptions, "interruption". mécanisme. Il est facilement extensible, bien écrit et documenté. Je l'ai utilisé sur plus de 20 projets.
Il joue également bien avec tout * NIX prenant en charge les threads POSIX ainsi que Windows.

Vaut le détour.

J'utilise TBB dans un projet. Il semblait être plus facile à utiliser que les threads. Certaines tâches peuvent être exécutées en parallèle. Une tâche est simplement un appel à votre sous-routine parallélisée. L'équilibrage de charge est effectué automatiquement. C'est pourquoi je l'accepte comme une bibliothèque de parallélisation de niveau supérieur. J'ai atteint la vitesse de 2,5x sans beaucoup de travail sur un processeur Intel à 4 cœurs. Il y a des exemples, ils répondent aux questions sur les forums et il est maintenu et gratuit.

Il est utile de préciser le rôle que TBB (Threading Building Blocks) doit opposer à d’autres alternatives (par exemple, les fonctionnalités de concurrence C ++ 11x). TBB est une bibliothèque portable et évolutive (pas une extension de compilateur) vous permettant d'écrire votre code sous la forme de tâches légères que TBB planifiera pour s'exécuter aussi rapidement que possible sur les ressources de processeur disponibles. Il n’est pas conçu pour le filetage à d’autres fins (par exemple, la préemption).

J'ai utilisé TBB pour accélérer le traitement d'image existant des boucles for sur les lignes de balayage d'image en boucles parallel_for (un minimum de 2 à 4 lignes de balayage en tant que taille de "grain"). Cela a été très réussi. Il est nécessaire que votre corps de boucle soit (ré) écrit pour traiter un index arbitraire plutôt que de supposer que chaque corps de boucle est traité de manière séquentielle (par exemple, des pointeurs incrémentés entre chaque itération de boucle).

Il s’agissait d’un cas assez trivial car il n’y avait pas de stockage partagé à mettre à jour. L'utilisation des fonctionnalités les plus puissantes (par exemple, les pipelines) nécessitera une importante réinvention et / ou une réécriture du code existant. Elle convient donc peut-être mieux au nouveau code.

L’avantage puissant de ce code basé sur TBB reste portable, ne semble pas interférer avec d’autres codes ailleurs dans le même processus et utilise simultanément d’autres stratégies de threading, et peut ensuite être combiné à des stratégies de multitraitement à un niveau supérieur ou inférieur (par exemple, le code de TBB parallel_for pourrait être appelé à partir d’un filtre situé dans un pipeline de multitraitement TBB).

Avez-vous consulté la bibliothèque boost avec sa API de thread ?

  

Les blocs de construction Threading (TBB) dans   la version open source, (il y a un   nouvelle version commerciale, 299 $, ne pas   connaissez encore les différences) est GNU   Licence publique générale version 2 avec   Une soi-disant & # 8220; Runtime Exception & # 8221; (cette   est spécifique à l'utilisation que sur   créer des logiciels libres.) J'ai vu   autres exceptions d'exécution qui tentent   d'approcher LGPL mais permettant   utilisation commerciale et liaison statique cette   n'est pas le cas.

Selon cette question Les blocs de construction de threading sont utilisables sans restrictions de copie pour un usage commercial.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top