Sans hésitation: C#
C
C++
Java
Lisp
Scala
F#
D
Haskell
Ruby
C#
Python
Erlang
Ada
MATLAB
Fortran
occam
Autre
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
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é.
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...
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...
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.
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
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.
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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager