Discussion :

[3DArchi]

Bêtement, je pensais qu'il y avait plus de subtilité...

[JolyLoic]

Et il y en a. En fonction du nombre de coeurs disponibles, des autres programmes qui tournent... le code sera parallélisé ou pas. Et s'il est parralélisé, ce sera d'une manière qui ne crée pas de thread système, ces derniers étant lourds à créer.

[3DArchi]

Donc il y a un différence entre les threads tels que les créé une application et ceux résultant d'une parallélisation. Peut-on dire que faire du multithread pour faire de la parallélisation est une erreur de conception (même si sur une plateforme multicoeur on peut espérer un gain de performance) ?

[Matthieu Brucher]

Et il y en a. En fonction du nombre de coeurs disponibles, des autres programmes qui tournent... le code sera parallélisé ou pas. Et s'il est parralélisé, ce sera d'une manière qui ne crée pas de thread système, ces derniers étant lourds à créer.

Il me semble que ce sont des threads tout ce qu'il y a de plus standard qui sont créés, tout du moins sous Linux Quand on compile avec gcc ou icc, on doit ajouter iomp5, et surtout pthread comme bibliothèque.

[Alp]

Et il y en a. En fonction du nombre de coeurs disponibles, des autres programmes qui tournent... le code sera parallélisé ou pas. Et s'il est parralélisé, ce sera d'une manière qui ne crée pas de thread système, ces derniers étant lourds à créer.

Ca s'est bien passé ?

[Médinoc]

Généralement, c'est parallélisé d'une manière à ne pas créer de nouveaux threads pendant le déroulement du programme: Tous les threads OpenMP sont créés à l'initialisation (généralement, autant de threads que de CPU vus par l'OS) et restent chacun sur son CPU.

[Matthieu Brucher]

Généralement, c'est parallélisé d'une manière à ne pas créer de nouveaux threads pendant le déroulement du programme: Tous les threads OpenMP sont créés à l'initialisation (généralement, autant de threads que de CPU vus par l'OS) et restent chacun sur son CPU.

Effectivement, ça se voit bien sur un valgrind, par exemple. En revanche, l'affinité des threads n'est pas garantie, il me semble (on l'impose avec un outil interne chez nous, donc ça me semble bizarre).

[Médinoc]

C'est possible. Pour l'affinité, c'était une supposition (qui me paraissait logique)

[JolyLoic]

Donc il y a un différence entre les threads tels que les créé une application et ceux résultant d'une parallélisation.

Le vocabulaire utilisé pendant la conférence était "task" pour un morceau de travail sérialisé qu'on exécutera en parallèle avec d'autres tasks, et "thread" pour l'objet du système gérant ce parallélisme.

Peut-on dire que faire du multithread pour faire de la parallélisation est une erreur de conception (même si sur une plateforme multicoeur on peut espérer un gain de performance) ?

Disons que manipuler directement des threads systèmes pour implémenter des tâches n'est pas optimal. Une couche d'abstraction entre les deux permet de pas mal optimiser.

Il me semble que ce sont des threads tout ce qu'il y a de plus standard qui sont créés, tout du moins sous Linux

Au final, des threads classiques seront utilisés, mais il n'y a pas bijection entre threads et tasks. A ce que j'ai compris, à chaque instant un thread travaille sur une tâche, et possède une liste de tâche en attente (et si cette liste est vide, il va en piquer dans la liste des tâches en attente du thread voisin).

Ca s'est bien passé ?

Oui. Même si en arrivant sur place, avec la vieille ville, la forteresse planant dessus du haut de son rocher, la montagne encore enneigée juste derrière, et le grand beau temps, il s'en est fallu de peu que je déchire mon billet retour

Pour un compte rendu plus technique, je vais essayer d'y bosser un peu ce week-end.

[Matthieu Brucher]

Au final, des threads classiques seront utilisés, mais il n'y a pas bijection entre threads et tasks. A ce que j'ai compris, à chaque instant un thread travaille sur une tâche, et possède une liste de tâche en attente (et si cette liste est vide, il va en piquer dans la liste des tâches en attente du thread voisin).

C'est le principe effectivement de TBB par exemple. Mais dans OpenMP, ce n'est pas comme ça, sauf dans la version 3 où le concept de task est présent (même si les boucles for peuvent aussi être vues ainsi).

[Alp]

Oui. Même si en arrivant sur place, avec la vieille ville, la forteresse planant dessus du haut de son rocher, la montagne encore enneigée juste derrière, et le grand beau temps, il s'en est fallu de peu que je déchire mon billet retour

Content que ça t'ait plu !
On se languit du feedback

En effet, chers visiteurs, Loïc y était et va donc nous rédiger un petit compte rendu. Ce sera d'autant plus intéressant qu'Intel commence à être au centre des technologies de parallélisme en C++ (et Fortran si j'ai bien compris).

[Matthieu Brucher]

Ce sera d'autant plus intéressant qu'Intel commence à être au centre des technologies de parallélisme en C++ (et Fortran si j'ai bien compris).

Depuis longtemps, ils ont proposé OpenMP dans leurs compilateurs, ils ont leur propre bibliothèque MPI (OK, pas trop adaptée aux clusters, mais tout de même), ils ont promu TBB, ...

[Mat.M]

Ou en d'autres mots une possibilité pour les applications mono-thread d'utiliser plusieurs coeurs à la fois ?

comme le dit Mathieu c'est pas possible.

[Mat.M]

Et il y en a. En fonction du nombre de coeurs disponibles, des autres programmes qui tournent... le code sera parallélisé ou pas. Et s'il est parralélisé, ce sera d'une manière qui ne crée pas de thread système, ces derniers étant lourds à créer.

Absolument c'est indiqué dans la FAQ de TBB

Intel TBB facilitates scalable performance in a way that works across a variety of machines for today, and readies programs for tomorrow. It detects the number of cores on the hardware platform and makes the necessary adjustments as more cores are added to allow software to adapt. Thus, more effectively taking advantage of multi-core hardware.