Le C++ est-il adapté pour le multithreading et la programation parallèle ?

Version imprimable

23/05/2009, 00h12
Alp

Le C++ est-il adapté pour le multithreading et la programation parallèle ?

Bonsoir,

Selon vous, C++ fait-il partie des langages les plus adaptés pour le multithreading et la programmation parallèle, sujet au coeur de la recherche et des évolutions aujourd'hui ? Quels sont les meilleurs outils pour en tirer au mieux parti ?

N'hésitez pas à argumenter, bien au contraire :)

PS : voici quelques discussions qui se rapportent au développement parallèle en C++
http://www.developpez.net/forums/d74...rallel-studio/
http://www.developpez.net/forums/d74...-parallelisme/
23/05/2009, 09h27
hiura

J'ai jamais poussé très loin mes utilisations des fils, mais je suis tombé sur ceci. Tout porte à croire que le C++ est effectivement adapté à cette utilisation si le comité décide d'ajouter ces outils à la STL.

Après, il faudra voir le résultat.
23/05/2009, 09h50
Matthieu Brucher

Beaucoup de frameworks existent pour le C++ permettant la programmation parallèle. Ils sont tous plus ou moins efficaces :
- OpenMP
- MPI
- TBB
- wxWidgets
- Qt
- ...

Bref, très efficace. Et avec les fonctions lambda, ça va encore aller en s'améliorant.
23/05/2009, 10h31
JolyLoic

Déjà, j'aimerais distinguer 3 types de multithreading :
- Pour les performances (exploiter un matériel multi-cœurs)
- Pour la réactivité (une IHM qui reste réactive quand le calcul s'éxécute, un programme gérant en temps réel des évènements extérieurs)
- Pour l'isolation (un serveur web isolant les différentes réponses à différentes requêtes)

Je pense que la question était particulièrement orientée vers le parallélisme pour la performance, qui est en effet d'actualité de nos jours.

Pour la question, aujourd'hui, je dirais non car :
- Le comportement multithread du C++ est platform dependant
- Il n'y a rien de standard pour gérer les threads, les locks...
- Il n'y a rien qui permette de remonter une exception depuis un thread vers le thread l'ayant lancé
- La notion de fonction pure qui permettrait d'aider une parallélisation automatique n'existe pas
- La syntaxe pour désigner une action est lourde (pas de lambda-expression)
- C'est un langage impératif, qui plus est où la possibilité d'aliasing est omniprésente, rendant la parallélisation difficile.

L'avantage, c'est qu'à part le dernier point, tous sont adressés par C++0x :)

Et comme d'un autre côté, le C++ est un langage qui est orienté performances, il me semble naturel que que faire de la performance grâce au parallélisme se base déjà sur le fait de faire de la performance tout court.

Autre point positif, le C++ est un langage où tout est fait pour permettre de bâtir des niveaux d'abstraction élevés à partir de couches bas niveau, sans que cette abstraction ait un coût trop important. Threads et lock sont des primitives bas niveau. Des bibliothèques comme TBB sont d'un niveau un peu plus élevé. Tout un niveau où le parallélisme devient non plus explicite mais implicite reste à construire.
23/05/2009, 11h11
Matthieu Brucher

Citation:

Envoyé par JolyLoic

Et comme d'un autre côté, le C++ est un langage qui est orienté performances, il me semble naturel que que faire de la performance grâce au parallélisme se base déjà sur le fait de faire de la performance tout court.

Certains diront qu'il manque à ce niveau la possibilité de supprimer l'aliasing de pointeurs :|
23/05/2009, 12h13
Arzar

Citation:

Envoyé par JolyLoic

- La notion de fonction pure qui permettrait d'aider une parallélisation automatique n'existe pas.
[...]
- C'est un langage impératif...

L'avantage, c'est qu'à part le dernier point, tous sont adressés par C++0x :)

Des fonctions pures ?
Je ne me souviens pas avoir vu passer de proposition pour ça et la recherche du mot "pure" dans le draft de mars ne donne rien (sauf des références aux fonctions virtuelles pures)
Est-ce une exclu pour developpez ? :D
Aurais-tu quelques détails ?
24/05/2009, 11h58
JolyLoic

Citation:

Envoyé par Arzar

Des fonctions pures ?
Je ne me souviens pas avoir vu passer de proposition pour ça et la recherche du mot "pure" dans le draft de mars ne donne rien (sauf des références aux fonctions virtuelles pures)

En fait, j'ai été un peu trop enthousiaste...
L'idée n'est pas forcément d'avoir une gestion par le standard de fonctions pures, mais de permettre à des compilateurs de gérer la notion de fonction pure. Mais cette idée fait débat.

En gros, il y a une proposition sur les attributs, et parmi les exemples d'attributs, l'un des plus cités est un attribut pure pour les fonctions. Mais les attributs seraient en grande partie non standards, juste des points d'expansion pour les compilateurs. http://www.open-std.org/jtc1/sc22/wg...2008/n2553.pdf
24/05/2009, 12h24
Goten

Sinon, en quoi les lambdas vont dans le sens de la programmation parallèle? (dans ma tête le mécanisme mis en oeuvre part le compilo revient à créer un foncteur)
24/05/2009, 12h34
Matthieu Brucher

On a souvent besoin de ce genre de fonctions/foncteurs/... pour le parallélisme. Ca permet donc de réduire le nombre de lignes à écrire. Ou de ne pas les appeler en-dehors d'un framework.

On y gagne en nombre de lignes à écrire, mais aussi en localité du code, et en besoin de trouver un nom.

Si j'ai une fonction :

Code:

1
2
3
4
5
6
7
8
9
10
void f()
{
  vector<double> v;
  // ... 
  for(auto it = v.begin() ; it != v.end() ; ++it)
  {
    *it = 2*g(*it);
  }
  // ...
}

Et que je désire remplacer le for par un parallel_for, avec un simple foncteur, je dois écrire :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
struct ApplyGAndDoubleResult // nom pas forcément bien choisi, de plus, on ne sait pas trop où cette classe va servir
{
  double operator()(double d)
  {
    return 2*g(d);
  }
}; // Pas mal de lignes de code
 
void f()
{
  vector<double> v;
  // ... 
  // On est obligé d'aller regarder ailleur pour voir ce qui se passe dans la boucle
  parallel_for(v.begin(), v.end(), ApplyGAndDoubleResult ());
  // ...
}

Avec des lambdas, on se retrouve bien plus proche du code initial :

Code:

1
2
3
4
5
6
7
8
9
10
void f()
{
  vector<double> v;
  // ... 
  parallel_for(v.begin(), v.end(), [](double d)
  {
      return 2*g(d);
  });
  // ...
}

24/05/2009, 15h13
Goten

Ahhh d'accord, je pensais que les lambdas permettrait des optimisations derrière pour du MT. Mais en fait non c'est par rapport à la compréhension du code. C'est le sens que j'avais pas compris.
09/08/2009, 17h07
Aurelien.Regat-Barrel

Citation:

Envoyé par JolyLoic

- Il n'y a rien qui permette de remonter une exception depuis un thread vers le thread l'ayant lancé

Je ne comprends pas le fonctionnement / usage. Chaque thread ayant sa propre pile, et les exceptions remontant cette pile, comment ça marche / s'utilise ?
09/08/2009, 18h20
Jean-Marc.Bourguet

Citation:

Envoyé par Aurelien.Regat-Barrel

Je ne comprends pas le fonctionnement / usage. Chaque thread ayant sa propre pile, et les exceptions remontant cette pile, comment ça marche / s'utilise ?

Un exemple d'utilisation basé sur la notion de "future" où on lance un calcul en parallèle en gardant un objet qui représente le résultat, quand on essaie d'avoir la valeur du résultat, on bloque en attendant le résultat du calcul. Si le calcul échoue à cause d'une exception, il est sensé de jeter à nouveau cette exception quand on cherche à obtenir la valeur. Il est d'autres cas où on peut vouloir copier une exception d'une thread à l'autre.
09/08/2009, 18h48
Aurelien.Regat-Barrel

Merci pour l'explication.
09/08/2009, 20h46
yan

Citation:

Envoyé par Aurelien.Regat-Barrel

Merci pour l'explication.

Pour info, les QtConcurrent l'implémente
http://doc.qtsoftware.com/4.6-snapsh...exception.html
09/08/2009, 21h00
Jean-Marc.Bourguet

Citation:

Envoyé par yan

Pour info, les QtConcurrent l'implémente
http://doc.qtsoftware.com/4.6-snapsh...exception.html

A condition de la classe d'exception hérite d'une classe de Qt.
25/06/2012, 09h21
ptyxs

La question initiale mériterait d'être reprise à la lumière des apports du C++11, non ? (même si les fonctionnalités concernant les threads sont encore celles qui sont le moins implémentées dans les grands compilateurs, mais, ma foi, ça ne saurait tarder maintenant...).

A noter un livre excellent sur le sujet :

C++, Concurrency in Action, par Antony Williams