Discussion :

[cs_ntd]

mais ce queje critique (car tu n'as pas lu) ce n'est pas le code généré, mais les resources occuppées par le JIT lui même. Peut etre le JIT fera du meilleur boulot sur le code généré en faisant une analyse du code, mais cette analyse de code n'est pas gratuite, elle tourne aussi sur le CPU, et le compilateur JIT utilise le CPU, et il utilise la bande passante de la mémoire et le cache du processeur.
Après le code généré par le JIT il est peut-être très bien hein, mais le JIT lui-même n'est pas gratuit.

C'est la ou est "l'erreur". C'est aussi pourquoi tu parle spontanément de machine virtuelle.

Un "cold start" (ou premier démarrage de l'application) en C# est desastreux en effet : c'est LA que le JIT intervient pour compiler en code natif l'application. Et le resultat de cette compilation, tenez vous bien : est sauvegardée dans un cache !!!

Et quelle est l'intéret de faire ca me direz-vous ? Et bien la prochaine fois que l'application va tourner, plutot que de compiler encore, on réutilise le cache .
Et le JIT pendant ce temps la ? Il se tourne les pouces , et ne consomme pas de ressources... (autre qu'un peu de mémoire surement, mais faut pas exagérer...).

Dément n'est-ce pas ?

C'est pour ca, que autre le terme, et malgrès que le JIT va compiler a la volée a un moment, c'est bien loin d'etre une machine virtuelle ou le code est constemment compilé/interprété.

En plus JIT ca veut rient dire, enfin si Just In Time, mais la dénomination officielle est JIT compiler. Le code est compilé juste au moment du runtime. C'est comme si vous lanciez un GCC sur votre code C pour "l'executer" après.

Bon ce n'est pas tout a fait vrai l'histoire du GCC : en réalité, il existe 3 modes pour le compileur JIT :

• Compilation en entier de l'application au (premier) démarrage, l'image est gardé dans le cache. Pas de couts supplémentaires durant l'execution (cela ce rapproche de l'utilisation de NGen par exemple)
• Compilation partie par partie, suivant ce qui est utilisé dans l'application, les morceaux générés sont gardés dans le cache (par défaut). Du coup, cela permet un cold start plus rapide, mais la première exécution d'un morceau de code nécessite des ressources supplémentaires (il faut le compiler). Ce qui est généré est sauvegaradé, donc les éxécution suivantes seront plus rapides.
• Compilation "a la volée" (ce qui se rapproche le plus de ce que vous dites) : le code a besoin d'etre recompilé a chaque foi, rien n'est gardé dans le cache : le JIT a besoin d'etre actif en permanence, et consomme effectivement des ressources tout le temps.

EDIT :
Si j'ai tout lu ce que tu as dit screetch.

Ensuite je ne suis pas un "fanboy" du C#, j'aime bien le C# c'est vrai, mais quand des choses fausses sont dites, j'aime bien les corriger c'est tout...
Après si vous préférez rester dans votre débat entre gens "convaincus" et surtout que personne ne vienne vous dire que vous dites des choses pas exactes ca peut se faire aussi...

[Louhike]

[...]je sais pas ce qu'est un stub alors pardonnez-moi. [...]

Un stub est appelé "bouchon" en français. C'est un petit programme qui simule le traitement d'un programme conséquent. Il envoie des réponses codées en dur ou fait une interprétation partielle des informations qu'il reçoit. Ils sont plus ou moins complexes selon les besoins.
http://fr.wikipedia.org/wiki/Bouchon_(informatique)
En espérant que mon explication n'est pas trop confuse.

[supertonic]

Merci Louhike mais je dois avouer que l'explication de Wikipedia est plus claire pour moi .

Ca serait pas mal de faire une sorte de tableau à deux colonnes, une pour C++ l'autre pour C# et de lister les différentes parties du développement ET production d'un jeu vidéo (AAA et pas AAA, d'ailleurs qui est ce qui donne les notation AAA dans le jeu vidéo, standart&poor ?)

[laumaya]

Je connais très mal le C# et l'environnement et l'API .NET
Mais il mes semble que la réalisation d'une IHM dépend bien plus de l'API ou du FrameWork qu'on utilise que du langage. Si le C++ est plus complexe que le C#, la différence ce fait au niveau de l'API et pas du langage.

Donc, il me parait plus simple d'utiliser du C++ pour le moteur d'un jeu et toujours du C++ en utilisant un bon Framework comme Qt4 qui offre énormément de possibilités dans la création d'une IHM :

• Widget classiques
• Graphics View
• QML

Et en bonus, c'est portable.

[Julien666]

le developpement des jeux pour window phone 7 c'est xna obligatoirement donc C#.

[Invité]

Un programme écrit avec un langage interprété sera toujours moins rapide qu'un écrit avec un langage natif tout simplement parce que chaque opérations de base à une charge supplémentaire en interprété, c'est logique et toutes les optimisations qui existent et qui existeront ne serviront qu'à se rapprocher des performances des langages natifs mais ne pourront pas les atteindre.
C'est et ça sera toujours plus lent que du binaire, théoriquement, et concrètement, il suffit de faire quelques benchmark, par contre attention plein de fanboy des langages interprétés en font avec du langage natif mal écris et du coup forcément le résultat est totalement biaisé. Pour être sûr autant faire le benchmark soit même ou sinon être sûr de l'impartialité et de la compétence de l'auteur du benchmark.

Il ne faut pas s'offusquer du fait que les langages interprétés soient plus lent, ils ont leurs avantages et leur inconvénients, leur inconvénient majeur est d'être à peu près 4x plus lent qu'un langage natif comme le C++ (bien sûr tout dépend des opérations effectuées mais ils vaut mieux prendre le pire cas), mais la productivité, la portabilité est meilleur. Si les applications temps réel et semi temps-réel sont toujours écris en langage natif ce n'est pas qu'une question d'héritage du temps.

Désolé de te contredire mais des chercheurs d'IBM dans le domaine du calcul haute performance ne sont pas de ton avis (ils invoquent le fait que pas mal d'optimisations possibles avec une machine virtuelle à l'exécution sont inenvisageables dans un langage compilé) ainsi que les créateurs de Jake 2 (clone de Quake 2 en Java). D'où sors-tu que les programmes interprétés sont 4 fois plus lents que leurs équivalents natifs? Jake 2 est pourtant 15% plus rapide que Quake 2, voilà au moins un excellent contre-exemple et ce n'est pas le seul. De plus, ici on parle de .NET et de Java, je te rappelle qu'ils ont tous les deux un compilateur just-in-time ce qui veut dire qu'ils ne sont pas purement interprétés contrairement à ce que tu laisses entendre. Bref, je ne vais pas refaire le débat de l'utilisation de Java dans les jeux vidéo, j'avais apporté pas mal d'éléments techniques. Si pas mal d'applications utilisent toujours le C++, c'est surtout parce que les porter dans un autre langage ne serait pas assez rentable à court terme, je rejoins en partie Mat M. à ce sujet.
Quant aux benchmarks, j'en connais aussi qui sont biaisés dans l'autre sens, quand le gars rajoute un appel à Thread.sleep() alors que cela casse la synchronisation tout ça pour faire comme dans son code C alors que sans cet appel, le résultat est très différent...

Et il faut arrêter de croire à des bêtises.

Je te conseille de ne pas dénigrer celles et ceux qui ne sont pas d'accord avec toi.

Le langage est donc compilé (mais ne produit pas d'instructions natives) puis interprété.

Je te conseille de lire ceci : http://en.wikipedia.org/wiki/Just-in-time_compilation

Plutôt que d'utiliser du C#, (J'ai jamais fait de jeux vidéos donc j'y connais rien) je pense qu'utiliser du C++ et de l'openGL est efficace pour faire un jeu.
Après ce n'est que mon avis

Il est possible d'utiliser OpenGL avec OpenTk en C# et surtout JOGL avec Java.

Le langage est normalisé, donc portable.

Malheureusement, ce n'est pas si simple, Click Once ne marche que sous Windows, l'implémentation du framework .NET Mono diffère en partie de l'implémentation .NET de Microsoft donc parler de portabilité en C# est discutable :
http://tinyurl.com/9n63kb

C# n'est pas fondamentalement plus lent que C++ par contre je connais un paquet de très mauvais développeurs C++.

L'algorithmique et les habitudes de programmation d'un codeur peuvent avoir un impact bien plus grand sur les performances que le choix du langage.

[oxyde356]

Désolé de te contredire mais des chercheurs d'IBM dans le domaine du calcul haute performance ne sont pas de ton avis (ils invoquent le fait que pas mal d'optimisations possibles avec une machine virtuelle à l'exécution sont inenvisageables dans un langage compilé) ...

Il serait très intéressant pour tout le monde que tu partage plus amplement tes sources. Car même si je suis en partie d'accord sur la théorie (qui repose quand même en bonne partie sur de la prédiction ...) il n'y a toujours pas de chiffres, rien de concret. Peut-être pourrais tu étayer tes propos de cette façon.

ainsi que les créateurs de Jake 2 (clone de Quake 2 en Java). D'où sors-tu que les programmes interprétés sont 4 fois plus lents que leurs équivalents natifs? Jake 2 est pourtant 15% plus rapide que Quake 2, voilà au moins un excellent contre-exemple et ce n'est pas le seul.

Wow en effet se permettre de comparer 2 codes qui ont 10 ans d'écart c'est vrai que c'est le summum de l'objectivité, ça c'est un excellent contre-exemple je suis scié, sachant que le deuxième s'inspire plus que largement du premier en plus :o Bon après c'est pas mal ça montre bien les 10 ans de retard dans le domaine ça c'est clair.

Quant aux benchmarks, j'en connais aussi qui sont biaisés dans l'autre sens, quand le gars rajoute un appel à Thread.sleep() alors que cela casse la synchronisation tout ça pour faire comme dans son code C alors que sans cet appel, le résultat est très différent...

Oui bien sûr qu'il y en à des biaisés dans l'autre sens c'est pourquoi partant de la constatation que les tests sont très souvent foireux il faut vraiment les scruter attentivement, et les mieux faits montrent clairement de quel côté sont les performances.

Je te conseille de ne pas dénigrer celles et ceux qui ne sont pas d'accord avec toi.

Je ne dénigre en rien les personnes qui sont en désaccord avec moi je dénigre leurs arguments, il me semble que c'est mon droit.

Je te conseille de lire ceci : http://en.wikipedia.org/wiki/Just-in-time_compilation

Ton JIT ne vas pas compiler à la volée ton code pour au final en faire un bloc unique d'instructions il ne va compiler que petits morceaux par petits morceaux pseudo-indépendants et c'est pas du code en langage natif qui va faire le lien entre tout ça !

[Camille_B]

ainsi que les créateurs de Jake 2 (clone de Quake 2 en Java). D'où sors-tu que les programmes interprétés sont 4 fois plus lents que leurs équivalents natifs? Jake 2 est pourtant 15% plus rapide que Quake 2, voilà au moins un excellent contre-exemple et ce n'est pas le seul.

C'est un faux exemple. Comme cela a été précédemment dit, 10 ans sépare l'écriture des deux codes. Entre temps le code source a été étudié forké, reforké (puisqu'open source) jusqu'à ce qu'il soit extrêmement poli.

Un exemple du même type c'est le portage de Doom pour Amiga avec processeur Motorola 68xxx. À l'époque de la sortie de Doom sur PC on pensait qu'un tel jeu était impossible sur Amiga, moins à cause des perds brutes (proc & mémoire) qu'à cause des particularité de conception de la puce graphique.

Et pourtant, après l'ouverture du code du moteur, il a fallut quelques années pour voir apparaître une version Amiga du jeu.

Non seulement à destination de machines aux perfs brutes inférieure à un 486, mais également pour des machines dont la puce graphique, excellente pour la 2D multiplans, n'étaient pas adaptées à la 3D.

Au final ? Un doom parfaitement fluide sur un simple A1200 grâce à un code ultra-optimisé.

[supertonic]

la question n'est pas de savoir si un compilateur génère un code plus performant qu'un compilateur C++ ou C, si vous vous voulez une max de perfs foncez sur l'assembleur et optimisez moi ça pour chaque puce (pratiquement ce que l'on fait sur console non ?), mais de savoir si le C# va commencer a être un langage d'importance dans le développement de jeu ... moi j'en conclu qui oui, même sur les gros titres, dans les couches gameplay au minimum...

oxyde356 excuse mais tu as pas lu les postes précédents qui expliquent a plusieurs reprises que la compilation peut se faire à l'avance ou COMPLÈTEMENT au premier lancement ?

vive le C++ et vive le C#

[oxyde356]

Mais j'ai juste parlé du JIT parce que gouessej en parlait et je répondais là dessus. Après quelle soit faite pendant ou avant ça ne change rien à ce que j'ai dis, elle n'est pas totale !

[LLB]

oxyde356 : écris du code C#, compile-le et regarde la sortie du compilateur JIT (dans VS : Windows -> Debug -> Disassembly).

Exemple rapide (il n'y a pas toutes les optimisations activées) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
            int sum = 0;
00000000  push        ebp 
00000001  mov         ebp,esp 
00000003  sub         esp,0Ch 
00000006  mov         dword ptr [ebp-4],ecx 
00000009  cmp         dword ptr ds:[0011313Ch],0 
00000010  je          00000017 
00000012  call        61BD63AB 
00000017  xor         edx,edx 
00000019  mov         dword ptr [ebp-0Ch],edx 
0000001c  xor         edx,edx 
0000001e  mov         dword ptr [ebp-8],edx 
00000021  xor         edx,edx 
00000023  mov         dword ptr [ebp-8],edx 
            for (int i = 0; i < 100; i++)
00000026  xor         edx,edx 
00000028  mov         dword ptr [ebp-0Ch],edx 
0000002b  nop 
0000002c  jmp         00000037 
                sum += i;
0000002e  mov         eax,dword ptr [ebp-0Ch] 
00000031  add         dword ptr [ebp-8],eax 
            for (int i = 0; i < 100; i++)
00000034  inc         dword ptr [ebp-0Ch] 
00000037  cmp         dword ptr [ebp-0Ch],64h 
0000003b  jl          0000002E 
            Console.WriteLine(sum);
0000003d  mov         ecx,dword ptr [ebp-8] 
00000040  call        5B41C340 
        }

Maintenant, dis-moi, qu'est qui n'est pas "totalement compilé" dans ce code ? Ce ne sont pas des "petits morceaux pseudo-indépendants", c'est du code machine, comme en produit un compilateur C++.

Si tu veux des arguments contre .NET et son JIT, je peux t'en donner (en plus de ceux qui sont répétés). Par exemple, le JIT a très peu de temps pour générer le code, et de ce fait certaines optimisations ne sont pas faites, tandis que les compilateurs C++ peuvent se permettre d'être plus agressifs (g++ -O3 fait des transformations impressionnantes). Ca concerne surtout les optimisations qui nécessitent une analyse poussée du code (par exemple, l'optimisation qui vire la vérification des accès tableau ne marche que dans les cas les plus simples).

[Elendhil]

Vous pensez vraiment que le même code pour faire un jeu en c# sera 2 fois plus lent, voir plus que du C++ ?

J'ai quand même de gros doutes , admettons que la différence soit de 20% à 30%, dans ce cas je vois pas de problèmes techniques pour créer un call of duty 4 en C# sur console par exemple.

Réduire de 20 à 30 % le nombre d'images de cod4 sur xbox devrait pas donner un jeu complètement injouable.

Je pense que le problème est tout autre que les performances ! Comme les autres le disent , les outils , les compilateurs pour console, les moteurs 3d, les middlewares, le code existant des jeux,les développeurs et les experts dans le domaine, tout est basé sur le C++.

Donc partant de là pourquoi changer ?

De plus par exemple si une société qui a de nombreux développeurs talentueux en java ce décide de créer un jeu 3D AAA pc en java, ils vont vouloir s'appuyer sur des outils existants .

Problème le choix sera très vite limité, tu auras Java Monkey engine ou ardor3D, les 2 seuls moteurs avec lesquels tu peux obtenir quelques choses , mais on est très très loin de la qualité d'un cryengine , unreal engine et des outils fournis avec, c'est même incomparable.

Donc il faudra refaire tous ce que ces studios ont réalisé pendant les 5-6 dernières années.

Le jour, il y aura les mêmes outils disponible pour les langages semi-compilés comme c#, java ou même as3, la donne ne sera plus la même.

Dans 10 ans des jeux dit AAA , en java ou c# , il y en aura à la pelle je pense.
Faut voir que java commence à être reconnu depuis la version 1.4 ça fait seulement 9 ans.

D'ailleurs il y aurait un gros marché pour ce genre d'outil en java , vu le nombre de développeurs dans ce langage. Si on regarde Android une grande part du succès est lié à java.

[oxyde356]

mdr LLB tu pense bien que quand je parle d'un code morcelé je ne pense pas que ça va diviser en 2 un code à 5 lignes avec des fonctions built-in XD

[screetch]

Elendhil si on part du principe que C# est 20/30% plus lent ton post n'a déjà sans doute pas de sens;
sur console on a le choix entre 2 framerate, 60 et 30. Si on atteint pas les 60 on est obligé de descendre a 30 ou a 15.
Si call of duty est a 60, les 20% vont sans doute les faire descendre a 30
si ils sont seulement a 30, les 20/30% peuvent les faire descendre a 15.
Enfin il y a quand meme une chance que ca marche hein
Et ca vient seulement d'une évaluation "au pif", donc c'est difficile de se faire une idée.


De plus comme j'ai dit plus haut le pire problème pour les consoles c'est pas le CPU c'est surtout la mémoire, sur une machine qui n'a que 200 megs de mémoire ca n'est pas rien de lâcher comme ca 10% pour charger un JIT ou le runtime de C#.
De plus C# ne pourra pas fonctionner sur les SPU de la playstation 3.

Sur les consoles actuelles, C# c'est juste pas possible comme langage principal et c'est costaud comme langage de script, pour les jeux AAA.
Comme dit plus haut, c'est parfait pour les jeux indy et les jeux avec moins d'objets a afficher.

[befalimpertinent]

Si les moteurs de jeux vidéos pour jeux AAA sont en C++, outre les raisons historiques et de perfs (quoique qu'on en dise on peut au moins s'accorder sur le fait que le C++ n'est au moins pas plus lent que le C# ).

Ne pourrait-ils pas y avoir des raisons liées au fait que dans un cas le langage et son évolution appartient à une entreprise privée alors que pour le C++ l'évolution se fait par comités (avec certes les inconvénients qu'on peut trouver en terme de rapidité d'évolution par exemple)

Si j'étais une entreprise devant écrire un moteur de jeu from scratch une des raisons qui me pousserai vers le C++ est que je ne souhaiterais pas que une partie aussi critique qu'un kernel soit soumis pieds et poings liés au bon vouloir d'un entreprise privée. Le réécrire toutes les n.0 version n'est pas une option envisageable.

[oxyde356]

C'est un très bon argument en effet. Après c'est difficile de juger, en général même si les technologies M$ sont très repliées sur elles mêmes le C# fait figure d'exception tout en profitant de la vitesse d'évolution d'un produit Microsoft.
Et puis est-ce que ça va durer, parce que on a bien vu comment ils ont déployer une stratégie de séductions des développeurs Java pour les faire passer au C# (et bien d'autres développeurs bien entendu mais c'est un exemple assez pertinent je pense) mais maintenant que c'est en partie fait est-ce que cette stratégie va rester où M$ va-t-il invoquer des excuses pour refermer C# sur Windows ou un truc du genre qui sait...
Personnellement je ne le pense pas mais en même temps je n'ai pas vraiment de risque à le penser contrairement à des chefs de projets qui sont tentés d'utiliser cette technologie.

[screetch]

la plupart des développeurs utilisent DirectX et sont donc "entre les mains" de microsoft déjà, dans un sens
mais microsoft fait le maximum pour que DirectX soit le plus efficace possible pour les jeux vidéos, car tout le monde s'y retrouve;
microsoft vend plus de windows pour les jeux vidéo
les développeurs de jeux vidéo font de "meilleurs" (i.e. plus beaux) jeux
les cartes graphiques se vendent mieux

au final en collaborant tout le monde y gagne

ce serait pareil en C#; si microsoft venait a virer de bord et perdait les développeurs (de jeux ou d'autre chose) "son" langage tomberait en désuetude


l'inverse, c'est OpenGL, géré par un consortium qui se chamaille en permanence, et ca a donné OpenGL 3 qui n'était adapté a personne, et OpenGL ne perce toujours pas dans les jeux AAA, sauf sur quelques moteurs qui veulent tourner sur Mac. Quelque fois, un dictateur bien eclairé aide beaucoup au développement rapide

[Camille_B]

Et puis est-ce que ça va durer, parce que on a bien vu comment ils ont déployer une stratégie de séductions des développeurs Java pour les faire passer au C# (et bien d'autres développeurs bien entendu mais c'est un exemple assez pertinent je pense) mais maintenant que c'est en partie fait est-ce que cette stratégie va rester où M$ va-t-il invoquer des excuses pour refermer C# sur Windows ou un truc du genre qui sait...

Il faut être clair, Microsoft n'a jamais fait grand chose pour que .NET fonctionne sur autre chose que Windows.

Mono est un projet open source né de gus qui n'avaient pas grand chose à voir avec Microsoft

Aujourd'hui Microsoft aide un peu à son développement, mais si les devs actuels de Mono arrêtent tout, son avenir est compromis car, a priori, Microsoft est certes intéressé par la chose, mais pas plus que ça.

Au fond, c'est la tactique idéale : "regardez notre techno tourne sur Linux et OSX (en plus c'est même pas nous qui faisons le boulot)". Et puis le jour où ça coule : "Ah bah tant pis, mais nous on y peut rien".

Cela dit, je ne crois pas que Mono soit en danger à court terme de disparaître, et c'est une techno que j'apprécie (je ne suis pas du tout anti-Mono). Mais c'est un problème à prendre en compte.

[Louhike]

Merci Louhike mais je dois avouer que l'explication de Wikipedia est plus claire pour moi .

Je viens d'ailleurs de remarquer de l'explication sur Wikipedia est incorrecte, il peut y avoir un traitement et les réponses envoyées ne sont pas toujours les mêmes...

[oxyde356]

Il faut être clair, Microsoft n'a jamais fait grand chose pour que .NET fonctionne sur autre chose que Windows.

Mono est un projet open source né de gus qui n'avaient pas grand chose à voir avec Microsoft

Aujourd'hui Microsoft aide un peu à son développement, mais si les devs actuels de Mono arrêtent tout, son avenir est compromis car, a priori, Microsoft est certes intéressé par la chose, mais pas plus que ça.

Au fond, c'est la tactique idéale : "regardez notre techno tourne sur Linux et OSX (en plus c'est même pas nous qui faisons le boulot)". Et puis le jour où ça coule : "Ah bah tant pis, mais nous on y peut rien".

Cela dit, je ne crois pas que Mono soit en danger à court terme de disparaître, et c'est une techno que j'apprécie (je ne suis pas du tout anti-Mono). Mais c'est un problème à prendre en compte.

Oui enfin ce que je voulais dire par là était relatif à la politique général de Microsoft qui normalement fait obstacle dès qu'il s'agit d'utiliser du Microsoft autre part que sur des produits Microsoft.