Discussion :

[JeromeBcx]

Effectivement, l'emploi d'un GPU peut dans certains contextes, faire vraiment la différence. Mais il faut tout réécrire, on est beaucoup trop dépendant du matériel, cela demande des compétences spécifiques (je doute que le commun mortel des programmeurs peuvent se lancer là dedans...)

Le compilateur Intel n'est certes pas donné, mais n'est pas non plus exorbitant. Il permet (bien sûr dans certains cas) de réaliser de nettes améliorations dans les temps d'exécution sans nécessiter un travail d'optimisation de code lourd qui souvent n'est pas parfait voir inutile.

Il faut se dire qu'une optimisation peut facilement prendre plus de 15 jours... A partir de là, on se rend compte que le coût du compilateur est ridicule s'il réussit à optimiser lui même le code par rapport au temps passé et au salaire du développeur.

Alors franchement, je doute que l'utilisation d'un GPU soit moins cher (en terme de coût pour l'entreprise) : tu n'as l'air de ne faire référence qu'au prix de la carte, c'est un peu limitant dans le calcul du coût. Il faut ajouter le temps passé, le niveau du développeur, ....
Donc pour moi : compilateur performant = petite optimisation à "pas cher"
GPU = grosse optimisation mais "très cher"
Après, tout dépend du projet et de ce que l'on veut

Ca dépend de ce que tu appelles automatisme.

j'entendais par là réflexe automatique du programmeur à écrire un code performant. Mais je vais dans ton sens : à mon avis, ce genre "d'optimisation" n'apporte pas grand chose.

[HanLee]

Effectivement, l'emploi d'un GPU peut dans certains contextes, faire vraiment la différence. Mais il faut tout réécrire, on est beaucoup trop dépendant du matériel, cela demande des compétences spécifiques (je doute que le commun mortel des programmeurs peuvent se lancer là dedans...).

A part les limitations (surement temporaires) précédentes, je crois que tu ne te rends pas compte de ce que tu dis, par rapport à CUDA.

Justement, CUDA, c'est le calcul massivement parallèle pour les masses, les gueux, le peuple.
Le code sur GPU avec CUDA, c'est littéralement du C, avec quelques mots clés spécifiques.
En un après midi tu t'adaptes.

Les testeurs d'Hardware.fr ont réussi à réécrire leur pacman assez facilement.

Tu peux continuer à écrire du code C++ templatisée, tu lances le code qui fait appel au GPU avec une syntaxe spéciale. Le compilateur s'occupe de faire le tri entre ce qui est code GPU, et code CPU. Il appelle le bon compilateur C++ et le compilateur GPU ensuite, et c'est tout.

[Matthieu Brucher]

A part les limitations (surement temporaires) précédentes, je crois que tu ne te rends pas compte de ce que tu dis, par rapport à CUDA.

J'en ai fait dans une formation avec des gars qui avaient l'habitude de programmer en C ou en C++. Beaucoup étaient à la ramasse. Donc je pense plus que c'est toi qui ne réalises pas les implications de l'utilisation de CUDA en terme d'architecture matérielle bien différente.
Quand tu en auras fait, pense à ceux qui ont déjà du mal à utiliser correctement l'architecture x86 et qui ne comprendront même pas l'architecture GPU.

[HanLee]

J'en ai fait dans une formation avec des gars qui avaient l'habitude de programmer en C ou en C++. Beaucoup étaient à la ramasse. Donc je pense plus que c'est toi qui ne réalises pas les implications de l'utilisation de CUDA en terme d'architecture matérielle bien différente.
Quand tu en auras fait, pense à ceux qui ont déjà du mal à utiliser correctement l'architecture x86 et qui ne comprendront même pas l'architecture GPU.

Ben, justement j'en fais là, et mon tuteur en fait aussi en même temps, on apprend tous les deux sur le tas, on s'en sort bien.

J'ai exagéré sur la simplicité, mais c'était pour insister sur le fait que c'était pas un saut si différent que ça.

[JeromeBcx]

A part les limitations (surement temporaires) précédentes, je crois que tu ne te rends pas compte de ce que tu dis, par rapport à CUDA.

Je suis d'accord, il y a des progrès dans ce sens très rapide,et bien que cela soit peut être encore trop récent, il y a beaucoup à faire et à moyen/long terme, cela devrait devenir très intéressant d'investir dans l'utilisation des GPU. Mais non, désolé, cela reste plus cher que d'utiliser un compilateur performant commercial, et franchement je ne me lancerais pas encore là dedans.
Cela reste un investissement lourd pour un labo et une entreprise. La discussion a été ouverte pour savoir si cela vaut la peine d'investir dans le compilateur Intel : cela représente un investissement de quelques milliers d'euros. Le basculement vers l'emploi de GPU demande beaucoup plus que ça. C'est tout ce que je voulais dire. Je te laisse faire le calcul du retour sur investissement

[JeromeBcx]

Je reprends un peu mon post précédent.... (j'y suis allez un peu fort)
Non, c'est clair, l'utilisation des GPU pour les calculs lourds et massivement parallélisable est une solution plus que prometteuse et relativement faible cout coté matériel (une GForce8 vs un cluster de 100PC !!!)

Mais le fait pour une entreprise de faire le pas vers cette technologie reste délicat, du moins en ce moment, parce que les choses bougent très vite et il y a beaucoup de monde en course pour l'emploi des multi-coeurs :
- la solution NVIDIA - CUDA, avec une API haut niveau
- la solution AMD et Close To Metal (un peu à la traine et moins accessible = programmation bas niveau)
- Intel et Larrabee,
- Apple et OpenCL (NB : équivalent de OpenGL pour le calcul massivement par parallèle)
Ce n'est pas évident pour une entreprise de choisir telle ou telle autre techno en ce moment.

C'est pour toute ces raisons que je m'opposais à ta proposition, et non sur la technologie de l'emploi des GPU, surtout par rapport au choix d'investir dans un compilateur C++ tel que celui d'Intel