Discussion :

[jacques antoine]

Sans hésitation: C#

[Invité]

Bon, autant vous dire franchement ce que je pense : je suis choqué qu'on pense encore à du C pour faire du parallèle

Je vois deux avantages au C (conception et éxecution) :

1. En C natif (conçu et réalisé en C sans aucun portage ou méthode d'analyse polluante) on peut écrire un petit kernel multitâche robuste en une 40aine de lignes. C'est dû à l'omniprésence des pointeurs natifs qui pointent aussi bien sur le code que sur les données. Attention car ce type de code est vraiment dur à lire mais cela marche tellement bien qu'il n'est jamais nécessaire de le maintenir. De nombreux jeux ont exploité cette possibilité il y a une dizaine d'années. Aujourd'hui on veut faire le contraire et confier tout traitement parallèle au compilateur, pourtant cette possibilité en dit long sur le degré d'optimisation qu'on peut atteindre en C natif.

2. L'absence de garbage collection et l'agencement du segment de données ne bloquent pas le partage des données entre threads. Je n'ignore pas que cela peut provoquer des erreurs monstrueuses mais si c'est bien programmé, on oublie les files d'attentes, les boucles d'évenements, sans parler des delegates et autres joyeusetés qui servent à étendre la visibilité d'un code à d'autres threads.


Je suis parfaitement conscient que cette approche n'a rien de didactique : aucune facilité aucun confort de programmation mais en embarqué, c'est parfois le seul moyen.

Le corollaire est que la conception à ce niveau est tellement critique qu'il vaut mieux utiliser des plateformes de simulation pour faire la conception. Les autres langages (surtout la garbage collection) sont tellement différents qu'ils ne sont pas vraiment utiles.

Donc , dans le topic, il vaut mieux parler en bien de ce qu'on connait bien : si on dit que ce qu'on ne connait pas est mauvais, on a presque toujours tort (mais c'est humain et parfois commercialement nécessaire)


Personnellement j'ai complètement arrêté de faire du C ultra optimisé car plus personne ne me le demande... Mais dire que c'est impossible est inexact

[barbudor]

Occam !

Langage conçu spécialement pour la programmation // où justement tu n'as pas a te pré-occuper où et comment cela s'exécute.
Le même programme peut s'exécuter sur un processeur avec un coeur, ou sur un réseau de 100 ou 1000 processeurs de la même manière.

Le Transputer était un processeur conçu dans la fin des années 80 exprès pour exécuter du code Occam. Il disposait d'un ordonnanceur cablé au niveau de la puce et des liaisons de communication inter-procésseur.
Dans le code Occam, on utilisait de manière transparent des "pipe" de communication qui pouvait être soit entre des threads s'exécutant sur un même processeur soit des threads sur des processeurs distant et l'ensemble prenait en charge cela de manière entièrement transparente.

J'avais fait pas mal de traitement d'image la dessus à l'époque. C'est bien adapté.

[Invité]

C / Objective-C avec Grand Central Dispatch ( libdispatch, Open Source ), c'est le pied. C'est efficace et simple à aborder.

Sinon, toujours en C, j'ai testé OpenCL : c'est plus complexe à aborder, mais aussi très efficace.

J'ai cherché dans tout le topic pour trouver un post qui en parle.

C'est étonnant que ni OpenCL ni CUDA soient proposés dans la liste ni abordés car le facteur performance est en totale rupture avec les langages classiques.
J'ai essayé de proposer une migration OpenCL l'année dernière sans succès, je l'ai abandonné. Mais depuis, Intel a mis à jour son driver et toutes les cartes (Radeon geForce) sont désormais compatibles même sur portables.

S'il y a un langage qui pulvérise tous les autres , c'est bien celui là puisqu'il peut mettre 2 teraflops dans un PC.. Pourtant les implémentations sont encore rares et je ne sais pas ce que ça vaut dans un programme qui n'est pas basé sur le calcul (traitement de signal dans mon cas)

OpenCL peut il acceder à une base SQL ? Gerer un protocole de flux ? .. je l'ignore, mais il fait de belles transformées de Fourier en 3D environ 50 fois plus vite qu'un core 2 duo à 3ghz , je n'en sais pas plus...

[dourouc05]

OpenCL peut il acceder à une base SQL ? Gerer un protocole de flux ? .. je l'ignore, mais il fait de belles transformées de Fourier en 3D environ 50 fois plus vite qu'un core 2 duo à 3ghz , je n'en sais pas plus...

Un GPU peut te faire des calculs très rapidement tant qu'il s'agit de calcul parallèle pur et dur, pas trop d'embranchements notamment.

Accéder à une base de données n'est pas encore possible, il faut transférer les données que tu reçois sur le CPU au bon endroit sur le GPU pour traitement. À noter que certains moteurs de base de données commencent à utiliser les GPU ; à part ces exceptions, ce n'est pas vraiment possible sans trop refaire soi-même...

[Gouyon]

Un GPU peut te faire des calculs très rapidement tant qu'il s'agit de calcul parallèle pur et dur, pas trop d'embranchements notamment.

Effectivement chez nous on utilise les GPU pour faire des calculs temps réels sur des images vidéo et c'est impressionnant. Par contre ça ne marche pas pour tout et c'est très délicat à programmer (aux dires de mes collègues)

Pour répondre à la question j'ai commencé la programmation parallèle avec du C++ puis du pascal. Je ne connais pas tous les langages cités mais ce que j'ai constaté c'est que soit on veut quelque chose de très performant et il faut mettre les mains dans le cambouis et oublier la portabilité (sauf sur une machine identique) et bonjour la maintenance du code. Soit on peut se contenter de quelque chose de moins pointu mais qui sera plus facile à programmer. Il existe des utilitaires qui permettent de paralléliser ça peut suffire et l'application est plus facile à maintenir.

[chaplin]

Ouais, j'évalue le "pas assez" à moins de 0,1% justement (dommage que personne n'ait pris le risque de répondre). Et non, je ne pense pas que comprendre le modèle mémoire relaxé du x86 soit un concept fondamental pour pouvoir appréhender la programmation parallèle, justement parce qu'il y a des modèle bien meilleurs que la mémoire partagé (genre le passage de message*). Et heureusement, vu la complexité incroyable de la chose (et le fait que ça change d'un proc à l'autre. Genre un algo qui marche sur x86 échouera lamentablement sur powerPC).

*: C'est l'approche utilisée dans Erlang, qui a motivé son concepteur a créé plus exactement ce langage.

[sekaijin]

je ne pense pas qu'il y ait de modèle meilleur qu'un autre en soit

je pense qu'un modèle est plus adapté à une situation

si je prends des extrêmes j'ai d'un côté des chose comme le calcul de contour par moyenne pondère
ou si j'ai un cpu par point de mon image que que chacun fait la moyenne pondéré des valeur voisine (immédiates)
le modèle de programmation est particulièrement efficace. tout les cpu (gpu) font le même calcul sur des valeurs locales
à l'opposé j'ai un système multi agent dont le but est de résoudre un pb d'IA complexe par la collaborations. dans ce cas la chaque agent à un algo qui lui est propre et les échanges de messages sont la base du fonctionnement. on est loin du pb de l'image et de ses contours.

pour moi il n'y a pas donc de meilleur mais selon le cas un modèle plus adapté qu'un autre.
je ne vois d'ailleurs rien qui empêche de mixer les approches.

A+JYT

[alex.buisson]

J'ai mené à bien des projets nécessitant tous les langages cités précédement avec les avantages et inconvéniants que vous avez tous très bien mis en avant. Cependant, comme vous l'avez fait remarqué les programmeurs ayant une "réelle" connaissance et maitrise de leur machine sont rare, et donc l'approche haut niveau et très souvent ce que je recommande aux débutants qui me demande comment accélérer certaines fonctions.

Mais plus qu'une approche par language, je leur demande d'abord de comprendre comment leur calcul peut être formulé de manière concurrent et ensuite le plus souvent via du OpenMP en C++ on introduit le //isme.

Ca permet de valider le modèle rapidement. OpenMP est souvent remplacé pour le code de production car bcp trop sensible à des perturabations extérieurs (var d'environnements, etc...).

En bref, pour bien exploter le //isme, il faut d'abord comprendre les paradigmes sous-jacents.

[Invité]

OpenMB, OpenCL, Haskell, Erlang.

Simplement car ils sont fait pour ça et ça se ressent. Fini l'époque où je faisais ça en C,C++ ou Java, et passait 99% du temps du projet à régler les problèmes de synchronisation. Préférence pour Erlang dans la liste.

D'ailleurs avis perso : le modèle acteur va revenir en force.

[hunter_fast]

C#