jvm : désactiver optimisations

Bonjour à tous,

j'espère que ce post n'es pas mal placé. Je travaille actuellement sur un projet de jeu vidéo développé en java, à l'aide de la librairie LWJGL. Le jeu qui affiche pas mal d'images à l'écran, tourne très bien, même sur des machines peu ressentes. Toutefois, nous sommes confrontés à un problème de temps de chargement. En effet, en lancant le jeu avec les dernieres jvm, par défaut, JIT est activé. Lors du deuxieme lancement, le chargement est quasi immediat. Ce procédé peut se révéler pratique dans une application, mais inadapté pour les jeux vidéo, surtout pour un jeu amateur, le joueur peut en effet être rebuté par les chargements (qui peuvent aller jusqu'a 30 secondes pour une map). J'aimerais donc savoir quelles options ou autres technqiues, me permettraient de diminuer ces temps de chargements, quitte à perdre un peu en performance durant le rendu du jeu.

Merci d'avance.

Salut,


Heu... Je ne comprend pas trop ton problème ?


Si tu veux désactiver le compilateur JIT il faut utiliser le flag -Xint de java... mais je ne comprend pas pourquoi tu voudrais faire cela ? Ton explication n'est pas très clair !


a++

ce sont deux jvm différentes? Si oui, ce n'est pas l'optimisation de la JVM qui entre en cause, c'est probablement le cache disque.

Si votre application met 30 secondes à démarrer une map, la première chose à faire est de déterminer quelle partie de votre application consomme ces 30 secondes et améliorer les perfs dedans.

Salut adiguba,

merci pour ta réponse rapide. Ensuite, je ne maitrise pas trés biens ce sujet, donc je vais essayer de pas dire trop de bétises ^^, n'hésites pas à me corriger. Si j'ajoute le flag -Xint, je passe en mode interprété, ce qui veut dire que la jvm interprètera en temps réel les instructions du bytecode, donc pour un jeu, c'est pas top. l'interet de JIT, c'est de compiler à la volée, en procédant entre autres à des optimisations en faisant une sorte de profiling. Et ces optimisations sont de plusieurs types et sont faites au fur et a mesure de l'exécution du code, ce qui explique la lenteur des chargements d'images au premier lancement du jeu. Ma question était, est ce qu'il y a un moyens de désactiver certaines optimisations effectués par JIT , en restant portables.

Pour le deuxième lancement, je n'ai pas précisé mais oui, c'est sur la même machine. Je lance une première fois l'application. Je la ferme, et je la relance. Quant à la cause du temps mis lors du chargement de la map, c'est clairement, le chargement des images : décompression des PNG, création d'un Buffer contenant les données de l'image, envoi vers la carte graphique, des étapes me paraissant quasi incompressibles.

Citation:

---

c'est probablement le cache disque.

---

est ce que vous pourriez me donner plus de détails sur ce point ?

Sur le site d'IBM, on peut trouver une description des paramètres que l'on peut passer a la JVM, dont celle-ci :

Code:

---

java -Xjit:verbose,optLevel=noOpt HelloWorld

---

hélas, elle n'a pas l'air d'être prise en compte par toutes les JVMs ...

la même JVM ? Ce ne sont certainement pas les "optimisation" java qui sont en cause dans les performance. Le but d'une optimisation n'est pas de ralentir

L'histoire du cache disque correspond au fait qu'à son premier démarrage, la JVM exécute tout un ensemble d'opérations (genre chargement de libs natives, extractiond e jar & ainsi de suite) qui sont mis en cache au niveau du disque par l'OS lui même et seront accessible bien plus rapidement lors du démarrage suivant de la JVM.

Cf notions de cold start/warm start.

http://java.sun.com/developer/techni.../#Quickstarter

Citation:

---

Envoyé par SQUAL

Sce qui veut dire que la jvm interprètera en temps réel les instructions du bytecode, donc pour un jeu, c'est pas top. l'interet de JIT, c'est de compiler à la volée

---

En effet... mais c'est toi qui voulais désactiver les optimisations !

Citation:

---

Envoyé par SQUAL

Et ces optimisations sont de plusieurs types et sont faites au fur et a mesure de l'exécution du code, ce qui explique la lenteur des chargements d'images au premier lancement du jeu.

---

Je ne vois pas en quoi les optimisations de la JVM serait à l'origine des lenteurs des chargements d'images...


Si tu as des problèmes de performances, commences déjà par cibler exactement leurs origines et montre nous le code en question...


a++

Rebonjour,

Tout d'abord, merci pour vos réponses. Je vais essayer d'être plus clair cette fois-ci. En fait, l'environnement java n'est pas la seule cible de notre jeu. En effet, un portage en XNA (C# donc) a débuté. En m'étant essentiellement concentré sur le portage du moteur graphique, je me suis rendu compte que le chargement d'un niveau (qui je le rappelle ne consiste principalement qu'à charger des images) était d'environs 2 à 3 secondes.
Je me suis donc penché sur la manière dont XNA chargeait les images, me disant effectivement que je m'y prenais mal. Je pensais avoir un élément de réponse quand je me suis aperçu qu'XNA transformait les PNG que je lui fournissait en DDS (un format de texture directement interprétable par la carte graphique). Je me suis donc empressé de faire la même chose en java : Je lit un fichier DDS en entrée et j'envoie les données de la texture à la carte graphique. Or, je constate que j'ai toujours les mêmes temps de chargements. (S'il vous faut faut un benchmarket des sources, je peux les envoyer).
Donc, je me suis dit que si XNA, basé sur C# qui se sert également d'une VM permet d'avoir ces performances la, je me suis dit que le problème venais de la JVM. C'est pour ca que je n'ai pas donné trop de précisions puisque je pensais avoir cerné le problème.

J'ai parcouru le lien que tu as donné Sinok, mais je me demande une chose :
lorsque je suis sous Eclipse, que je build le projet pour la première fois et que j'exécute, le temps de chargement d'une map (Et non le temps de lancement du jeu) est de 30 secondes. Lorsque je quitte et que je réexecutes à nouveau, il est de 2 secondes. Mais ensuite, si je fais une modification dans une classe (c'est le cas pour certaines classes) et que je rebuild, la le chargement est encore de 30 secondes, or, la JVM était déjà lancée. D'où mon interrogation sur JIT : quelles optimisations et à quel moment il les fait. Quand j'ai parlé de désactiver les optimisations, je parlais de désactiver "certaines" optimisations, comme le inlining. Si ces optimisations n'influent pas sur le temps d'exécution durant le jeu, quel serait l'intérêt de de les désactiver ? Tu dis Adigabu que les optimisations n'ont rien à voir avec les temps de chargements, et tu as surement raison, mais j'aimerais quand même comprendre cette différence de perf entre java et c#, sachant que j'ai deja fait l'effort de regarder du coté du code en lisant notamment un sujet sur ce forum :
[URL="http://stackoverflow.com/questions/1927419/loading-pngs-into-opengl-performance-issues-java-jogl-much-slower-than-c-t"]. Voila, il y a déjà plus de détails.

Merci de m'avoir lu.

Ce que je ne comprend pas, c'est que tu souhaites désactiver des optimisations pour améliorer les temps de chargement... C'est un peu contradictoire non ?

:arrow: Tu affirmes que le problème vient de la JVM ? Comment peux-tu en arriver à cette affirmation aussi facilement ???

Tes lenteurs viennent du chargement des Map ? Comment fais-tu cela ?
As-tu fais des essais avec la solution donné sur la page que tu donnes en lien ?

a++

Et as tu simplement essayé de passer ton projet à la loupe d'un profiler (comme visualvm qui est fourni avec le jdk 6) afin de vérifier où sont consommées ces 30 secondes?

et vous n'êtes toujours pas clair sur 1 point: Vous exécutez 1 ou plusieurs fois la JVM pour voir des différences?

Citation:

---

et que je rebuild, la le chargement est encore de 30 secondes, or, la JVM était déjà lancée.

---

Tu injecte directement la nouvelle classe via eclipse dans une application qui tourne déja (hot replace)? Si oui, vérifie aussi que ce n'est pas bêtement le debugger eclipse qui ralentit ton application. tout breakpoint conditionnel est suceptible de ralentir l'application.


Enfin, si vous chargez deux fois "dans la même jvm" êtes-vous sûr de bien chaque fois décoder les images depuis le disque? Les apis d'images comme ImageIO en java on un cache nom de fichier -> Objet Image, qui évite de relire quand ont l'a déjà fait. De même, il n'est pas impossible que jogl aie le même genre de cache Image java -> image GL, et en faisant un hotreplace ca invaliderait le cache d'une manière ou d'une autre.


De toutes facon, même si, par un miracle incroyable, les optimisations JIT faisaient passer votre application au second run de 30 à 2 secondes (ce dont je doute), desactiver JIT aboutirait à ce que votre application mette chaque fois 30 secondes :)

Au départ, j'ai donné trop peu de précision, ensuite, j'en ai peut être trop donné, ce qui a rendu la discussion difficile à suivre pour chacun et je m'en excuse. Donc je récapitule en répondant aux questions:

Citation:

---

Adiguba dit : Tu affirmes que le problème vient de la JVM ? Comment peux-tu en arriver à cette affirmation aussi facilement ???

---

- Je n'affirme pas que ca vient de la JVM, je dis que j'y ai pensé, puisque j'ai suivi les conseils donné dans le forum du lien, à savoir chargement de fichiers DDS, donc pas d'imageIO et que donc j'ai pensé être à l'abri des problemes de perfs liés au chargement.

a Sinok:
- J'avais tenté un profiling via les outils d'Eclipse, je le referais ce soir en affichant ici les résultats ainsi que les sources.

A tchize_ :
- J'utilise une seule JVM, et je fais le test en lancant le jeu deux fois de suite (hors Eclipse), la la difference se voit. Ma remarque sur le developpement en eclipse portait sur le fait qu'en modifiant une classe (pas de hot code replace), la lenteur réapparaissait.

A tchize:
- et je le redis, au départ, je ne cherchais pas à désactiver JIT, mais à désactiver certaines optimisations qu'effectue JIT, ce qui est différent. Et d'ailleurs je n'ai pas eu de réponse à ce sujet : il existe des paramètres de la JVM pour ne pas effecteur certaiens optims ou pour définir le nombre de méthodes à executer avant de compiler (CompileThreshold). A quoi servent ces parametres ? Est ce qu'elles n'ont d'incidence que sur le temps de démarrage de l'application ? Certains parametres sont-ils exclusifs à certaines JVM ?

Voila, en attendant que je puisse vous fournir le profiling et les sources.

Ne pas oublier que je suis sur ce forum aussi pour apprendre, et non seulement pour obtenir une solution à mon problème, et que ca pourrait aussi aider d'autres personnes et convaincre certains qu'on peut faire des jeux avec Java ^^

A bientot.

Ce n'est pas parce que tu as suivi un conseil que tu es à l'abri de tout problème.

Je ne comprend pas en quoi la désactivation de certaines optimisations du JIT pourrait améliorer la vitesse d'exécution !!! Au contraire...

Mais si tu veux la liste des paramètres tu peux trouver cela ici : http://www.oracle.com/technetwork/ja...sp-140102.html


Mais je persiste à dire qu'il faut d'abord cibler précisément le code posant problème...


a++

Citation:

---

Envoyé par SQUAL

a Sinok:
- J'avais tenté un profiling via les outils d'Eclipse, je le referais ce soir en affichant ici les résultats ainsi que les sources.

---

VisualVm est mieux fichu et plus précis que les outils eclipse, de loin.

adiGuba :
j'avais deja été sur cette page, ainsi que celle sur le site d'IBM, mais en essayant de passer certains VM arguments dans eclispe, je recois un message d'erreur : unrecognized VM argument (pas bcp de resultats interessants sur google). J'utilise la JDK 1.5

Sinok :
Merci pour l'info ^^ Je vais essayer celui la alors.

En ce qui concerne le profiling je te conseille fortement d'utiliser le JDK 6 (celui qui inclus jvisualvm). En effet java 6 a largement augmenté les possibilités niveau profiling par rapport à java 5

Citation:

---

adiGuba a dit :
Je ne comprend pas en quoi la désactivation de certaines optimisations du JIT pourrait améliorer la vitesse d'exécution !!! Au contraire...

---

Parce qu'au vu de ce que j'avais lu et (surement mal) compris, je pensais qu'à la première exécution du jeu, JIT faisait des analyses du code exécute en temps réel et qu'il produisait du code natif à la volée (donc pendant le chargement d'une map et des images) et que donc le temps passé à l'analyse/profiling + le temps passé à produire du code natif à la volée, pouvait engendrer cette lenteur de chargement.
Voila tout.

Citation:

---

Envoyé par SQUAL

A tchize_ :
- J'utilise une seule JVM, et je fais le test en lancant le jeu deux fois de suite (hors Eclipse), la la difference se voit. Ma remarque sur le developpement en eclipse portait sur le fait qu'en modifiant une classe (pas de hot code replace), la lenteur réapparaissait.

---

Et ben, c'est toujours pas clair et contradictoire. Si tu n'utilise pas de hot code replace, faudra que tu nous explique comment tu arrive à remplacer une classe sans relancer la JVM :aie:

Donc pour ce que j'ai compris,

:arrow: première option:

1) tu lance l'application (java -jar blablabla)
2) tu fais "nouveau jeu" ou autre
30 secondes
3) tu recommance "nouveau jeu"
2 secondes voir moins
4) tu quitte la JVM (retour au prompt)
5) tu modifie une classe
6) tu relance la JVM (a nouveau java -jar blablabla)
7) tu fais de nouveau "nouveau jeu" ou autre
30 secondes

Dans ce cas, je dirais que la différence entre le 30s et le 2 seconde viens d'un cache quelconque que tu as soit mis en place, soit qui a été mis en place à ton insu par une librairie que tu utilise. Donc
1) profiler les 30 secondes, si possible avec au moins deux profilers différents car ils ne sont jamais d'accord entre eux :)
2) identifer où tu passe le plus gros de tes 30 secondes
3) à partir de là essayer de l'optimiser


:arrow: deuxième option

1) tu lance l'application (java -jar blablabla)
2) tu fais "nouveau jeu" ou autre
30 secondes
3) tu quitte (retour au prompt) et tu relance le jeu (a nouveau java -jar blablabla)
2 secondes voir moins
4) tu quitte la JVM (retour au prompt)
5) tu modifie une classe
6) tu relance la JVM (a nouveau java -jar blablabla)
7) tu fais de nouveau "nouveau jeu" ou autre
30 secondes

Dans ce cas, la différence n'a certainement rien à voir avec java. Les optimisation faites par le JIT ne persistent pas d'un lancement à l'autre. Les deux raisons* que je pourrais voir sont
-> Des optimisation au niveau du cache disque de l'OS. LA première fois il lit tout sur le disque, la deuxième fois tout est déjà en mémoire cache, la troisième fois il faut de nouveau tout recharger parce que, ce qui se trouve en cache c'est maintenant le compilateur et toutes ses librairies dont on a eu besoin pour la compilation. Tu perd donc ton temps en IOs
-> Tu consomme énormément de mémoire. La première fois, l'OS "swape dehors" une partie de ton IDE en dehors de la mémoire vive pour faire de la place pour java. La deuxième fois, il y a une espace vide pile poil de la bonne taille puisqu'on a fermé l'application précédente qui l'occupait, donc pas d'opération de swapping. Ensuite tu retourne dans ton IDE, donc "swappe retour" depuis le disque vers la mémoire vive, compilation. Tu lance pour la troisième fois que tu lance, il faudra de nouveau swapper dehors une partie de l'IDE pour faire de la place pour ton application.
-> Même réflexion qu'au dessus, mais avec la mémoire graphique si ta carte a cette "merveilleuse" propriété de pouvoir utiliser de la RAM machine pour compenser un manque de RAM embarquée

* et visiblement je ne sais plus compter :aie:

Salut tchize,

merci pour ta (si longue) réponse, je pense que tu es celui qui a le mieux cerné mon problème et je t'en remercie. Je n'ai pas encore eu le temps de profiler la partie sensible. Dés que je le 'aurais fait, je reviendrais t'embêter encore sur cette histoire de cache disque. Si jamais tu arrives à m'aider à résoudre mon souci, je peux t'assurer que je mettrais ton nom au générique de fin du jeu ;)