Discussion :

[3DArchi]

Bonjour,
Il existe beaucoup d'options pour faire du multithread : API spécifique de l'O.S., bibliothèques multiplateformes, abstractions de plus haut niveau, etc.
Qu'utilisez-vous pour vos développements concurrents et pourquoi ? Quels sont les limites que vous trouvez et qu'aimeriez vous avoir comme autres services ?

Ce sondage porte sur leur utilisation dans le cadre de la programmation concurrente, les objectifs principaux étant la réactivité et l'isolation (agents asynchrone => IHM non bloquantes, tâche dédié traitements, etc..). Pour la programmation multithread dans un objectif de supporter une montée en charge (programmation //), voir ce sondage.

[yamashi]

Je préfére coder moi même ma librairie de thread basé sur les API système comme ca le systeme est adapté à mes besoins et il n'y a rien de superflu. Les autres librairies étant concut pour être adapté à tous, je pense qu'elles sont un peu trop lourde pour quelque chose supposé être très rapide.
Les limites ? Le temps que ca prends à coder et les problèmes de thread non géré nativement (dead locks...) qu'il faut donc gérer soit même.

[screetch]

je développe pour des plates-formes plutot multiples (sous-entendu non supportées par boost) donc j'utilise l'API systeme (Win32 sous windows, pthreads sous linux/mac/solaris, spécifique sur console/iphone)

[JolyLoic]

J'ai plus voté pour ce que j'utiliserais sur un nouveau projet que pour ce que j'utilise dans du code historique. Dans "Autre", j'ai pensé aux TBB (mais aussi peut-être à la bibliothèque avec un positionnement semblable de Microsoft TPL)

[Luc Hermitte]

J'ai voté pour plein de choses.
Aujourd'hui : ACE
A tester : ICE
Demain: la partie threads de C++0x, à défaut ceux de boost, à condition qu'ils viennent à supporter les tâches qui communiquent via queues de messages (ACE_Task, agents de VC10 -- comment faire du MT sérieusement sans ça ?). Accessoirement, just::thread me semble implémenter des mutex hiérarchiques (cf l'article d'Herb Sutter à ce sujet), et mérite donc que l'on s'y attarde.

[Charlemagne]

(Je ne connais pas ACE ou POCO)
J'utilise l'API Windows, Mac et Pthread (Posix) dont je me suis fait des wrappers à la façon TBB (en moins complet).
Je préfère de loin l'API pthread à l'API Windows, mais ça oblige d'installer la lib pthreads_win32 (qui ne fait que wrapper l'API Windows).

J'ai voté "autre" en pensant à OpenMP: (c'est plus orienté calcul pur et dur pour paralléliser les boucles), je n'aime pas la syntaxe trop C. Ceci dit c'est facile, efficace et intégré à tout bon compilateur

J'ai jamais utilisé TBB, c'est tout de même le concept que je préfère, car ça ressemble à la STL, même si je trouve qu'il y a des lourdeurs.

Je trouve que Boost ne fait pas grand chose, si ce n'est wrapper l'API Windows, Mac ou pthread.

Quand le C++0x sera là, je m'y mettrai, ça fera plaisir de ne plus avoir 36 couches de wrappers...

PS: Je commence à toucher à OpenCL, c'est une interface C quand même compliquée (je me suis fait des wrappers...), mais c'est ce qui me parraît encore être le plus simple et le plus portable pour la programmation GPU.

[Mac LAK]

Personnellement, j'utilise toujours l'API native quand l'outil n'est pas prévu / conçu pour être portable (je pense notamment aux outils dédiés à un système donné).

Toutefois, dans le cas d'un projet portable, j'ai pu utiliser ACE, ICE et POCO. Boost ne fait pas partie du lot car non supporté sur certaines de mes plate-formes. Dans ce genre de cas, j'ai quand même nettement tendance à préférer abstraire l'intégralité des fonctions utilisées de l'OS et non pas juste la partie MT, d'où mon choix de librairies d'abstraction complètes d'un OS.

Au final :

• API natives : Win32 nettement supérieur à pthread sur le plan pratique / mnémotechnique. Toutefois, j'ai toujours déploré l'absence de locks lecteur/rédacteur sous Win32 (corrigé depuis Vista, mais pas sur les anciennes plate-formes), alors que cela existe sur pthread : cela pose parfois quelques soucis, amenant alors à utiliser une librairie générale pour le multi plate-forme au lieu d'un simple wrapper maison.
• ACE : OK, c'est puissant et ça supporte des cibles peu courantes. Toutefois, l'API n'est pas claire, la doc non plus et il y a quelques comportements étranges.
• POCO : Très puissant, très bien documenté, très pratique. Seul inconvénient : relativement peu de cibles supportées par rapport à ACE.
• ICE : Très léger sur le plan abstraction d'OS, c'est limité aux éléments essentiels à la gestion des threads / sockets. Toutefois, si cela suffit au besoin, c'est aussi pratique à utiliser que POCO.
• Le couple ICE (pour la communication) plus POCO (pour l'abstraction d'OS) est assez royal à utiliser.

A tester un de ces jours :

• OpenMP, notamment la compatibilité entre VS/Win32 et GCC/Linux (avec sources identiques, bien entendu).
• Trouver un pendant à PThreadWin32, qui wrapperait l'API Win32 sur Linux/PThreads, de façon à simplifier certains portages d'anciennes applications.

[Lightness1024]

openmp ca marche bien. faut pas l'oublier dans le sondage. sur mac faut avoir gcc 4.2 donc OSx10.6 mini. sous win ca marche bien aussi, a part un joli petit piège de l'implementation de microsoft qui leak les threads créés si ta boucle openmp ne part pas du main thread.

[Emmanuel Deloget]

J'ai voté C++11 / just::thread (enfin, std::thread maintenant), parce que ça me semble logique (et que la librairie est particulièrement bien pensée).

[Luc Hermitte]

just::thread c'est plus que le standard.
Cette implémentation commerciale offre des facilités supplémentaires pour le debuggage p.ex.

Sinon, il faudrait peut-être distinguer les libs orientés concurrences de celles orientées parallélisme -- et les hybrides, car il y en a toujours.
Il est difficile de laquelle est mieux quand en fait toutes ne couvrent pas le même spectre de fonctionnalités, et sont en fait complémentaires.

[uriotcea]

Bonjour,

J'utilise beaucoup OpenMP. C'est facile à utiliser et c'est portable sur toutes les OS. Mais il n'est pas dans la liste !

[Emmanuel Deloget]

just::thread c'est plus que le standard.
Cette implémentation commerciale offre des facilités supplémentaires pour le debuggage p.ex.

Sinon, il faudrait peut-être distinguer les libs orientés concurrences de celles orientées parallélisme -- et les hybrides, car il y en a toujours.
Il est difficile de laquelle est mieux quand en fait toutes ne couvrent pas le même spectre de fonctionnalités, et sont en fait complémentaires.

C'est plus que le standard, certes, mais c'est une implémentation basée sur l'interface proposée par std::thread (le standard ne faisant que donner des requirements et une interface minimale, just::thread reste une implémentation de std::thread avec des extensions qui sont vendor-specific).

[oxyde356]

J'ai voté boost::thread, simple et vraiment très pratique, de plus c'est plutôt complet niveau primitives de synchro, on fait ce qu'on veut avec de façon très intuitive et compatible linux/win. J'ai tellement l'impression de faire du marketing que je vais finir par dire : un acheter, un offert

[3DArchi]

Salut,

Sinon, il faudrait peut-être distinguer les libs orientés concurrences de celles orientées parallélisme -- et les hybrides, car il y en a toujours.

Il me semble que le sondage ne propose que des libs orientés concurrences, non ?

[Luc Hermitte]

Je trouve aussi.

[3DArchi]

Bonjour,

Pour tout ceux qui sont frustrés de ne pouvoir proposer OpenMP, TBB, PPL ou CUDA, un nouveau sondage est ouvert ici : Quelle bibliothèque pour la programmation parallèle ?. Vous allez pouvoir voter pour LA bibliothèque qui assure vos performances

[Klaim]

Je ne comprends pas pourquoi PPL et ITBB ne sont pas dans la liste, ils sont autant orienté parallélisme que concurrence (et même que c'est leur principal interet je trouve, avec tous les outils pour les Task...)