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ï

[Thierry Chappuis]

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ï

Merci beaucoup !

Thierry

[bredelet]

Pour le C il y a MPI

Pour ML il y a JoCaml et Alice ML

Sinon moi je m'interesserais a Java (ou les autres langages de la JVM) ou Objective-C...

[jmnicolas]

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 !

Un petit extrait :

Many technologists are pushing for increased use of multithreading in software in order to take advantage of the predicted increases in parallelism in computer architectures. In this paper, I argue that this is not a good idea. Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism.

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

[dapounet]

Et voilà l'avis de Donald Knuth :

To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the "Itanium" approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write.

Let me put it this way: During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. Surely, for example, multiple processors are no help to TeX.

http://www.informit.com/articles/art...=1193856&rll=1

[bredelet]

Et il y a une reponse? Car ceci me semble une idiotie

Surely, for example, multiple processors are no help to TeX.

[etdmi3]

salut à tous,
je suis en train de faire un exposé à propos des systèmes multicore et je m'intéresse à cette nouvelle technologie .
Voulez vous me préciser les raisons pour lesquelles est apparue ,quelles sont ses limites et comment cette technologie est vue dans le marché.
Je serais reconnaissante si vous me procurez des documents.
merci d'avance

[Garulfo]

salut à tous,
je suis en train de faire un exposé à propos des systèmes multicore et je m'intéresse à cette nouvelle technologie .
Voulez vous me préciser les raisons pour lesquelles est apparue ,quelles sont ses limites et comment cette technologie est vue dans le marché.
Je serais reconnaissante si vous me procurez des documents.
merci d'avance

Non…

C'est un exposé que tu fais. C'est donc un travail de recherche que tu dois faire. Si on te les donne, c'est nous qui le faisons.

Tu trouveras sans peine de l'aide sur Wikipedia et à partir de là, des liens vers d'autres ressources.

[InOCamlWeTrust]

Je suis d'accord avec Garulfo. Tu trouveras toute la documentation à ce sujet sur le site d'Intel.

Si ton niveau ne dépasse pas celui du BAC, je crois que tu te rendras vite compte que ton sujet est bidon, essentiellement à cause du fait qu'il n'existe pas un seul modèle multi-processeur, mais des dizaines, voire des centaines. De plus les industriels distilent très peu d'informations quant à leurs processeurs. Les seules informations réellement disponibles sont celles utiles aux concepteurs des OS, et concernent dans 99% des cas les façons de tirer un peu parti de leurs fonctionnalités... du genre des trucs aussi bandants que le numéro de bit à allumer dans un registre dont personne ne soupçonne l'existence qui permettra en mode superviseur d'activer une super-fonctionnalité donnant droit pour les trois prochaines instructions à un super-pouvoir conditionné à une condition conditionnelle portant sur les 53ème bit en haut à gauche du registre FPXA34G.

Bon, voilà : si tu veux endormir ton auditoire ou le faire fuir, c'est ce qu'il faut faire.

Bref, si aujourd'hui parler des multi-processeurs entre personnes un peu aware of that kind of things est un peu comme entendre des biologistes parler de relativité générale ou de mécanique quantique, le faire dans un exposé, c'est comme débattre du sexe des anges... une conversation de bistrot, quoi !

Quant aux limitations techniques, il n'y a rien à faire : ces choses-là sont faites pour faire tourner plusieurs programmes en même temps, et non un seul programme plus rapidement. En clair, il n'y a aucun avantage à en tirer en ce qui concerne un seul programme, à moins que ce programme puisse se diviser en tâches totalement séparables et distinctes.

[etdmi3]

Merci pour votre aide mais ce n'est qu'une introduction pour un sujet de PFE

[Furikawari]

Et il y a une reponse? Car ceci me semble une idiotie

Bon, déjà dire que Knuth a dit une idotie ...

Au passage Knuth est aussi le créateur de TeX.

Je le trouve plutôt extrémiste dans ses propos sur le parallélisme/multithreading. Dans le cas de TeX, il est clair que le processing semble très linéaire. Cela dit, s'il y a un découpage en section on peut parfaitement distribuer le processing de chaque section (avec quand même quelques questions comme les références en dehors la section).

[millie]

Je le trouve plutôt extrémiste dans ses propos sur le parallélisme/multithreading. Dans le cas de TeX, il est clair que le processing semble très linéaire. Cela dit, s'il y a un découpage en section on peut parfaitement distribuer le processing de chaque section (avec quand même quelques questions comme les références en dehors la section).

Le gros du traitement, c'est la mise en page sur le pdf/ps/dvi. Et il faut avoir traiter les sections précédentes pour savoir placer les nouvelles sections.

EDIT : Pour les chapitres, il pourrait y avoir des astuces, mais cela demanderait quand même de reconstruire une bonne partie à la fin.

[souviron34]

..
Je le trouve plutôt extrémiste dans ses propos sur le parallélisme/multithreading.

Moi non

En fait, à part quelques cas, mon opinion (qui ne vaut que ce qu'elle vaut) est que c'est une mode, mais néfaste car elle s'imbrique partout, et surtout dans les têtes....

En ce qui concerne le multi-core, le problème est différent. Un calcul répétitif, en boucle, avec des sous-éléments indépendants, peut largement profiter d'un multi-core (et effectivement, quelque chose comme MPI est largement utilisé dans le domaine industriel). Si les besoins de synchronisation sont réduits par rapport au nombre de calculs indépendants, il est certain que l'on y gagne (j'ai vu des codes de calcul de modélisation météo gagner un facteur 3.2 en passant de 1 à 4 core).


Cependant, à part de très rares cas, le multi-threading est (me semble) inefficace.

1. Primo, un processeur ne traite qu'une chose à la fois, donc, pour toute appli tournant sur un seul processeur, justifier les threads en parlant d'accélération est du pur "whishful thinking".
2. Secondo, comme le mentionne Knuth, il y a peu d'applications demandant réellement un parallèlisme, ou alors les demandes sont trop nombreuses (N clients à traiter simultanément, N > 1000, ce qui est le cas des applications Web ou serveur, par exemple) pour que cela soit solutionné par du multi-threading.
3. Tertio, la complexité impliquée dans les programmes fait considérablement baisser la maintenabilité ou la vision d'ensemble.
4. Quarto, la "mode" et l'imbrication de cette notion au premier rang dans les pensées actuelles entraînent une "paresse" intellectuelle en ce qui concerne l'otpimisation, l'algorithmie, et enfin la réalité, le but et l'usage de l'application concernée.
5. Et enfin Cinquo, il me semble que le développement de cette pensée est principalement dû aux personnes arrivant du monde M$, où le traitement asynchrone des événements (voir les sockets asynchrones) est inexistant (cela existe, mais pas en sous-couche indépendante), alors que c'est la base des autres OS (unixoides en tête).

Mais ce n'est que mon humble opinion....