Discussion :

[JolyLoic]

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 ?

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

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[camboui]

Que regroupe la notion de "parallélisme" ?
-du multithreading
-des opérations à opérandes multiples
quoi d'autre ?

[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 :

des opérations à opérandes multiples

[Matthieu Brucher]

Sans doute SIMD.

[JulienDuSud]

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 ?

[Matthieu Brucher]

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.

[JulienDuSud]

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

[camboui]

Sans doute SIMD.

Oui, c'est bien ça.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Matthieu Brucher]

Via une syntaxe de ce genre par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[camboui]

Ah ? Ch'ais pas

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.

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

[3DArchi]

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 ?

[Matthieu Brucher]

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.

[3DArchi]

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

[Matthieu Brucher]

Non, c'est encapsulé, mais c'est disponible sous une autre forme.

[3DArchi]

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

[Matthieu Brucher]

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.