Conférence parallélisme Intel : Appel à questions

Version imprimable

13/04/2009, 12h41
JolyLoic

Conférence parallélisme Intel : Appel à questions

Bonjour,

Je vais la semaine prochaine (20 et 21 avril) à une conférence organisée par Intel pour présenter ses outils en matière de développement parallèle (intel parallel studio, thread building blocks...). Je vais écrire un article pour Développez.com suite à cette conférence, et je devrais pouvoir y effectuer une interview d'un représentant d'Intel sur ce sujet.

Auriez-vous des questions que vous aimeriez me voir poser lors de cette interview ?
13/04/2009, 13h21
Matthieu Brucher

En vrac :
- la place de Linux dans leurs développements (comme il y a Parallel Studio (que je dois finir de tester) mais que sous Windows, même s'il y a des choses dans le débuggeur graphique sous Linux), sachant que les plus gros sont sous Linux
- leur langage de recherche sur le parallèle, leurs opinions sur les méthodologies de programmation parallèle, l'impact sur les extensions qu'ils proposeront pour les compilateurs C/C++(/Fortran)
- SDK C/C++ pour Larrabee sous Linux dispo quand ? (apparemment le langage précédemment cité serait fourni pour la sortie Larrabee)
14/04/2009, 09h47
white_tentacle
La vérification de parallélisabilité du code. Comme ce n'est sûrement pas clair, je détaille

Actuellement, on peut écrire (en tout cas, au dernières nouvelles que j'avais eu, à savoir, une présentation microsoft sur le sujet) du code de ce genre :
Code:

1 2 3 4 parrallel_for(int i = 1; i < v.size(); ++i) { v[i] = v[i-1] + 1; }
J'aimerai savoir s'ils ont prévu de faire en sorte que ça ne compile plus... (certains compilos pour DSP font de la parallélisation de code, et détectent que ce code n'est pas parallélisable, donc ça ne semble pas délirant à faire).
14/04/2009, 10h22
Matthieu Brucher

Il y a une détection chez Intel pour ce genre de chose (proven dependency, on voit ça très bien dans les logs de compilation), donc pas besoin de l'ajouter au niveau de la vectorisation.

Si maintenant, tu parles plus d'aliasing de pointeurs, c'est à l'utilisateur de s'en mordre les doigts. Si tu dis qu'il peut paralléliser et que tu lui donnes les mauvais arguments, aïe...
16/04/2009, 17h38
camboui

Que regroupe la notion de "parallélisme" ?
-du multithreading
-des opérations à opérandes multiples
quoi d'autre ?
16/04/2009, 21h19
JolyLoic

En l'occurrence, c'est le fait d'exécuter du code dans plusieurs threads en même temps (l'un des objectifs étant de mieux utiliser le matériel multi-coeur). Je n'ai pas trop compris ce que tu entendais par :

Citation:

des opérations à opérandes multiples
16/04/2009, 21h20
Matthieu Brucher

Sans doute SIMD.
22/04/2009, 16h27
JulienDuSud

Citation:

Envoyé par JolyLoic

En l'occurrence, c'est le fait d'exécuter du code dans plusieurs threads en même temps (l'un des objectifs étant de mieux utiliser le matériel multi-coeur). Je n'ai pas trop compris ce que tu entendais par :

Ou en d'autres mots une possibilité pour les applications mono-thread d'utiliser plusieurs coeurs à la fois ?
22/04/2009, 18h17
Matthieu Brucher

Citation:

Envoyé par JulienDuSud

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

Si c'est mono-thread, il n'est pas possible d'utiliser plusieurs coeurs.
23/04/2009, 11h16
JulienDuSud

Citation:

Envoyé par Matthieu Brucher

Si c'est mono-thread, il n'est pas possible d'utiliser plusieurs coeurs.

Ok, j'ai mal compris le message de JolyLoic alors...

Je pensais qu'il y avait du nouveau sur la manière dont les CPU allaient gérer les threads unique, dans le sens où plusieurs coeurs pourraient se partager le calcul d'un même calcul en factorisant à droite et à gauche par exemple :aie:
23/04/2009, 11h29
camboui
Citation:

Envoyé par Matthieu Brucher

Sans doute SIMD.

Oui, c'est bien ça.

Citation:

Envoyé par Matthieu Brucher

Si c'est mono-thread, il n'est pas possible d'utiliser plusieurs coeurs.

Ah, pourtant j'y verrais bien une extension du langage pouvant le permettre.
En fait l'application serait mono-thread du point ce vue du programmeur, certainement multithread en pratique mais se serait au compilateur de le gérer.
Via une syntaxe de ce genre par exemple:
Code:

1 2 3 4 5 6 7 8 concurrent { ...//code } concurrent { ...//code }
Les blocs consécutifs de code précédés du mot clé concurrent pourrait s'éxecuter indépendemment les uns des autres, et donc aussi en parallèle. Le programmeur n'aurait pas à créer/gérer lui-même les threads éventuels.
23/04/2009, 12h50
Matthieu Brucher
Citation:
Envoyé par camboui

Via une syntaxe de ce genre par exemple:

Code:

1 2 3 4 5 6 7 8 concurrent { ...//code } concurrent { ...//code }

Les blocs consécutifs de code précédés du mot clé concurrent pourrait s'éxecuter indépendemment les uns des autres, et donc aussi en parallèle. Le programmeur n'aurait pas à créer/gérer lui-même les threads éventuels.
Ca s'appelle OpenMP ton truc, non ;) ?
23/04/2009, 14h10
camboui

Ah ? Ch'ais pas :oops:

Je me rappelais juste il y a plus de 20 ans, quand on me parlait de programmation parallèle à l'école, que le pascal proposait les mots clés COBEGIN et COEND en plus des BEGIN et END pour permettre l'éxecution parallèle de blocs de code.
23/04/2009, 15h17
Matthieu Brucher

OpenMP permet de faire grosso modo ça. Certains compilateurs ont leur propres extensions, mais ça se base sur les mêmes outils derrière.
23/04/2009, 16h05
3DArchi

Citation:

Envoyé par Matthieu Brucher

OpenMP permet de faire grosso modo ça. Certains compilateurs ont leur propres extensions, mais ça se base sur les mêmes outils derrière.

Et ça correspond à la création d'un thread (au sens OS du terme) ou il y a un autre mécanisme derrière ?
23/04/2009, 16h34
Matthieu Brucher

Citation:

Envoyé par 3DArchi

Et ça correspond à la création d'un thread (au sens OS du terme) ou il y a un autre mécanisme derrière ?

Oui, c'est du pthread par exemple sous Linux.
23/04/2009, 17h39
3DArchi

Citation:

Envoyé par Matthieu Brucher

Oui, c'est du pthread par exemple sous Linux.

Ca veut dire qu'on peut utiliser toute l'artillerie des threads (mutex, lock et compagnie) ?
23/04/2009, 18h08
Matthieu Brucher

Non, c'est encapsulé, mais c'est disponible sous une autre forme.
23/04/2009, 18h09
3DArchi

Alors question bête : à quoi servent les librairies de parallélisation ? A faciliter l'écriture des threads ?
23/04/2009, 18h10
Matthieu Brucher

Citation:

Envoyé par 3DArchi

Alors question bête : à quoi servent les librairies de parallélisation ? A faciliter l'écriture des threads ?

Exactement. Tu ne t'occupes pas du nombre de thread, de leur création et destruction, ... Et c'est disponible en C/C++ et Fortran.
23/04/2009, 18h14
3DArchi

Bêtement, je pensais qu'il y avait plus de subtilité...
24/04/2009, 08h19
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.
24/04/2009, 09h37
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) ?
24/04/2009, 09h43
Matthieu Brucher

Citation:

Envoyé par 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.

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.
24/04/2009, 11h37
Alp

Citation:

Envoyé par 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.

Ca s'est bien passé ? ;)
24/04/2009, 12h07
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.
24/04/2009, 12h22
Matthieu Brucher

Citation:

Envoyé par 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.

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).
24/04/2009, 12h26
Médinoc

C'est possible. Pour l'affinité, c'était une supposition (qui me paraissait logique)
24/04/2009, 20h30
JolyLoic

Citation:

Envoyé par 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.

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

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.

Citation:

Envoyé par Matthieu Brucher

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:

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 Alp

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. :sm:
24/04/2009, 20h33
Matthieu Brucher

Citation:

Envoyé par JolyLoic

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).
24/04/2009, 20h51
Alp

Citation:

Envoyé par JolyLoic

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

:aie:
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).
24/04/2009, 20h53
Matthieu Brucher

Citation:

Envoyé par Alp

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, ...
27/05/2009, 16h19
Mat.M

Citation:

Envoyé par JulienDuSud

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.
27/05/2009, 16h28
Mat.M

Citation:

Envoyé par 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.

Absolument c'est indiqué dans la FAQ de TBB

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.