Bêtement, je pensais qu'il y avait plus de subtilité...
Version imprimable
Bêtement, je pensais qu'il y avait plus de subtilité...
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.
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) ?
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 :koi: Quand on compile avec gcc ou icc, on doit ajouter iomp5, et surtout pthread comme bibliothèque.Citation:
Envoyé par JolyLoic
Ca s'est bien passé ? ;)Citation:
Envoyé par JolyLoic
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).Citation:
Envoyé par Médinoc
C'est possible. Pour l'affinité, c'était une supposition (qui me paraissait logique)
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.Citation:
Envoyé par 3DArchi
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.Citation:
Envoyé par 3DArchi
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).Citation:
Envoyé par Matthieu Brucher
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 ;)Citation:
Envoyé par Alp
Pour un compte rendu plus technique, je vais essayer d'y bosser un peu ce week-end. :sm:
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).Citation:
Envoyé par JolyLoic
:aie:Citation:
Envoyé par JolyLoic
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).
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, ...Citation:
Envoyé par Alp
comme le dit Mathieu c'est pas possible.Citation:
Envoyé par JulienDuSud
Absolument c'est indiqué dans la FAQ de TBBCitation:
Envoyé par JolyLoic
Citation:
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.