Discussion :

[NokyDaOne]

Je ne suis pas sûr que ce post soit au bon endroit mais bon :

j'ai souvent programmé en multi thread sur des processeurs simple core. J'ai maintenant un processeur dual core et souhaiterais programmer dessus en utilisant les << deux >> processeurs.
J'ai un peu lu et vu que le fait d'avoir plusieurs threads qui utilisent une ressource partagée (un peu obligé faut bien que les threads communiquent, sinon ils ne servent presque à rien) empêchait l'utilisation du biprocesseur.

Alors en fait je voudrais savoir vers quel genre de langage, librairie ou autre je devais me tourner pour faire mumuze avec ma machine.

Je précise je suis sous MAC OS X 10.5, et suis prêt à programmer dans n'importe quel style de langage : asm, C, fonctionnel, objet, typé, pas typé (je m'en fous). Donc je voudrais bien avoir vos avis.

Bon ma préférence irait quand même soit sur du fonctionnel (OCaml je t'aime), soit sur de l'asm (il y a qqc de magique qui se passe à chaque fois que je fais de l'asm, c'est une sensation indescriptible mais forte et profonde).

Merci d'avance.

[Jedai]

OCaml n'est pas top côté parallélisme/concurrence. Tu peux tenter ta chance du côté de Haskell cependant. Haskell est encore plus orienté "fonctionnel" que OCaml et nettement plus doté dans le domaine du parallélisme.

J'ai un peu lu et vu que le fait d'avoir plusieurs threads qui utilisent une ressource partagée (un peu obligé faut bien que les threads communiquent, sinon ils ne servent presque à rien) empêchait l'utilisation du biprocesseur.

C'est un peu excessif... Il est simplement vrai que dans le paradigme multithread impératif prédominant, il y a généralement trop de locks et de ressources partagées pour que le potentiel des multicores (surtout des plus de 2 cores) soit bien exploité.

--
Jedaï

[Thierry Chappuis]

Si tu cherches un langage fonctionnel orienté concurrence, tu peux aussi jeter un coup d'oeil à Erlang qui a été conçu pour ça.

Thierry

[NokyDaOne]

Je vous remercie et irait jeter un coup d'œil à ces langages ce soir. Je connaissais déjà Haskell (un tout petit peu pratiqué) et Erlang juste de nom.

[Jedai]

Si tu cherches un langage fonctionnel orienté concurrence, tu peux aussi jeter un coup d'oeil à Erlang qui a été conçu pour ça.

Plutôt qu'orienté "concurrence", je dirais qu'Erlang est orienté "distribué". Haskell a plus de mécanisme pour permettre d'effectuer des calculs en parallèle, tandis que le modèle d'Erlang est plus adapté pour les processus qui peuvent être distribués à des agents indépendants communiquant par messages, s'exécutant sur plusieurs cores ou même sur plusieurs ordinateurs. Chacun des modèles a son domaine de prédilection et tout deux ont leur place.
Il est intéressant de constater que Erlang et Haskell sont tous deux des langages fonctionnels...

--
Jedaï

[Thierry Chappuis]

Plutôt qu'orienté "concurrence", je dirais qu'Erlang est orienté "distribué". Haskell a plus de mécanisme pour permettre d'effectuer des calculs en parallèle, tandis que le modèle d'Erlang est plus adapté pour les processus qui peuvent être distribués à des agents indépendants communiquant par messages, s'exécutant sur plusieurs cores ou même sur plusieurs ordinateurs. Chacun des modèles a son domaine de prédilection et tout deux ont leur place.
Il est intéressant de constater que Erlang et Haskell sont tous deux des langages fonctionnels...

--
Jedaï

Merci pour ces précisions, Jedai.

Au passage, as-tu des références au sujet de Haskell et le parallélisme ?

Thierry

[Jedai]

GHC implémente un modèle de threads qui répartit des threads utilisateurs ultra-léger sur des threads systèmes profitant du multicore.

Pour se faire les dents :
http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/29

Ce qui est utilisé dans cet article est un exemple (très simple) de l'utilisation de stratégies :
http://www.macs.hw.ac.uk/~dsg/gph/pa...trategies.html

Une autre méthode sympathique pour ajouter du parallélisme à moindre coût : Data Parallel Haskell
http://haskell.org/haskellwiki/GHC/D...rallel_Haskell

(DPH est encore assez instable et en progrès, même s'il y a actuellement un projet GSoC pour écrire un moteur physique avec DPH)

Côté concurrence (plutôt que parallélisme), les transactions mémoire logicielles (STM) sont un autre sujet dans lequel Haskell a été pionnier (et dans lequel il conserve certains avantages de sûreté et d'élégance) :
http://research.microsoft.com/Users/.../stm/index.htm

La prochaine version de GHC (cet automne) aura également un GC parallèle ce qui devrait améliorer les performances des codes parallèle allouant généreusement.

--
Jedaï

[bredelet]

Dans cet article [PDF en anglais] l'auteur affirme que les threads tels qu'on les trouve dans les langages impératifs classiques (Java, C++ etc) posent un grand problème de fiabilité.
Il propose d'ailleurs des alternatives comme ADA et Erlang qui sont plus adaptées selon lui.

Perso, je n'ai pas encore le bagage technique suffisant pour me faire une idée, alors je soumets cet article à vos commentaires éclairés !

On parle bien des questions que Noky soulevait:

J'ai un peu lu et vu que le fait d'avoir plusieurs threads qui utilisent une ressource partagée (un peu obligé faut bien que les threads communiquent, sinon ils ne servent presque à rien) empêchait l'utilisation du biprocesseur.

C'est un peu excessif... Il est simplement vrai que dans le paradigme multithread impératif prédominant, il y a généralement trop de locks et de ressources partagées pour que le potentiel des multicores (surtout des plus de 2 cores) soit bien exploité.

--
Jedaï

Le secret est de partager le moins possible, alors il n'y a pas de raison de ne pas utiliser de threads. Ceci dit je pense que le modele de Erlang (processus echangeant des messages) est bien meilleur que celui des threads, mais bon... Et a ce que je sache Ada a les threads aussi.