Just In Time compilation, c'est tout
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Just In Time compilation, c'est tout
en théorie c'est pas possible
un compilateur peut générer une version instrumentée d'un executable, analyser le résultat et générer une version optimisée a posteriori, comme un compilateur JIT pourrait le faire (Sauf que le JIT le fait a la volée)
Et même si l'égalité était possible, le JIT lui même n'est pas gratuit, il faut bien prendre du temps CPU pour analyser les perfs et recompiler dynamiquement.
En pratique, certaines implémentations très spécifiques sont mieux optimisées par certains JIT que par certains compilateurs.
Ouai donc les seules optis qu'il pourrait y avoir dépendent du système et non du langage donc c'est aussi faisable par un compilateur. Donc en théorie avec un langage interprété comme le Java il n'y a aucune optimisation qui n'est pas faisable dans un langage natif comme le C++ (j'entend pas le biais du compilateur), c'est ce qu'il me semblait c'était juste pour être sûr ^^Envoyé par screetch
c'est un peu plus compliqué. Je crois qu'en fait les compilateurs actuels ne sont pas tres fort sur le "profile guided optimisation", pour l'instant.
Sur l'ensemble d'un gros programme, je crois cependant que c'est toujours le langage precompilé qui gagne
Oui les optimization théoriquement possibles avec du Just In Time vont bien plus loin parcequ'il y a de l'analyse du comportement de l'application pendant l'execution. Donc, profiling, compilation des parties les plus statiques, optimizations diverses selon le graph d'execution, puis eventuellement optimization de l'agencement de la mémoire selon les accès, etc.
Le probleme avec JIT c'est jsutement que même si le tout est optimisé au runtime, le timing de l'ensemble devient fluctuant (au moins pendant un temps aprrès le départ) ce qui fait que de toutes façon ce n'est pas adapté pour tout ce qui est temps-réél ou pseudo-temps-réel où on a besoin de prévisibilité.
Donc dans le jeu vidéo, JIT est rarement pertinent.
Cela dit, tout dépends des performances requises pour le jeu. C'est simplement que beaucoup de types e jeux requirent de base des performances brutes et facilement prévisibles. Si tu design un jeu où c'est moins le cas (un jeu tour par tour sans affichage gourmand), il n'y aura pas ou peu de problemes.
le "profile guided optimization" pour le C++ (pgo pour les intimes) revient au meme, avec deux binaries: un binaire instrumenté execute du code et enregistre les statistiques sur les branchements, etc, donc fait aussi de l'analyse de comportement. Ensuite, on invoque le compilateur et linker une seconde fois avec en entrée les données d'analyse.
En theorie cela permet de faire la meme chose qu'avec un JIT mais en "offline". En pratique je crois que c'est moins performant et moins souvent mis en oeuvre
Et surtout, ce n'est pas l'environnement de l'utilisateur, mais un environnement de test qui est utilisé.
Ca change tout parcequ'il n'y a pas d'adaptation au contexte justement.
Puis l'agencement de la mémoire selon les accès c'est largement faisable en C++ aussi.
Dans une certaine mesure seulement.
Mais dans tous les cas effectivement sans JIT on peut déjà faire pas mal de prédictions en C++ et c'est le point le plus important quand il sagit de développer du jeu, simplement parceque l'experience du jeu dépends totalement de ce qu'on permet a la machine de faire.
en fait il y a globalement une grossière egalité entre le JIT et le profile guided optimization, le JIT ayant un avantage dans certains cas mais cet avantage n'est pas transposable sur une partie gigantesque d'un programme. En revanche, le JIT lui même a un cout memoire et CPU encore trop élevé pour arriver a concurrencer le langage precompilé.
C'est seulement le cas pour les meilleurs compilateurs, comme les compilateurs C++ (gcc, msvc, suncc et intel) ainsi que dans certaines niches (haskell, prolog) tandis que des langages comme Delphi ou autres sont clairement moins optimisés que les langages avec les JIT efficaces, comme C# ou Java.
Enfin, dans certains cas une JIT plomble clairement les performances dans le cas de memoires tres limitées. Sur XBox ou PS2 par exemple, la memoire disponible est seulement de 32MO, si on prend 10 megs pour l'executable + 10 megs pour la JIT il ne reste plus grand chose. Sur un PC, bien que la memoire dispo soit plus large, acceder a la memoire plombe aussi les performances tres haut niveau et contrebalance l'optimisation JIT, d'ou un rendement plus faible que prévu
Ca change tout, bof, faudrait pas exagererCa change un peu, mais les parties les plus critiques sont souvent les mieux optimisées, donc en pratique on voit peu la difference.
les jeux android ça se programme en java non ?
Jusqu'à ce qu'il y ait besoin de meilleures performances, oui, parceque c'est le plus simple à développer.
Si les performances deviennent un problème important, on passe au Native Developpement Kit, donc C++ et C.
Par exemple, quasimment tous les jeux en 3D sont en C++, mais evidemment sur cette plateforme ils ne sont pas légion. En fait tous les développeurs que je connais qui ont développé sur IPhone ou Android on finit par passer au C++ a cause de soucis de perfs, pas parceque l'implémentation de Java est lente, mais parcequ'elle n'était pas assez permissive en optimization pour atteindre leurs objectifs. C'est subtile a comprendre : la plupart des jeux 2D n'ont pas besoin de plus que la plateforme de base Java sur mobile. Ajoute un peu de 3D complexe ou un système poussé de physique, ou pire de l'IA qui doit rouler en pseudo-"temps réél"... et ça devient difficile.
Il y a un autre aspect qui fait que beaucoup de devs utilisent C++, C ou Objective C et Objective C++ : la portabilité.
Java étant interdit sur IPhone, une des solutions pour les applications qui doivent être dispo sur Iphone ET Android c'est de le faire avec un language compilé en natif. C'est une des solutions mais pas la seule, evidemment.
Donc pour résumer : java peut être un bon choix, pour peux que toutes les plateformes le supporte et que les performances ne soient pas un problème (ce qui n'est en fait pas toujours le cas puisque les jeux sur portables sont rarement extrèmenent complexes).
Il y a une chose a propos de la portabilité de java : celui sur Android n'est pas le même que celui sur les autres mobiles qui supportent Java, comme par exemple les BlackBerry.
Autrement dit, C++ (et d'autres languages natifs) sont généralement plus portable que les différentes implémentations de Java dans le monde mobile.
Enfin, même avec cela en tête, C++ reste plus difficile (et surtout long, essentiellement a cause des compilations longues) à développer.
Quand on connait ses objectifs de projet , il est très facile de choisir entre ces languages pour sa propre utilisation.
Non mais bloodridge... Regardez un peu les jeux faits avec XNA....
Oui je sais le graphisme ne fait pas tout mais vous vous tapez dessus pour une comparaison de jeux ... pas AAA, très très loin même... On dirait des jeux datant de l'époque de Quake 2 en moins beau...
Le langage le mieux adapté pour UN (type de ?) jeu vidéo dépend de ce que le jeu doit être et des librairies disponibles si on ne vaut pas réinventer toute les roues du carrosse... De même que le support du matériel accélérateur.
On doit pouvoir faire un Crysis en Java, ok. Mais je demande à voir... Parce que les petits gars de chez crytek connaissent le C++ sur le bout des ongles et les pointeurs bien utilisés il n'y a pas plus rapide. De même pour le prochain moteur Unreal 4... M'étonnerait que ça ne fonctionne qu'avec des références/passages par copies...
Remedy games utilise D en complément de C++. On reste dans les langages systèmes, niveau perfs, mais plus important, niveau latence, c'est le seul moyen de contrôler.
En effet, l'idée très répandue est que le JV à besoin de beaucoup de perfs. Si c'est un point important, ce n'est pas le plus important. Bien avant les perfs, le JV à besoin de temps de réponse courts (si vous n'êtes pas convaincus, essayez les jeux infogrammes type tintin au tibet).
Tu peux bien fournir 100fps, si tu ne peux pas garantir qu'une image va sortir au moins toutes les 16ms, tu es foutu.
Rien que pour ça, de nombreux GC sont hors course. Bien sur l'utilisation d'un GC n'est pas exclu, mais il faut qu'il ai de bonne caractéristiques.
Si tu parle des jeux qui sont publiées conjointement sur pc et xbox, il faut aussi rappeler qu'il y a(avait) des grosses contraintes de tailles sur les applications présentes sur le xla. Au démarrage c'était 50 mo(quelques soit le language tu fais pas tenir les ressources graphiques d'un Crisis dedans), maintenant c'est 2 Go(500 mo sur XBLIG) d'après le wiki.
Pour en revenir à la discussion d'un point de vue amateur, pour moi la question ne se pose même pas. Il vaut tjs mieux prendre le language dans lequel on est à l'aise. C'est déjà assez dur de se motiver sur la longueur, si en plus on doit travailler avec des outils que l'on aime pas...
Vous aimez Java et OpenGL, allez y. Ce n'est peut être pas le choix que je ferais, mais c'est le votre.
D'un point de vue professionnel, ça dépent beaucoup de la plateforme et du résultat visés.
Mhh... je crois que malheureusement ça dépend surtout du budget. Si dans les petites structures comme ankama ou mojang ils choisissent le java, c'est parce qu'ils ont pas le temps de faire leurs jeux en c+
Ankama utilise beaucoup ActionScript mais aussi C++ pour les clients de certains jeux developes plus recemment, dont "Slage" qui a ete annule. (je connais pas mal de membres de l'equipe).
Ils me semble qu'ils n'ont utilise Java que pour la partie serveur de leurs differents jeux, et je suis pas sur que ce soit le cas sur Slage ou les jeux suivants.
C'est pas vrai qu'il n'y a pas de plein écran en Java ni que c'est lent pour afficher de la 3D temps réel! Il y a JOGL
Java peut être plus rapide à l'exécution, encore un préjugé.
Dis donc, super argumentation, ça vole haut.
Ca fait belle lurette qu'on n'utilise plus d'assembleur pour programmer les jeux hormis sur les vieux shaders.Dis donc, super argumentation, ça vole haut.
Dis donc, super argumentation, ça vole haut.
J'allais dire que le java est très utilisé niveau tools internes dans les petites boîtes qui font leurs propres moteurs (editeurs de gfx, de maps, de musique, etc), mais c'est un peu maigre comme argumentation, donc je propose une vue de ce débat sous un angle plus "économique".
Sachant qu'en France l'industrie du jeu vidéo est très marginale, la majorité de notre production ce sont des jeux amateurs faits par des gamedev du dimanche, qui le reste de la semaine travaillent là où ça embauche surtout en france, à savoir principalement la gestion de bases de données.
Sur le CV d'un développeur français on attend donc en priorité les langages objet impliqués dans la gestion de bdd: java, c++, c#, php, etc
A partir de là on considère que le gamedev du dimanche peut avoir des bonnes raisons de faire des jeux avec l'intention de s'entraîner sur ces langages, la solution idéale serait, dans l'idéal, évidemment, dans la mesure du temps disponible:
- faire les tools en java/c#/python/etc
- gérer la partie serveur en java/php/etc
- faire la lib son/image en c++
- éventuellement programmer le gameplay en c#
Dans ce cadre là on peut donc manger pas mal de java, comme chez nos tout petits studios qui font des jeux smartphone ou facebook.
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.
Répondre avec citation
Partager