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.
0 |
0 |