C'est possible que petit à petit C# prenne quelques parts de marchés sur C++ sur windows, mais ça sera pas le cas sur Android, IOS, Linux, playstation, wii, ...

Par contre en ce moment c'est plutôt Android et IOS qui prennent des parts de marché sur Windows, le marché des PC recule et celui des mobiles explose...

Justement non.
Microsoft est en train de détruire le .Net petit à petit. Silverlight est considéré comme mort, XNA vient d'être annoncé comme final (plus d'évolution) et est donc considéré comme mort aussi, C# va sans doute pâtir de tout ça. C'est con, cet écosystème est quand même assez vivace.

Ouais j'ai pas compris pourquoi ils arrêtaient XNA aussi brutalement, ça avait l'air actif quand même Et à ma connaissance ils proposent pas d'alternatives, c'est bizarre

"CUDA et OpenCL sont pas mal pour le calcul haute performance et sont utilisables en Java ou C#, sans que le langage choisi n'impacte sensiblement les performances. A terme pour les calculs parallélisables, C et C++ risquent de perdre de l'importance."

Le calcul haute performance, c'est plus que l'utilisation de carte graphique. CUDA et OpenCL ca fait que de la carte graphique. C'est un pan du HPC mais c'est pas tout.

Dans l'ensemble, les performance obtenu par les GPUs ne sont pas si interessante. Tu lis souvent des gens qui pipeaute du "regarde j'ai du 150x avec mon GPU" et ca c'est juste faux. En pratique sur des applications autre que faire du rendu graphique ou de l'algebre lineaire dense, les GPUs n'ont pas tant d'importance que ca. Le probleme est que les gens ne savent pas ou ne veulent pas ecrire du bon code pour CPU, et ils optimisent leur code GPU a mort. et du coup, ils sont content quand ils voient un facteur 150. En pratique c'est BEAUCOUP plus faible. Lis le papier: "Debunking the 100X GPU vs. CPU Myth".

Apres le HPC, c'est pas juste du calcul pure sur un GPU. C'est aussi comment tu amenes tes donnees a ton unite de calcul. C'est bien d'avoir une grosse acceleration, mais combien de temps ca te coute d'amener les calcul sur la carte? C'est comment tu amenes tes donnees du disque a la memoire, de la memoire au cache, du cache aux registres. C'est comment tu utilises 2 GPUs, 3 GPUs, 4GPUs. C'est comment tu utilise plusieurs machines qui occupent le meme reseau. Peut etre qu'ils partagent des serveurs de fichiers.

le grain de precision dont tu as besoin pour faire ces choses la, tu ne les verra pas en Java. Il y a eu des efforts pour faire des systeme HPC en Java. Les performances ont toujours ete risible. Pour calculer rapidement, il n'y a pas de mystere, il faut arriver a coller ton architecture materielle. Donc il te faut un langage de bas niveau.

Note que tu pourrais faire le code de haut niveau en Java, et les libs de calcul/management dans un langage de bas niveau.

Il y à beaucoup d'éditeurs de jeux qui livrent le même jeu en même temps sur plusieurs plateformes, genre PC, Playstation, xbox, ... Généralement ces moteurs sont faits en C++, sinon il y à aussi un peu de C, C#, Python mais C++ reste largement majoritaire, il y à qu'à voir cette liste : http://fr.wikipedia.org/wg/wiki/Liste_de_moteurs_de_jeu

Un éditeur de jeux va généralement choisir le meilleur moteur de jeux adapté pour son projet, et le plus portable, et si le moteur de jeux est en C++ alors ça sera C++... non ?

C'est quand même plus facile de rentabiliser un jeux si tu vise large.

Prenons un exemple, moi j'ai Oblivion, un bon jeu qui marche très bien : beau, rapide, très stable, fait par l'excellent Bethesda Softworks, c'est développé avec ce moteur : Gamebryo, et c'est porté sur tout ça :

Nintendo GameCube (à partir de la version 1.2)
PlayStation 2 (à partir de la 1.2)
PlayStation 3 / PSN (à partir de la 2.6)
Wii / WiiWare (à partir de la 2.6)
Windows avec DirectX 9/10/11 (à partir de la version 2.6)
Xbox (à partir de la 1.2)
Xbox 360 (à partir de la 2.6)

C'est énorme, et c'est fait en C++.
Si les meilleurs moteurs multiplateformes sont en C++ et que C# est pas porté sur ces plateformes, on peu comprendre que l'avenir de ce genre d'éditeurs de jeux c'est C++ et que du coup Microsoft laisse tomber les outils jeux pour C#.

tbol,

Je suis convaincu que la portabilite est l'argument principale derriere l'utilisation de C ou C++ dans le domaine des jeux videos. Essayer de tirer des performances de systeme si different a partir d'une architecture virtuelle comme la JVM ou la CLR, c'est juste un cauchemard complet.

C'est amusant a dire, mais je ne connais rien de plus portable que C++...

godrik,

Juste pour préciser que je répondais pas à ton message mais que j'étais en train de réfléchir tout haut sur ce que j'ai lu précédemment sur C++ versus C#
J'ai du écrire mon message en même temps que le tien.

En fait cette discussion intéressante à fait progresser mon avis sur la question, je suis sur les aspects "business" plus que sur les aspects technique, et ça peu expliquer bien des choses...

Je suis fan de plusieurs éditeurs de logiciels de jeux, dont entre autres Bethesda Softworks, et je pense que leur choix, et surtout leurs succès dans le domaine peu nous en apprendre.

tbol, j'ai bien compris.

Je pense que dans l'ensemble, il faut pas etre sectaire sur les technologies que l'on emploie. Par contre, il faut faire attention au contraintes qui sont apporte par chaque choix logiciel. Java, C#, et Python offrent des aspects de haut niveau assez facilement avec des framework un peu partout qui font le cafe. C'est bien, ca permet d'etre productif. Mais on sacrifie de la portabilite et de la performance. Dans plein de cas on s'en fout completement. Je ne sais pas ce qu'il en est de l'interoperabilite de ces techno la. (quelqu'un sait?)

Les technologies que j'ai envie d'appeler "native", c'est une valeure sur en terme de portabilite. Tous les processeurs du monde font tourner du code natif. Si tu arrives a faire tourner du code java, c'est parceque la JVM a ete compile en natif. C'est aussi le mode qui va te donner le plus de potentiel d'optimization parceque tu es si proche de l'architecture. Par contre, il y a souvent assez peu de primitive de haut niveau disponible et tu as tendance a tout te tapper a la main, ce qui est definitivement un probleme.

"Dans l'ensemble, les performance obtenu par les GPUs ne sont pas si interessante."

Savoir coder sur GPU n'est pas si évident, et surtout tous les algorithmes ne s'y prêtent pas, ça tient à l'architecture même du GPU. Pour utiliser le GPU il faut que le calcul soit massivement parallélisable, et il faut éviter tout transfert entre la mémoire du système et la mémoire de la carte graphique. Ces contraintes empêchent de nombreux algorithmes de pouvoir être exécutés efficacement par un GPU, mais ce n'est pas le GPU qui est en tort, c'est l'algorithme utilisé qui n'est pas approprié au GPU. Pour des algorithmes qui s'exécutent très bien sur GPU, comme la plupart des algos qui font du traitement d'image par exemple, alors le gain de performance par rapport à un CPU est vraiment énorme. La simulation et rendu de mécanique des fluides 3D en temps réel est aussi réalisable sur GPU, mais c'est impossible, à ma connaissance, sur CPU.

Silverlight et XNA n'ont jamais convaincu. Pas étonnant que Microsoft ait arrêté leur développement.

@elite_2009
En fait, tu as raison. Il semble bien que Microsoft veuille remettre C++ à l'ordre du jour.
Je vois arriver WinRT. C'est fait en C++, et vu l'architecture, cela semble vouloir remplacer .NET.
De plus, Sutter assure que Visual Studio sera désormais plus rapidement conforme aux normes qui sortiront (C++14 et C++17).

Donc en fait, c'est tout le contraire de ce que j'ai dit. C'est plutôt C# que C++ qui sera utilisé dans des marchés de niche comme le business, le RAD, etc.

Je ne comprendrai jamais Microsoft. Ils sortent un language, puis, quelques années plus tard, ils font marche arrière.

Tsuioku
"Je ne comprendrai jamais Microsoft. Ils sortent un language, puis, quelques années plus tard, ils font marche arrière. "

Je ne sais pas si tu as côtoyé des directeurs en grandes entreprise mais c'est pas mieux que la politique : changement de stratège au gré des changements de direction, directeurs totalement incompétents, voir stratégies faussées pour faire travailler des agences ou prestataires "amis" pour organiser des détournements de fonds massif.

Donc si tu pense que les décisions en grandes entreprises sont toujours intelligentes tu risque d'être déçu.

Si C# disparaît, c'est probablement Java qui récupérera tous les utilisateurs (performances et temps de développements équivalents). Les développeurs d'applications "standard" (applications de gestion, progiciels) qui aujourd'hui développent massivement en C# ne vont très probablement pas passer en C++.

Si Microsoft veut imposer sa plateforme et son environnement de développement, alors il s'y prend très mal.

Aldebran
Posté le 11 février 2013 à 19:24:00

Le C# s'impose massivement pour les jeux indépendants, notamment via XNA. Fez, Magicka, Terraria, Bastion, etc. sont des jeux qui tournent extrêmement bien. D'un autre côté, faut reconnaître que ce ne sont pas des jeux qui bouffent beaucoup de ressources.

J'ai joué pas mal de temps à Terraria, et bien qu'une fois le map chargé il n'a plus besoin d'être chargé, donc pas mal de choses à gérer simultanément, le jeu y va quand même un peu pour rien sur le proco.

Euh, c'est juste XNA qui n'évolue plus, pas le C# non ?

Pour l'instant oui. Mais quand winRT sortira, on peut se demander à juste titre s'il y aura un futur pour .NET.

Je comprends pas trop pourquoi winRT devrait évincer .Net sachant que les interfaces depuis ce langages sont prévues, ainsi que C++ et (lol) javascript.
Et c'est pas comme si tout le monde ASP.net avait cessé d'exister.

Je crois que tu te trompes.

Aldebran, ne me fait pas dire ce que je n'ai pas dit. Les GPUs ont leur utilite. Il y a des problemes sur lesquels ils sont utiles. Mais un GPUs dans le HPC, c'est comme un tournevis en bricolage, ca fait pas tout. Il y a des classes de problemes pour lesquel les GPUs fonctionnent et te font gagner en gros un facteur 20, ce qui est bien.

Mais il y a plein de problemes qui se traitent assez mal sur un GPU parceque le probleme n'est pas regulier. Tout les algos de graphes par exemple c'est un calvaire. Par exemple dans [1] on essaye d'utiliser un C2050 pour calculer betweenness centrality d'un graphe. Comme tu peu le voir, on a amener plein d'optimization : equilibrage de charge pour eviter la divergence de thread, coalescing des access memoire, reduction des operations atomiques. Malgre toute ces optimisation, ca n'apporte pas grand chose compare a une configuration dual CPU classique (figure 7, bar 1,2,3). Sachant que dans cette experience, on a un code CPU un peu naif.
Dans les choses sur lesquels j'ai travaille le plus d'acceleration que j'ai vu est ici [2]. regarde la table 1 et tu vois un speedup de 45 sur une application d'imagerie et de 160 sur une application de reconstruction d'image a partir de trace de radar. Le speedup a l'air gros, mais en fait la comparaison est fait a un core d'un CPU, donc deja tu peux couper par 4 ou par 8. Et dans le deuxieme cas, le code CPU n'est pas optimiser pour faire du SIMD ce qui sur ce genre de probleme est important. Donc une fois que tu fais une comparison honete, tu te retrouve avec des speedup de 10 ou 20, ce qui est bien. Mais "c'est tout".

Ensuite, il faut se rappeler que sur GPU tu as un probleme de memoire, en HPC, il n'y a pas beaucoup de gens qui ont des problemes qui tiennent dans 8GB de memoire. Donc les transfert sur PCI-e tu ne va pas avoir le choix. ou alors il va te falloir plusieurs GPUs, mais la tu es limite dans le nombre de carte PCI-e que tu peux mettre dans une seule machine. Et la synchro entre deux cartes c'est pas completement evident. Tu peux aussi faire un cluster de equipe de GPUs. C'est ce dont on parlait dans [2]. Mais un cluster de GPU apporte peu compare a un cluster standard dans plein d'application. Passer a travers PCI-e ca fait mal. Quand tu fais de la communication cluster de GPU, tu te prends 10 fois la latence d'un cluster de CPU (resultat de MVAPICH [3]).

En bref, les GPUs c'est bien mais c'est une petite partie du calcul haute performance.

[1] http://bmi.osu.edu/~esaule/public-website/paper/gpgpu13-SKSC.pdf
[2] http://bmi.osu.edu/~esaule/public-website/paper/hipc10-HSC.pdf
[3] http://mvapich.cse.ohio-state.edu/performance/

elite, peut etre si AMD fait bien son boulot. Mais depuis 6 ans ils font que de la merde. Donc perso j'attend de voir.

Pour une perspective HPC, il n'est pas realiste de fusionner le "CPU" et le "GPU" a cause des problemes de dissipation thermique. Tu ne peux pas mettre un core i7 et tes 460 core de fermi sur une seule puce, et conserver une frequence a 2Ghz (1Ghz pour les core des fermi) et conserver un tdp en dessous de 150W. Technologiquement, on sait pas faire ca.
Donc il va falloir faire un compromis quelque part (genre ce que fait nvidia avec tegra). Mais ca reste une perspective interessante.

Ce qui va vraiment reolutionner le monde du calcul c'est l'utilisation de NVRAM (la technologie des SSD) comme extension de RAM. Ca pourrait amener des tera octet de RAM avec une latence seulement legerement plus importante que de la RAM standard. Coupler a des accelerateurs comme Tesla ou Xeon Phi, ca pourrait bien botter le cul des architectures genre cray XMT.