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