Si l'on regarde les papiers de MS à propos de C# par rapport à C++ dans le domaine du jeu, on peut avoir une bonne idée de ce que pensent des professionnels biaisés mais aguerris sur ce débat, car j'ai l'impression que les problèmes de C# dans le domaine du jeu doivent être du point de vue technique très proche de ceux que posent Java. A l'exception du boxing, je pense que le papier est pratiquement entièrement applicable à ce "débat".
Les arguments avancés dans cette publication sont très cohérents: "Costs a very small amount of performance in exchange for games that never crash due to wild pointers, ever!", "Type-safe reusability", "No buffer overruns, ever!", "Again, trade is rapid development of robust games for performance".
Ces soucis basiques de "robust games" (crash par pointeurs, buffer overrun et autres bugs) ne concernent pas les jeux à gros budget, où les bugs ont un million de fois plus de chance de venir des autres domaines du développement (la quête qui bloque, les gobelins appelés string_ID_error, le fusil-laser qui pointe pile dans l'œil du Jedi, ...). C++ est massivement utilisé dans des systèmes critiques, que ce soit dans l'armement, la santé, les communications etc. A partir d'un certain seuil de qualité de l'équipe de développement, et les studios pondant les jeux à gros budget atteignent certainement ce niveau critique, parler de crash à cause de pointeur est hors sujet. C'est une autre histoire pour les développeurs individuels.
Par contre, on peut voir dans le document en lien que les soucis pour maintenir la performance dans des environnement à GC automatique sont loin d'être triviaux (l'importance que lui accorde l'équipe XNA "The GC can be a tough beast to wrangle" pourrait interpeler certains et relativiser certaines affirmations un peu rapides). Pour faire un jeu aux limites de la technique, ce qui contient la totalité des jeux AAA presque par définition, il faut donc effectuer un travail spécifique supplémentaire, d'où une perte de productivité sur ce point précis.
Quant à la rapidité du reste du développement, il est évident qu'elle dépend de l'infrastructure à laquelle a accès le développeur. Pour un programmeur isolé, des outils ultra simples comme XNA peuvent être attirants, malgré leur manque de contrôle fin ou de puissance. Pour un studio de développement organisé et financé, les outils internes ou middleware puissants en C++ sont certes bien moins simples, mais ne poseront strictement aucun problème à des professionnels, et donc ils peuvent profiter de la puissance et de la maitrise sans s'exposer particulièrement à des pertes d'efficacité de développement.
Enfin, je rappelle qu'à partir du moment où l'on arrive à mettre suffisamment le GPU à contribution, même Ruby peut exposer des performances époustouflantes (j'ai géré un projet de machine complexe dans lequel le prototype de faisabilité a été bidouillé en Ruby/C#/GPU, nous avons atteint toutes les butées des bandes passantes du PCIe dès le proto). Donc je suis sûr, contrairement à ce qui est souvent remis en question dans cette discussion, que Java peut mettre n'importe quel PC + GPU à genoux avec une efficacité parfaite, après initialisation soigneuse et profilage conséquent.
Simplement, c'est bien moins simple à faire de façon fiable et industrielle qu'en C++: par simple ré-écriture en C++ du prototype, selon nos méthodologies habituelles de développement, nous n'avons gagné que quelques % en vitesse moyenne, mais nous sommes débarrassé sans coup férir de tous les hoquets intermittents de l'implémentation Ruby/C#. A contrario, il nous aurait fallu plus de temps pour faire le proto en C++ (en l'occurrence, un proto était nécessaire pour des questions fondamentales de faisabilité, ce qui n'est pas le cas d'un jeu dont les performances sont dictées par le PC, et non fixées par les besoins de l'application).
Par analogie entre le sujet et ce cas de programme à très haute performance en environnement à GC et langage productif et peu rapide, il faudrait que Java soit bien plus productif que C++ pour justifier le surcroit de précaution et de travail. Les jeux à gros budget étant tout bêtement des projets classiques de PME, les mêmes questions qu'ailleurs (C++ vs Java) se posent, avec des réponses similaires.
Je soutiens que le parallèle fait ici entre C# et Java n'est pas parfait, mais reste pertinent à cause des évidentes similarités entre les problèmes de Java et de C# du point de vue de la programmation des jeux. Il est d'autant plus intéressant que l'équipe XNA, qui a quand même une autre autorité en matière de développement de jeu que tel ou tel effort open source plus ou moins primitif, est le seul soutien officiel de C# et des VMs en général dans les jeux, mais est aussi en charge de DX10 (soutenu officiellement uniquement en C++ dit "natif", càd sans VM), et qu'elle a vainement tenté par le passé de convertir la communauté du développement de jeu vers les langages à VM, en particulier avec managed DirectX, qui a été totalement rejeté bien qu'il ait été entièrement accessible en C++!
Cet épisode montre s'il en était besoin que ce débat est stérile, ne serait-ce que par la confusion entre contrainte en provenance du langage ou en provenance de la machine virtuelle.
Donc je vais y aller aussi de mes petites conclusions à propos du sujet "Java est-il adapté aux jeux video?":
- Oui, Java peut faire hurler le métal. Il y a plus simple, mais on peut, puisque le juge de paix d'un jeu aux limites, c'est le GPU, et qu'au bout d'un moment on est en (xx)SL quel que soit le langage d'origine (j'ai parlé d'un exemple extrême avec Ruby)
- Non, une VM à GC n'est pas neutre vis-à-vis de la simplicité de maitrise des performances (cf. le papier en lien).
En conséquence, Java est sans doute adapté, mais pas le plus adapté, et n'est donc pas utilisé, pour de simples raisons pragmatiques. C'est la mésaventure qui est arrivé à Managed DirectX / C++, et même la puissance de MS n'a rien pu y faire.
Pour moi qui ne fait pas de jeux, mais qui utilise des GPUs, des FPGAs et autre électronique à très haute vitesse en environnement industriel, Java ne présente aucun intérêt particulier par rapport à C++, et par contre présente quelques inconvénients réels. Je comprends donc tout-à-fait pourquoi Java n'accroche pas dans le milieu du jeu.
Répondre avec citation
Envoyé par ac_wingless
Partager