Discussion :

[3DArchi]

Bonjour,

Un volet du développement multithread a pour objectif de distribuer les calculs sur plusieurs cœurs d'exécution afin de permettre d'améliorer sensiblement les performances et de pouvoir supporter une montée en charge des données à traiter. Plusieurs bibliothèques existent utilisant différentes approches :

• SIMD
• Multicoeur/multiprocesseur
• GPGPU

Certaines bibliothèques interviennent sur plusieurs de ces différentes possibilités.

Laquelle/Lesquelles utilisez-vous ou aimeriez-vous utiliser sur vos projets ? Quels sont leurs avantages ? Leurs inconvénients ? Que manque-t-il ?

Ce sondage est le pendant de celui ci qui porte sur la programmation concurrente.

[Lightness1024]

il ne faut pas oublier Thrust

[bzerath]

En Java j'utilise Ateji PX. C'est pas mal, ca simplifie vachement le parallélisme.

Juste dommage que faute de moyens ils n'aient pas sorti de version stable pour la programation sur le GPU.

http://www.ateji.com/

[YannPeniguel]

En C++, j'ai utilisé les QThread du Framework Qt: http://developer.qt.nokia.com/doc/qt-4.8/qthread.html
En C, j'ai utilisé les threads Poxix: https://computing.llnl.gov/tutorials/pthreads/
Et les threads de la glib: http://developer.gnome.org/glib/2.28/glib-Threads.html

[tbarry]

en C, j'utilise l'extension Openmp, facile à utiliser et très efficace, tout en restant très proche du séquentiel.
>possibilité de fixer ou pas le nombre de coeur à utiliser, et de partager le travaille de façon dynamique/statique entre les coeurs rien qu'avec des directives ex: #pragma openmp parallele for.... pour paralléliser une boucle for

don't patch a bad code, rewrite it

[OcterA]

Idem pour moi, j'ai utiliser la librairie OpenMP lors d'un projet de traitement d'image en C++.
Cette libraire grâce à ces pragma super bien foutu et très intuitive m'as permis d'améliorer mes performance de filtres (algo déjà optimisé au maximum) par 10.
Comme l'as fait souligner tbarry, une petite pragme du genre "#pragma openmp parallele for" juste avant votre for et le tour est (quasiment) joué.

[vivi168]

en c les posix thread

[Rozebud]

CUDA et PyCUDA sont très pratiques pour les calculs numériques intenses.

[mhtrinh]

en C avec OpenMPI
Je suppose que Boost.MPI c'est pour du C++ ?

[shenron666]

en C++ : au début j'utilisais les threads de l'api win32 puis j'ai testé un peu OpenMP et finalement j'ai jeté mon dévolu sur Boost.Threads qui a le gros avantage d'être portable
mais ça fait près de 2 ans que je n'ai pas fait de C++

en C# : TPL et Reactive Framework

[Gouyon]

Moi j'utilise les thread de l'api win32 (à la dure). Je n'ai pas encore testé OpenMP et cie. Mais le prochain développement massivement parallèle que je ferais sera sans doute avec CUDA.

[Xanto]

OpenMP pour son efficacité et surtout sa simplicité.

[Matthieu Brucher]

Tiens, ca pourrait etre interessant de refaire le sondage avec les bibliotheques actuelles.

Plusieurs points :
- Boost.MPI est un wrapper pour MPI 1, donc deprecie
- Idem pour ATI.Stream
- Je suppose que OpenAAC est en realite OpenACC ?

Certaines des bibliotheques ne sont que pour les accelerateurs, donc moins pertinentes que les bibliotheques plus generalistes.

Le gros souci de TBB, c'est le flou assez complet qui regne autour de l'exception a la GPL2 qu'elle contient. Assez insupportable, car autrement, il s'agit d'un tres bonne bibliotheque.

[RPGamer]

Attention, plusieurs concepts qui n'ont rien à voir son mélangés dans ce sondage. La programmation concurrente (multithreading) n'a aucun rapport avec la programmation parallélisée (SIMD par ex). Je dirais même que le choix d'utiliser telle ou telle approche est fait dans des contextes totalement différents.