performances de java - Page 1

plop,

j'ai un projet à coder en java sur un mois, et pr l'instant je n'ai jamais utilisé ce langage; on a deux sujets au choix, qui sont tous les deux des jeux, l'un est réalisable en 3D, pour l'autre c'est nettement moins évident, mais j'ai un doute : est-ce que c'est raisonnable de vouloir faire quelque chose de rapide en 3D avec JOGL (un truc pas "trop" ridicule quoi, ac des modèles 3DS et cie), ou bien ça risque d'être vraiment tendu niveau performances ?

mci

Il me semble que la partie rendue est déléguée à OpenGl, donc il n'y a que la logique du jeu qui sera en java, et ça devrait être correct.
Après, ça dépend de ce que tu veux comme qualité de rendu et de ce que comportent tes scènes.

même si le langage n'a effectivement aucune influence pr le rendu en lui-même, ça implique pas mal de calculs, c'est surtout là-dessus que je me posais des questions

sinon comme qualité bah... je sais pas trop pr l'instant, c'est pour un petit jeu de stratégie donc mettons une heightmap et une 50aine de modèles 3ds dont la moitié affichés en même temps sur l'écran ?

ca devrait se faire, je pense que c'est plutot l'ia si tu dois en coder une qui risque de penaliser non? (je suis pas expert en java...)

hmm ué je dois en coder une, c'est pas bete comme remarque... personne n'a déjà tenté de trucs de ce genre en java et peut évaluer si ça risque de donner des mauvais résultats ou non ?

(je sais pas si c'est toujours d'actualité, enfin bon, on sait jamais)

Il y a quelques mois, j'avais voulu apprendre à faire du SDL, je m'étais trouvé un bon tuto, et paf, au travail. Le seul problème était que le tuto était en C++, dont je ne sais pas me servir. Qu'à cela ne tienne, me suis-je dit, caml a des bindings SDL, je vais tout traduire en caml, comme ça en plus ça me fera apprendre. Je l'ai donc fait.

Au début ça marchait bien. Puis, à un moment, le tuto s'est mis à faire des moyennes de couleurs dans chaque boucle. Avec des && et || logiques. Le problème évidemment, c'est que caml n'a pas d'entiers 32 bits. Donc les couleurs sont un type spécial "Color", sur lequel on ne peut pas faire d'opérations logiques. J'avais donc le choix entre utiliser une fonction de conversion de couleurs en un triplet d'entiers (lent) puis faire des opérations dessus (rapide), ou convertir les couleurs en un autre type de caml, Int32 (rapide) puis faire des opérations dessus (lent). Quelle que soit la solution utilisée, c'était super lent.

Les entiers en java sont bien sur 32 bits (du moins, je crois). Par contre, il est sûrement fort possible de tomber sur d'autres problèmes du même genre (ie perte de performances car conversions trop nombreuses entre divers types).

(bon c'est HS, mais je dis ça au cas où :

Moumou
: Au début ça marchait bien. Puis, à un moment, le tuto s'est mis à faire des moyennes de couleurs dans chaque boucle. Avec des && et || logiques. Le problème évidemment, c'est que caml n'a pas d'entiers 32 bits. Donc les couleurs sont un type spécial "Color", sur lequel on ne peut pas faire d'opérations logiques. J'avais donc le choix entre utiliser une fonction de conversion de couleurs en un triplet d'entiers (lent) puis faire des opérations dessus (rapide), ou convertir les couleurs en un autre type de caml, Int32 (rapide) puis faire des opérations dessus (lent). Quelle que soit la solution utilisée, c'était super lent.

tu aurais sans doute pu convertir en un seul entier normal de 31 bits et faire tes opérations logiques dessus, surtout si tu ne te servais pas du canal alpha... et le compilo caml n'est pas capable d'optimiser les opérations sur les Int32 en faisant de l'unboxing ?)

Alors en fait ce n'est effectivement plus trop d'actualité, j'ai déjà commencé le projet en question, mais peut-être que ça interessera quelqun de savoir comment ça se passe pour le moment :

(tout ceci est à lire en sachant que je ne connaissais pas du tout Java avant d'avoir commencé ce projet, donc ça vaut ce que ça vaut, j'ai pas encore l'experience nécessaire)

- J'utilise finalement LWJGL, qui parait-il est ce qui est de plus rapide disponible pour faire de l'OpenGL en Java (c'est très orienté jeu, donc ça m'allait parfaitement).

- Le Java, c'est super lent, y'a même pas à discuter. J'ai cru que j'allais laisser tomber en traduisant mon loader de ghoul2 (des modèles 3D animés) de C++ à Java : fps divisés par un facteur entre 5 et 10, et en plus la version C++ aurait pu être accelerée un peu, pas la version Java (cf point suivant).

- Ça rejoint ce que dit Moumou : les entiers font 32 bits en Java, donc pas trop de problèmes de ce coté-là (par contre ils sont tous signés, pour lire des fichiers binaires qui contiennent des 'unsigned int' c'est super pratique); par contre une des optimisations de base d'OpenGL consiste à passer par des Vertex buffers (et TexCoord buffers, Color buffers, etc, c'est le même principe), qui permettent (en gros) de tout afficher d'un seul coup en passant un gros tableau de points plutôt que de tracer chaque point un à un. Le problème, c'est que bien sûr les tableaux de Java qui sont des objets ne sont pas contigus en mémoire (à vrai dire je sais pas comment c'est foutu, et je veux pas le savoir ^^), donc LWJGL propose des fonctions qui créent des "FloatBuffer", "IntegerBuffer", etc, qui eux sont utilisables avec OpenGL. Mais le remplissage de ces structures est tellement lent qu'au lieu d'optimiser, on perd des FPS. Bref, le bonheur.

- Beaucoup d'autres surprises que j'ai la flemme de détailler, comme le garbage collector qui se met en route quand ça le chante en provoquant un bon gros coup de lag dans l'application \o/

Au final (enfin si on veut, j'en suis à 25% de mon projet), ça marche, mais je suis assez dégouté qu'on m'ait imposé Java pour faire ce truc tellement j'aurais pu obtenir un meilleur résultat avec un langage mieux adapté. Java n'est pas mauvais du tout comme langage (enfin bon il a des défauts mais dans l'ensemble je le trouve plutot pas mal foutu), mais absolument pas adapté pour faire des jeux, même simples.

Pollux :
(bon c'est HS, mais je dis ça au cas où :

Moumou
: Au début ça marchait bien. Puis, à un moment, le tuto s'est mis à faire des moyennes de couleurs dans chaque boucle. Avec des && et || logiques. Le problème évidemment, c'est que caml n'a pas d'entiers 32 bits. Donc les couleurs sont un type spécial "Color", sur lequel on ne peut pas faire d'opérations logiques. J'avais donc le choix entre utiliser une fonction de conversion de couleurs en un triplet d'entiers (lent) puis faire des opérations dessus (rapide), ou convertir les couleurs en un autre type de caml, Int32 (rapide) puis faire des opérations dessus (lent). Quelle que soit la solution utilisée, c'était super lent.

tu aurais sans doute pu convertir en un seul entier normal de 31 bits et faire tes opérations logiques dessus, surtout si tu ne te servais pas du canal alpha... et le compilo caml n'est pas capable d'optimiser les opérations sur les Int32 en faisant de l'unboxing ?)

Pour le canal alpha, je ne me souviens plus si je l'utilisais ou pas. Enfin de toute façon il n'y avait tout simplement pas de fonction color->int donc c'était pas envisageable. Et pour les Int32, je ne sais pas si il optimise ou pas, mais il se trouve que c'était lent.

Bob > Pour les problèmes de gc, il existe un tas de méthodes qui évitent les "pauses" lors de la garbage collection. Et comme toute la recherche sur les gc se fait avec java, il doit y avoir moyen de trouver des trucs déjà tout prêts.

Heu juste une question con, mais à vrai dire j'ai jamais cherché la réponse : on peut détruire soi même un objet qu'on a "new-é", quand on est sûr qu'il ne servira plus, ou bien il sera obligatoirement détruit lors du garbage collect ?

Ca me paraît assez difficile sachant que java ne peut pas savoir si l'objet n'a effectivement plus aucune référence, ou non. Parce qu'il ne s'agit pas uniquement de ne plus jamais utiliser l'objet : le dit objet peut très bien être référencé par exemple dans un champ d'une classe qui existe toujours. Bien sur, si t'as bien fait le design de ton programme, ça ne devrait pas être le cas, mais ça, java ne peut pas le savoir.¹

Par contre tu dois pouvoir décider de quand tu veux lancer le gc.

¹ il existe une méthode de gc assez triviale qui permettrait de le savoir, c'est le reference counting. En gros, pour chaque objet, on garde dans l'environnement un compteur du nombre de références vers cet objet, compteur qui est automatiquement incrémenté et décrémenté. Le gc se résumerait alors à supprimer un objet dès qu'il n'a plus de référence (enfin, c'est tout de même un peu plus compliqué, il faut aussi gérer le cas des références circulaires). En théorie, c'est très joli comme système, aucun objet ne vit plus longtemps que ce qu'il a à vivre, et l'algorithme de gc est simple. En pratique, l'incrémentation et la décrémentation des compteurs sont réalisées tellement souvent dans le programme que l'impact sur les performances est énorme, nettement plus important que pour des gc classiques.

En pratique si tu met toutes le références a cet objet a null, il devrait être détruit au prochain garbage collector que tu peux forcer avec un System.gc().
C'est particulièrement utile en J2ME.

Moumou
: Ca me paraît assez difficile sachant que java ne peut pas savoir si l'objet n'a effectivement plus aucune référence, ou non.

Justement, c'était le but de la question : je me fiche que lui le sache ou non, je voulais le détruire quand moi je sais qu'il ne sera plus jamais utilisé

(sinon je vais pê suivre le conseil d'Uther, merci )

Au fait le gc et la 3d ça marche bien ensemble, cf http://wiki.beyondunreal.com/wiki/Garbage_Collection

c'est pas vraiment pareil : ils disent qu'ils ne nettoient à peu près qu'à chaque changement de niveau, et que la garbage-collection au cours d'un niveau n'apporterait pas grand-chose... ça n'a rien à voir avec Java, qui est obligé d'allouer des quantités gigantesques de mémoire sur le tas, donc t'as forcément des garbages collections à un moment inopportun... enfin cela dit il existe peut-être comme tu le disais des GC alternatifs (incrémentiels), ça peut être une solution
par exemple http://java.sun.com/docs/hotspot/gc1.4.2/ ^^

All objects and actors in Unreal are garbage-collected using a tree-following garbage collector similar to that of the Java VM.

Après, peut être (sûrement même) que la stratégie pour déterminer quand lancer le gc est différente

Ben oui, c'est ce qu'ils disent :

Full Garbage Collection in Unreal occurs automatically at a level change, or can be forced with a console command.

Et aussi :

Generally since most Objects are relatively small, the overhead for having the Objects stay around in memory is also relatively small
(with the gluttonous UWindowWindow being an exception of course).

ce qui n'est pas du tout le cas de Java...

Je pense qu'ils ne bouffent pas toute la RAM, parceque comme ils le disent, ils sérialisent leurs objets, ce qui peut aussi se faire en java.

je comprends pas ce que tu veux dire ? le fait de sérialiser une partie de ta mémoire en java ne va t'aider à rien du tout, si par ailleurs tu alloues des 10aines de Mo de mémoire par frame, le gc sera de toute façon obligé de faire une passe de temps en temps...

Mais pourquoi allouerais tu des 10aines de Mo par frame ?

Euh, se restreindre à n'appeler que des procédures qui n'allouent *aucun* nouvel objet, ça me paraît un peu difficile, même en faisant des gros efforts style tout allouer dans des tableaux gigantesques au début... Je suis sûr que même les fonctions de LWJGL doivent allouer des nouveaux objets, et ne parlons pas de la lib standard de java ^^

Heu en parlant de performance java, j'ai un problème: c'est le temps que met une apps java à se lancer (10 sec). Ce temps est beaucoup trop long surtout pour le peu de code que j'ai (et qui fait pas des choses extraordinaires).
QQn à une solution pour que cela se lance plus rapidement?

merci

utiliser gcj au lieu de la jvm ?

Le problème c'est que java fait une vérification de l'intégrité du code avant chaque lancement, ce qui prend du temps, en plus du chargement de la JVM elle même.
D'ailleurs en J2ME cette étape n'est pas faite a l'exécution, elle doit être réalisée après la compilation. Mais je ne pense pas que ca soit possible en J2SE

Pollux
: Euh, se restreindre à n'appeler que des procédures qui n'allouent *aucun* nouvel objet, ça me paraît un peu difficile, même en faisant des gros efforts style tout allouer dans des tableaux gigantesques au début... Je suis sûr que même les fonctions de LWJGL doivent allouer des nouveaux objets, et ne parlons pas de la lib standard de java ^^

Bah théoriquement dans un jeu, une fois que c'est "lancé", il est possible de ne plus avoir grand chose à allouer; c'est ce qu'on fait pour limiter ces coups de lag justement, et ça implique effectivement des tableaux assez monstrueux dans les structures, mais c'est clairement plus efficace qu'au début où on new-ait tout au moment où ça a besoin d'être utilisé. LWJGL n'est qu'un bind sur OpenGL, je sais pas trop comment ça marche mais je pense pas qu'elle alloue grand chose

Je pense qu'il est largement possible de coder des jeux dans des langages style java ou caml. Il y a bien un fps en haskell, qui tourne très bien, donc pourquoi pas ? Par contre, c'est sûr que ça demandera nettement plus de travail et de bidouillage qu'avec un langage fait pour manipuler la mémoire à bas niveau.

bah... ça dépend, déjà en caml j'aurais tendance à penser que c'est nettement plus réalisable qu'en java (on a un groupe en sup qui a fait un jeu 3D cell-shading en caml y'a pas longtemps, et ça tourne nikel); après ça dépend de ce que tu considères comme correct.
pour l'instant on a des bsp de quake3, des modèles ghoul2 de soldier of fortune 2/jedi academy, ça tourne à 80fps... donc on peut considérer ça comme jouable, mais y'a qu'un seul perso affiché, les effets graphiques sont très très pauvres, et surtout l'équivalent en C[++] tournerait facilement 10 fois plus vite. c'est techniquement possible, mais ça reste inutile pour autre chose que le défi amha

Zephyr :
bah... ça dépend, déjà en caml j'aurais tendance à penser que c'est nettement plus réalisable qu'en java (on a un groupe en sup qui a fait un jeu 3D cell-shading en caml y'a pas longtemps, et ça tourne nikel); après ça dépend de ce que tu considères comme correct.
pour l'instant on a des bsp de quake3, des modèles ghoul2 de soldier of fortune 2/jedi academy, ça tourne à 80fps... donc on peut considérer ça comme jouable, mais y'a qu'un seul perso affiché, les effets graphiques sont très très pauvres, et surtout l'équivalent en C[++] tournerait facilement 10 fois plus vite. c'est techniquement possible, mais ça reste inutile pour autre chose que le défi amha

Oui, mais vous n'avez pas encore bidouillé le gc, si ?

Moumou :
Je pense qu'il est largement possible de coder des jeux dans des langages style java ou caml. Il y a bien un fps en haskell, qui tourne très bien, donc pourquoi pas ?

Oui, absolument, je dis juste que ces langages ne sont pas conçus pour ne pas allouer de mémoire, et que donc le GC est bien obligé de tourner... (on peut juste faire des hacks pour qu'il tourne moins)
En revanche le fait que le GC tourne n'implique pas nécessairement des saccades ou un ralentissement, si le GC est adapté aux jeux ça ne doit poser aucun problème

Moumou :
Oui, mais vous n'avez pas encore bidouillé le gc, si ?

Euh, c'est pas du tout dit que la différence de performances soit liée au GC...