Nouveaux langages pour la programmation des processeurs multicoeurs

La question :

Quelqu'un connaît-il et/ou a-t-il déjà utilisé des langages tels que
Chapel ou X10 pour la programmation du parallélisme et plus
particulièrement, la programmation des processeurs multicoeurs ?

Poser votre question sur le forum Programmation

Les 34 réponses :

On 13 juin, 12:03, Wykaaa <wyk...@yahoo.fr> a écrit :


Quelqu'un connaît-il et/ou a-t-il déjà utilisé des langages tels que
Chapel ou X10 pour la programmation du parallélisme et plus
particulièrement, la programmation des processeurs multicoeurs ?


Pourquoi réinventer un nouveau langage. Ceux (Ada ou java par
exemple) qui exploitent les architectures multiprocesseurs sont
portables sur les multi coeurs. J'ai recompilé un programme Ada qui
exploitait le parallélisme d'une machine SGI irix à 12 processeurs sur
une machine linux avec un processeur à huit coeurs sans rien changer.

a écrit :


On 13 juin, 12:03, Wykaaa <wyk...@yahoo.fr> a écrit :


Quelqu'un connaît-il et/ou a-t-il déjà utilisé des langages tels que
Chapel ou X10 pour la programmation du parallélisme et plus
particulièrement, la programmation des processeurs multicoeurs ?


Pourquoi réinventer un nouveau langage. Ceux (Ada ou java par
exemple) qui exploitent les architectures multiprocesseurs sont
portables sur les multi coeurs. J'ai recompilé un programme Ada qui
exploitait le parallélisme d'une machine SGI irix à 12 processeurs sur
une machine linux avec un processeur à huit coeurs sans rien changer.


Ok mais es-tu sûr que le logiciel exploite au mieux les huit coeurs ?
Si ces langages nouveaux existent pour ces architectures
multiprocesseurs/multicoeurs, il doit bien y avoir une raison.

On Jun 14, 9:37 pm, Wykaaa <wyk...@yahoo.fr> a écrit :


cjpsi...@gmail.com a écrit :> On 13 juin, 12:03, Wykaaa <wyk...@yahoo.fr> a écrit :


Quelqu'un connaît-il et/ou a-t-il déjà utilisé des langages tels que
Chapel ou X10 pour la programmation du parallélisme et plus
particulièrement, la programmation des processeurs multicoeurs ?



Pourquoi réinventer un nouveau langage. Ceux (Ada ou  java par
exemple) qui exploitent les architectures multiprocesseurs sont
portables sur les multi coeurs. J'ai recompilé un programme Ada qui
exploitait le parallélisme d'une machine SGI irix à 12 processeurs sur
une machine linux avec un processeur à huit coeurs sans rien changer.


Ok mais es-tu sûr que le logiciel exploite au mieux les huit coeurs ?
Si ces langages nouveaux existent pour ces architectures
multiprocesseurs/multicoeurs, il doit bien y avoir une raison.


Il y a un article de Robert Dewar : http://www.adaic.org/whyada/multicore.html
sur le sujet.

Pour ma part, je suis incapable de dire si on peut faire mieux ou non.
Ce que je sais pour l'avoir vérifié, c'est que les huits coeurs
étaient utilisés à 100%. Je n'ai pas eu le temps de faire les
benchmarks que j'avais fait à l'époque sur SGI.

Je ne suis pas spécialiste mais seulement utilisateur et j'ai eu
plusieurs applications à paralléliser. Dont une en fortran.
Pour celle là après avoir lorgné sur MPI et openMP, j'ai utilisé une
petite blibliothèque écrite en Ada qui permettait de lancer des appels
à des routines fortran dans des tâches Ada. Le résultat a été que
seulement 20 lignes du code fortran ont été modifiées pour un gains
atteignant 98% du parallélisme théorique. Ce qui fait 2% d'overhead.
Je n'ai pas poussé plus loin car j'avais atteint mon but et je n'avais
pas de budjet pour autre chose. J'aurais aimé explorer le super
linéaire.

Pour ce qui est de la création de nouveaux langages je crois qu'il y a
et aura toujours des gens pour réinventer la roue. Et le parallélisme
est une belle roue. Je leur conseillerais de s'intéresser à Ada car il
pourront y trouver des enseignements importants, notamment comment
gérer les exceptions dans un contexte multi-tâche. Ou encore quelles
sont les difficultés pour faire de l'optimisation d'une application
multi coeur, pour le compilateur mais aussi pour le programmeur, par
exemple gérer les problèmes de localisation des données dans les
câches. Etc... Les concepteurs d'Ada ont travaillé là dessus depuis
1980.

Ne pas oublier que le langage, son compilateur et le run-time sont
dépendants de l'OS et du hardware. Le multi-threading doit être
correctement implanté dans le système d'exploitation. Il se pose aussi
le problème du placement des threads soit de manière autoritaire sur
une plate-forme dédiée à l'application soit par affinité sur un
serveur partagé.

<Mode_dithyrambe>
L'avantage d'Ada de mon point de vue est que c'est un langage
généraliste très complet qui a évolué au cours de ses révisions
successives pour intégrer des nouveautés (programmation objet,
distribution, bibliothèques mathématiques, conteneurs, objet protégé,
interface à la java...) en les intégrant dans les traits adoptés dés
le départ (généricité, tasking, modularité, typage fort, exceptions,
interfaçage avec d'autres langages, accès au bas niveau...) tout en
gardant une compatibilité ascendante remarquable.
</Mode_dithyrambe>

Bien sûr, j'aimerais bien lui ajouter quelques nouveautés moi aussi
(par exemple : équation aux dimension et unités, boucle parallèle,
tranche de tableau multidimensionnel, extension d'énumérés...), mais
je ne vais pas définir un nouveau langage de programmation à empiler
sur la tour de Babel.

Aucun langage n'est le dernier langage. Mais avant d'entreprendre la
définition d'un nouveau langage le minimum est de regarder ce qui
existe et ce qu'il convient de modifier ou d'améliorer plutôt que
repartir de zéro. Si le but est seulement de faire du parallélisme sur
machine multi-coeur on aura un langage incomplet. Pour le moment tout
ce que j'ai vu sur le sujet (je mets de côté le parallélisme massif et
les architectures dédiées) me parait en retard d'une génération.

a écrit :


On Jun 14, 9:37 pm, Wykaaa <wyk...@yahoo.fr> a écrit :


cjpsi...@gmail.com a écrit :> On 13 juin, 12:03, Wykaaa <wyk...@yahoo.fr> a écrit :


Quelqu'un connaît-il et/ou a-t-il déjà utilisé des langages tels que
Chapel ou X10 pour la programmation du parallélisme et plus
particulièrement, la programmation des processeurs multicoeurs ?
Pourquoi réinventer un nouveau langage. Ceux (Ada ou java par
exemple) qui exploitent les architectures multiprocesseurs sont
portables sur les multi coeurs. J'ai recompilé un programme Ada qui
exploitait le parallélisme d'une machine SGI irix à 12 processeurs sur
une machine linux avec un processeur à huit coeurs sans rien changer.


Ok mais es-tu sûr que le logiciel exploite au mieux les huit coeurs ?
Si ces langages nouveaux existent pour ces architectures
multiprocesseurs/multicoeurs, il doit bien y avoir une raison.


Il y a un article de Robert Dewar : http://www.adaic.org/whyada/multicore.html
sur le sujet.

Pour ma part, je suis incapable de dire si on peut faire mieux ou non.
Ce que je sais pour l'avoir vérifié, c'est que les huits coeurs
étaient utilisés à 100%. Je n'ai pas eu le temps de faire les
benchmarks que j'avais fait à l'époque sur SGI.

Je ne suis pas spécialiste mais seulement utilisateur et j'ai eu
plusieurs applications à paralléliser. Dont une en fortran.
Pour celle là après avoir lorgné sur MPI et openMP, j'ai utilisé une
petite blibliothèque écrite en Ada qui permettait de lancer des appels
à des routines fortran dans des tâches Ada. Le résultat a été que
seulement 20 lignes du code fortran ont été modifiées pour un gains
atteignant 98% du parallélisme théorique. Ce qui fait 2% d'overhead.
Je n'ai pas poussé plus loin car j'avais atteint mon but et je n'avais
pas de budjet pour autre chose. J'aurais aimé explorer le super
linéaire.

Pour ce qui est de la création de nouveaux langages je crois qu'il y a
et aura toujours des gens pour réinventer la roue. Et le parallélisme
est une belle roue. Je leur conseillerais de s'intéresser à Ada car il
pourront y trouver des enseignements importants, notamment comment
gérer les exceptions dans un contexte multi-tâche. Ou encore quelles
sont les difficultés pour faire de l'optimisation d'une application
multi coeur, pour le compilateur mais aussi pour le programmeur, par
exemple gérer les problèmes de localisation des données dans les
câches. Etc... Les concepteurs d'Ada ont travaillé là dessus depuis
1980.

Ne pas oublier que le langage, son compilateur et le run-time sont
dépendants de l'OS et du hardware. Le multi-threading doit être
correctement implanté dans le système d'exploitation. Il se pose aussi
le problème du placement des threads soit de manière autoritaire sur
une plate-forme dédiée à l'application soit par affinité sur un
serveur partagé.

<Mode_dithyrambe>
L'avantage d'Ada de mon point de vue est que c'est un langage
généraliste très complet qui a évolué au cours de ses révisions
successives pour intégrer des nouveautés (programmation objet,
distribution, bibliothèques mathématiques, conteneurs, objet protégé,
interface à la java...) en les intégrant dans les traits adoptés dés
le départ (généricité, tasking, modularité, typage fort, exceptions,
interfaçage avec d'autres langages, accès au bas niveau...) tout en
gardant une compatibilité ascendante remarquable.
</Mode_dithyrambe>

Bien sûr, j'aimerais bien lui ajouter quelques nouveautés moi aussi
(par exemple : équation aux dimension et unités, boucle parallèle,
tranche de tableau multidimensionnel, extension d'énumérés...), mais
je ne vais pas définir un nouveau langage de programmation à empiler
sur la tour de Babel.

Aucun langage n'est le dernier langage. Mais avant d'entreprendre la
définition d'un nouveau langage le minimum est de regarder ce qui
existe et ce qu'il convient de modifier ou d'améliorer plutôt que
repartir de zéro. Si le but est seulement de faire du parallélisme sur
machine multi-coeur on aura un langage incomplet. Pour le moment tout
ce que j'ai vu sur le sujet (je mets de côté le parallélisme massif et
les architectures dédiées) me parait en retard d'une génération.


Je connais très bien Ada 83 car j'ai trempé dans l'écriture d'un
compilateur. Le multitasking Ada et ses "rendez-vous" n'étaient pas
spécifiés au mieux dans la première mouture de Ada car, sur des machines
incluant les sémaphores au niveau de l'assembleur, il en fallait 2 pour
respecter les spécification Ada.
Cela semble s'être arrangé avec Ada 95 mais j'avoue qu'alors j'étais sur
d'autres domaines.
Je suis d'accord qu'Ada est un bon langage trop méconnu ou, peut-être,
qui "fait peur" aux développeurs car trop contraignant mais, concernant
la gestion des multicoeurs, je ne suis pas certain qu'il soit le plus
adéquat (mais je peux me tromper...).
Peut-être qu'une des solutions pour gérer au mieux le
multithreading/multicoeurs est d'écrire en Ada, générer du bytecode et
le faire exécuter par la dernière JVM de Sun qui gère les threads en natif.
Encore faut-il que la génération Ada -> bytecode soit optimisée pour le
multiprocesseur/multicoeur... ce qui est loin d'être gagné.

On Jun 15, 10:33 am, Wykaaa <wyk...@yahoo.fr> a écrit :


cjpsi...@gmail.com a écrit :



On Jun 14, 9:37 pm, Wykaaa <wyk...@yahoo.fr> a écrit :


cjpsi...@gmail.com a écrit :> On 13 juin, 12:03, Wykaaa <wyk...@yahoo.fr> a écrit :
Quelqu'un connaît-il et/ou a-t-il déjà utilisé des langages tels que
Chapel ou X10 pour la programmation du parallélisme et plus
particulièrement, la programmation des processeurs multicoeurs ?
Pourquoi réinventer un nouveau langage. Ceux (Ada ou  java par
exemple) qui exploitent les architectures multiprocesseurs sont
portables sur les multi coeurs. J'ai recompilé un programme Ada qui
exploitait le parallélisme d'une machine SGI irix à 12 processeurs sur
une machine linux avec un processeur à huit coeurs sans rien changer.
Ok mais es-tu sûr que le logiciel exploite au mieux les huit coeurs ?
Si ces langages nouveaux existent pour ces architectures
multiprocesseurs/multicoeurs, il doit bien y avoir une raison.



Il y a un article de Robert Dewar :http://www.adaic.org/whyada/multicore.html
sur le sujet.



Pour ma part, je suis incapable de dire si on peut faire mieux ou non.
Ce que je sais pour l'avoir vérifié, c'est que les huits coeurs
étaient utilisés à 100%. Je n'ai pas eu le temps de faire les
benchmarks que j'avais fait à l'époque sur SGI.



Je ne suis pas spécialiste mais seulement utilisateur et j'ai eu
plusieurs applications à paralléliser. Dont une en fortran.
Pour celle là après avoir lorgné sur MPI et openMP, j'ai utilisé une
petite blibliothèque écrite en Ada qui permettait de lancer des appels
à des routines fortran dans des tâches Ada. Le résultat a étéque
seulement 20 lignes du code fortran ont été modifiées pour un gains
atteignant 98% du parallélisme théorique. Ce qui fait 2% d'overhead..
Je n'ai pas poussé plus loin car j'avais atteint mon but et je n'avais
pas de budjet pour autre chose. J'aurais aimé explorer le super
linéaire.



Pour ce qui est de la création de nouveaux langages je crois qu'il y a
et aura toujours des gens pour réinventer la roue. Et le parallélisme
est une belle roue. Je leur conseillerais de s'intéresser à Ada caril
pourront y trouver des enseignements importants, notamment comment
gérer les exceptions dans un contexte multi-tâche. Ou encore quelles
sont les difficultés pour faire de l'optimisation d'une application
multi coeur, pour le compilateur mais aussi pour le programmeur, par
exemple gérer les problèmes de localisation des données dans les
câches. Etc... Les concepteurs d'Ada ont travaillé là dessus depuis
1980.



Ne pas oublier que le langage, son compilateur et le run-time sont
dépendants de l'OS et du hardware. Le multi-threading doit être
correctement implanté dans le système d'exploitation. Il se pose aussi
le problème du placement des threads soit de manière autoritaire sur
une plate-forme dédiée à l'application soit par affinité sur un
serveur partagé.



<Mode_dithyrambe>
L'avantage d'Ada de mon point de vue est que c'est un langage
généraliste très complet qui a évolué au cours de ses révisions
successives pour intégrer des nouveautés (programmation objet,
distribution, bibliothèques mathématiques, conteneurs, objet protégé,
interface à la java...) en les intégrant dans les traits adoptés dés
le départ (généricité, tasking, modularité, typage fort, exceptions,
interfaçage avec d'autres langages, accès au bas niveau...) tout en
gardant une compatibilité ascendante remarquable.
</Mode_dithyrambe>



Bien sûr, j'aimerais bien lui ajouter quelques nouveautés moi aussi
(par exemple : équation aux dimension et unités, boucle parallèle,
tranche de tableau multidimensionnel, extension d'énumérés...), mais
je ne vais pas définir un nouveau langage de programmation à empiler
sur la tour de Babel.



Aucun langage n'est le dernier langage. Mais avant d'entreprendre la
définition d'un nouveau langage le minimum est de regarder ce qui
existe et ce qu'il convient de modifier ou d'améliorer plutôt que
repartir de zéro. Si le but est seulement de faire du parallélisme sur
machine multi-coeur on aura un langage incomplet. Pour le moment tout
ce que j'ai vu sur le sujet (je mets de côté le parallélisme massif et
les architectures dédiées) me parait en retard d'une génération..


Je connais très bien Ada 83 car j'ai trempé dans l'écriture d'un
compilateur. Le multitasking Ada et ses "rendez-vous" n'étaient pas
spécifiés au mieux dans la première mouture de Ada car, sur des machines
incluant les sémaphores au niveau de l'assembleur, il en fallait 2 pour
respecter les spécification Ada.
Cela semble s'être arrangé avec Ada 95 mais j'avoue qu'alors j'étais sur
d'autres domaines.
Je suis d'accord qu'Ada est un bon langage trop méconnu ou, peut-être,
qui "fait peur" aux développeurs car trop contraignant mais, concernant
la gestion des multicoeurs, je ne suis pas certain qu'il soit le plus
adéquat (mais je peux me tromper...).
Peut-être qu'une des solutions pour gérer au mieux le
multithreading/multicoeurs est d'écrire en Ada, générer du bytecodeet
le faire exécuter par la dernière JVM de Sun qui gère les threads en natif.
Encore faut-il que la génération Ada -> bytecode soit optimisée pour le
multiprocesseur/multicoeur... ce qui est loin d'être gagné.


La plupart des compilos Ada basent le tasking sur les threads fournis
par l'OS (je suppose que c'est cela que veut dire natif) comme je
suppose la JVM. A l'époque de Ada83 les threads n'existaient pas
encore (je n'en avait pas encore entendu parler en tout cas).

Je ne vois pas en quoi rajouter une couche d'interprétation de
bytecode permettrait d'accélérer le programme.
Les tests que j'ai fait d'un programme Ada utilisant le multi-
processing (à base de multithreading donc) en le portant sur une
machine mono-processeur ont montré un overhead de moins de 2% entre le
programme non parallélisé et le programme parallélisé.

Je pense qu'Ada est une solution beaucoup plus facile à utiliser que
la programmation directe en C ou C++ d'une lib de type pthread. Et je
ne vois pas pourquoi ce serait moins performant. Que les appels à la
lib de thread soient générés par le compilo plutôt qu'écrits à la main
ne change rien en terme de performance. Ou bien j'ai manqué quelque
chose !

De plus j'ai remarqué, lors de mes tests, que l'utilisation
généralisée de la pile que fait Ada permettait de localiser presque
automatiquement les données dans le câche et d'en accélérer l'accès.

Dans mon équipe on a donc élaboré une technique de programmation qui
consistait à recopier une version locale des données dans la procédure
de traitement, des réaliser les calculs et de ne renvoyer les
résultats que si les calculs s'étaient bien déroulés. On gagnait sur
trois tableaux : données locales (pas de synchronisation d'accès), un
mode transactionnel sûr, et la cerise sur le gâteau un gain de
performance non négligeable, tout cela grâce à la recopie des données
et résultats ce qui aurait fait hurler tout programmeur omnubilé par
l'optimisation au niveau code machine.

Si on doit améliorer quelque chose pour le parallélisme de type
multicoeur il vaut mieux, à mon humble avis, améliorer les
bibliothèques de threads. Soit en les optimisant encore et encore soit
en faisant évoluer leur paradigme en parallèle avec une évolution du
hardware. Mais là je suis totalement incompétent. Tout ce que je sais
c'est qu'il y a trois couches qui sont visées par de possibles
évolutions : le langage + compilateur/optimiseur/run-time, l'OS et le
hardware.

Poser votre question sur le forum Programmation

Questions similaires :

Initiation à la programmation

Je viens de le retrouver http://www.codecademy.com/#!/exercises/0 mais c’est en anglais

Pédagogie de la programmation

On 2009-04-29, Michael DOUBEZ wrote: Je ne me souvenais pas du fait que cela avait couté la vie aux soldats US.[/color] [snip] J'ai retrouvé une référence: An Iraqi Scud missile hit Dhahran barracks, leaving 28 dead and 98 wounded. The incoming missile was not...

langages "compatibles"

Mihamina (R12y) Rakotomandimby a écrit : Un equestion est qu'appelle-t-on binder ? Pouvoir appeler directement des fonctions de l'un dans l'autre ? Pouvoir écrire aisément une couche d'interface qui permette de créer et manipuler des objets de l'un dans l'autre, pouvoir nativement hériter et...

Concepts des langages algorithmiques

ulis wrote: Ca veut dire quoi un langage algorithmique ? Un langage permettant de programmer tous les algorithmes? Ce qui signifie qu'il doit permettre de programmer toutes les fonctions effectivement calculables (fonctions calculées par une machine de Turing «qui termine»). Dans ce cas, le...

Programmation par contrainte

tao wrote: La programmation par contrainte a été popularisée, à l'origine, par des langages tels que Prolog (programmation déclarative). La programmation par contrainte permet de résoudre, plus simplement qu'avec une programmation dite impérative, des problèmes de placements (les huit reines,...