Pthreads et OpenMP

Question

Je suis en train de créer une application multithread en C sous Linux.

Je ne sais pas si je dois utiliser l'API POSIX thread ou l'API OpenMP.

Quels sont les avantages et les inconvénients de l'un ou l'autre ?

Edit :

Quelqu'un pourrait-il préciser si les deux API créent niveau du noyau ou au niveau de l'utilisateur des fils ?

Answer 1

Pthreads et OpenMP représentent deux paradigmes de multiprocessing totalement différents.

Pthreads est une API de très bas niveau pour travailler avec les threads. Ainsi, vous disposez d'un contrôle extrêmement fin de la gestion des threads (créer/joindre/etc), des mutex, etc. C'est assez simple.

D'un autre côté, OpenMP est beaucoup plus haut niveau, est plus portable et ne vous limite pas à l'utilisation du C. Il est également beaucoup plus facile à adapter que pthreads. Un exemple spécifique de ceci est la construction de partage de travail d'OpenMP, qui vous permet de diviser le travail entre plusieurs threads avec une relative facilité. (Voir également l'article de Wikipedia liste des avantages et des inconvénients .)

Cela dit, vous n'avez vraiment fourni aucun détail sur le programme spécifique que vous mettez en œuvre, ni sur la façon dont vous comptez l'utiliser. Il est donc pratiquement impossible de recommander une API plutôt qu'une autre.

Answer 2

Si vous utilisez OpenMP, il peut est aussi simple que l'ajout d'un seul pragma, et vous aurez fait 90 % du chemin vers un code multithread correct avec une accélération linéaire. Pour obtenir le même gain de performance avec les pthreads, il faut beaucoup plus de travail.

Mais comme d'habitude, vous obtenez plus de flexibilité avec pthreads.

En fait, cela dépend de votre application. Avez-vous un algorithme trivialement parallélisable ? Ou avez-vous simplement un grand nombre de tâches arbitraires que vous aimeriez exécuter simultanément ? Dans quelle mesure les tâches doivent-elles communiquer entre elles ? Quelle est la quantité de synchronisation nécessaire ?

Answer 3

OpenMP a l'avantage d'être multiplateforme et plus simple pour certaines opérations. Il gère le threading d'une manière différente, en ce sens qu'il vous offre des options de threading de plus haut niveau, comme la parallélisation des boucles, par exemple :

#pragma omp parallel for
for (i = 0; i < 500; i++)
    arr[i] = 2 * i;

Si cela vous intéresse, et si le C++ est une option, je vous recommande aussi Blocs de construction de l'enfilage .

Pthreads est une API de niveau inférieur permettant de générer des threads et des synchronisations de manière explicite. À cet égard, elle offre plus de contrôle.

Answer 4

Cela dépend de deux choses : votre base de code et votre place dans cette base. Les questions clés sont les suivantes : 1) "Votre base de code comporte-t-elle des threads, des threadpools et des primitives de contrôle (verrous, événements, etc.) ?" et 2) "Développez-vous des bibliothèques réutilisables ou des applications ordinaires ?".

Si votre bibliothèque dispose d'outils pour les threads (presque toujours construits sur une certaine forme de PThread), UTILISEZ-LES. Si vous êtes un développeur de bibliothèque, prenez le temps (si possible) de les construire. Cela en vaut la peine - vous pouvez mettre en place un threading beaucoup plus fin et avancé que ce que vous offre OpenMP.

À l'inverse, si vous êtes pressé par le temps ou si vous développez simplement des applications ou quelque chose à partir d'outils tiers, utilisez OpenMP. Vous pouvez l'envelopper dans quelques macros et obtenir le parallélisme de base dont vous avez besoin.

En général, OpenMP est suffisamment bon pour le multithreading de base. Dès que l'on arrive à un point où l'on gère directement les ressources du système pour construire du code hautement asynchrone, son avantage en termes de facilité d'utilisation est supplanté par les problèmes de performance et d'interface.