Discussion :

[loka]

Message de Mat.M 25/07/2008 à 16h44

Java à une meilleur productivité que C++ donc potentielement un prix de jeux moins cher

C'est un argument absolument faux parce que
-et d'une les couts de développement des jeux vidéos explosent .
Quand on voit Electronic Arts qui rachète 2 studios de création de jeu vidéo pour 800 millions..
Donc Java ou C++ ou QBasic pour un jeu vidéo cela ne changera rien.
Faire un jeu vidéo entièrement en Java ne coutera vraiment en rien moins cher qu'un jeu en C++.
Parce que de toute façon la boite de jeu devra payer des graphismes et concepteurs qui ont du talent.

-et de 2 , la conception d'un jeu vidéo c'est pas comme un ERP ou un progiciel de gestion ( genres de projets informatiques pour lesquels le développement Java est évidemment plus adapté )..
un titre de jeu vidéo lancé sur le marché ne ressemblera jamais à un autre fort heureusement car ce qui prime essentiellement c'est pas la productivité mais le coté conceptuel et créatif pour la réalisation d'un jeu vidéo

[loka]

Message de Mat.M 25/07/2008 à 16h49:

Le surcoût mémoire d'une JVM est de l'ordre de 4 Mo il me semble (en tout cas c'est dans cet ordre de grandeur).

??
Cela m'étonnerait fortement ; je doute que la JVM ne nécessite que de 4Mo pour s'initialiser mais bien plus pour allouer de la mémoire pour la pile de variables internes.
Il y avait un message interne de Sun microsystems il y a fort longtemps qui stipulait que tout programme Java requierait beaucoup de mémoire.
Même si Sun a fait des progrès sur sa JVM je suis persuadé que celle-ci requiert bcp d'allocation mémoire pour être initialisée

[loka]

Message de TanEk 25/07/2008 à 17h07:

??
Cela m'étonnerait fortement ; je doute que la JVM ne nécessite que de 4Mo pour s'initialiser mais bien plus pour allouer de la mémoire pour la pile de variables internes.
Il y avait un message interne de Sun microsystems il y a fort longtemps qui stipulait que tout programme Java requierait beaucoup de mémoire.
Même si Sun a fait des progrès sur sa JVM je suis persuadé que celle-ci requiert bcp d'allocation mémoire pour être initialisée

Sous linux avec la JVM 6 et un hello world en utilisant l'utilitaire top je vois une mémoire totale de 10Mo sachant que 5 Mo sont partagées par d'autres programmes et viennent de .so linkés au programme (librairies systèmes qui sont aussi utilisées et chargées de toute manière dans un JV donc je ne les prends pas en compte). Donc le surcoût de la JVM est ici de 5Mo. Ce qui n'est pas loin des 4Mo que je disais... Et SUN a insisté pour dire qu'il ferait un effort pour réduire encore un peu cette taille dans la prochaine version 7.

[loka]

Message de screetch 25/07/2008 à 18h13:

Sous linux avec la JVM 6 et un hello world en utilisant l'utilitaire top je vois une mémoire totale de 10Mo sachant que 5 Mo sont partagées par d'autres programmes et viennent de .so linkés au programme (librairies systèmes qui sont aussi utilisées et chargées de toute manière dans un JV donc je ne les prends pas en compte). Donc le surcoût de la JVM est ici de 5Mo. Ce qui n'est pas loin des 4Mo que je disais... Et SUN a insisté pour dire qu'il ferait un effort pour réduire encore un peu cette taille dans la prochaine version 7.

le surcout est proportionel a la taille du code; si pour un hello world c'est 5 megs, il est peu probable que pouru ne grosse appli ca reste 5 megs

[loka]

Message de TanEk 25/07/2008 à 18h19:

le surcout est proportionel a la taille du code; si pour un hello world c'est 5 megs, il est peu probable que pouru ne grosse appli ca reste 5 megs

Mais de quel surcoût tu parles ? Il y en a pas ! J'ai argumenté et expliqué pourquoi il y en avait pas (à part la jvm de 5 M et les quelques octes en plus d'infos sur les classes qui font grand maximum 1M sur un programme type jeu vidéo mais ça peut être ça comme ça peut être dix fois moins, les 1M c'est vraiment une fourchette super large). Alors moi je veux bien de ton peu probable mais argumentes un peu. Le surcoût ne sera jamais supérieur à 10 M ça c'est sûr et certain (je pense pour un 6-7M).

[loka]

Message de bafman 25/07/2008 à 19h49:

Je ne suis pas entièrement d'accord car vu la complexité des objets, ces derniers sont maintenant traités en tableaux d'où la création des VBO, etc. Et en java les tableaux sont contigus en mémoire... Le seul moment où on travaille pixel par pixel c'est au niveau des shaders qui est au niveau de la carte graphique. Donc la question de savoir dans quel langage on programme ne se pose pas : on programme en shader.

Donc cette histoire de problème de cache... Je ne vois pas vraiment à par dans des cas très spécifiques peut-être et encore et dans ce cas on passe en natif.

certe, mais ton VBO va contenir une structure de vertex alloué dynamiquement, qui, Java oblige, vont contenir au minimum un pointeur vers la meta class (plus, très probablement quelques octets en plus mais je ne suis pas capable de les quantifier). Si on prend l'exemple d'un bête float3 dans le tableau, pour 12 octets d'info, on a 4 octets de surcout par objets qui peuvent être évité en C++...

De plus un float prend autant de place en java qu'en natif en mémoire...

vrai pour un type natif, potentiellement faux pour des classes (ça dépend du fait que la classe contienne des fonction virtuelles en C++)

Java le fait plutôt bien : si tu crées un objet contenant des types primitifs, il va allouer d'un coup toute une zone mémoire pour stocker ça. Donc on a une certaine proximité des données qui est tout de même assurée. Java ne marchera pas pour des cas vraiment très particuliers d'algorithmes avec des optimisations à mort sur les caches ce qui est très rare. Et d'ailleurs puisque vous insistez tant sur ce point, sortez-moi un algorithme que vous connaissez et dont vous pouvez me filer les sources qui pourrait (je dis bien pourrais) avoir des performances lamentables en Java.

Java peut tenter effectivement de regrouper les objets au même emplacement mémoire, mais on a aucune garanti qu'il va effectivement y arriver. Avec les allocation par pool en C++, on peut garantir ce genre de chose. Pour les jeux, c'est une préoccupation quotidienne, notemment sur les consoles dont les processeurs n'ont pas de préfetcheur hardware.

Sinon, concernant l'algo, le système sur lequel je bosse au quotidient est un bon exemple.
C'est un système d'évaluation d'arbre d'expression avec systeme d'inference de type qui nous oblige a avoir une description non typé des expression. Ce système est utilisé pour effectuer des calculs de symulation sur des lots importants de particules. On a donc 2 domaine dans lequel Java ne nous permet pas d'obtenir des perfs correctes :
- les expression etant non typé mais statiques, on peut typer le tout à l'execution, pour créer une deuxieme version de l'arbre d'evaluation, totalement typé elle. Ceci est permit par un passage unique entre le monde dynamique et le monde statique, avec beaucoup de code a base de template qui nous génere l'ensemble des combinaisons possible. Ceci génere un executable de taille très importantes, mais les perfs sont sans comparaisons avec un système purement dynamique. Ceci n'est pas réalisable en Java car il n'existe pas d'equivalent réel aux template d'un point de vue génération de code à la compilation. Notamment, un gros aventage de cette technique est de nous eviter un nombre important d'appels de fonctions virtuelles à l'execution (car le type etant connu statiquement, la bonne méthode peut être appelé au bon moment sans indirection)
- Le deuxieme point concerne justement la localité memoire et la gestion du cache processeurs. On a des profilers qui tournent régulierement pour s'assurer que l'utilisation du cache est suffisament efficace pour que les calculs sur des batches de particules s'effectue dans des temps supportable pour du temps réel. (on peut monter jusqu'a 7/8 millions de particules evolué par seconde en plus du rendu normal)

Le fait de désallouer tout d'un coup comme le fait le garbage collector est un gain de temps et une assurance que la mémoire ne sera pas fragmentée et donc un gain de perf CONSTANT. D'ailleurs les benchmarks ont prouvé plusieurs fois que l'allocation mémoire de java était plus rapide que l'allocation native.

sauf quand on utilise massivement les allocation thread local et par pool en C++ qui permettent d'avoir un cout d'allocation et de desallocation nettement inferieur à celui de Java... D'ailleurs, on utilise même pas l'allocateur standard de windows chez nous même pour les allocations standard

Donc comme il n'y a pas de problème on peut faire du AAA en Java. Je pense que avec la JVM actuelle de sun on a une perte de performance de l'ordre de 10% et encore je vois large... Les seuls problemes de perfs sur l'implémentation de la JVM actuelle (et je parle bien de l'implémentation, pas du langage en lui-même !) que je vois et qui m'embêtent (il doit y en avoir d'autres mais là encore j'insiste : ce n'est qu'un soucis d'implémentation et pas de limite du langage en soit) c'est :

- la librairie Math qui est en fait liée à la librairie StrictMath alors qu'elle ne le devrait pas et donc a des performances moisies, mais rien n'empêche de faire sa propre librairie Math méga optimisée ;
- en monde -client les compilations de codes chauds ne sont pas faites assez vite mais ceci devrait être arrangé avec la JVM 7 qui n'aura plus de monde -client ou -server mais un hybride ;
- les constantes dans les boucles qui ne sont pas encore bien gérées.

Mais ceci n'est que du détail et n'est qu'un soucis d'implémentation.

non justement, il y a des problèmatique intrinseques au langages qui font qu'on peut toujours, a pleteforme hardware quivalente, faire mieux en C++ qu'en Java. Le tout etant de savoir si le surcout en terme de developpement des optimisation bas niveau vaut le coup (et le coût). A l'heure actuelle, la difference est suffisante pour que les gros développement restent en C++

[loka]

Message de TanEk 25/07/2008 à 21h02:

comme je te l'ai dit, un exe une fois compilé en natif fait dans les 10 megs (pour un jeu complet, hein). ce sont 10 megs de code compilé, il faut bien les avoir en mémoire aussi, que ce soit du code interpreté (du bytecode) ou precompilé.
Or, la JVM pèse également le poids d'un exe, puisque c'est un exe.

Mais tu le fais exprès ou tu le fais exprès ? Ton code compilé en C++ qui fait 10 megas en bytecode il ferait sûrement 7 mega et la JVM fait 5 méga en mémoire, que ce soit un hello world ou un jeu de 100 méga de code. Donc le surcoût par rapport au C++ est de 5 méga de jvm en plus qui est de plus en plus rattrappé par le fait que le bytecode est moins gros que le code généré par les compilos même en prenant en compte l'autre surcoût de la compilation des points chauds par la jvm (donc plus ton programme est gros, moins t'as du surcharge en % global du fait d'avoir une jvm).

Pour bafman :

Enfin un exemple où le C++ est gagnant par rapport au java de par son type de langage statique à l'exécution. Là je suis d'accord cela fait partie des 1% de problèmes où le java n'a pas encore sa place.

Après pour le cache je te laisse seul juge mais comme on le disait plus haut, rien n'empêche de passer ces parties critiques en C++ et de les appeler en JNI. Ce sera peut-être légèrement moins performant qu'en pur C++ (quoique... comme je disais on peut gagner autre part...) mais ce serait réalisable. Le sujet rappelons-le est Java est-il adapté aux jeux-vidéos ou plus clairement peux-t-on faire des jeux de haute qualité en Java. Penses-tu bafman que si on y mettait les ressources nécessaires on ne pourrait pas créer un moteur à base de java et peut-être de C++ pour les parties critiques (les parties critiques c'est même pas 5% du code hein...) qui rivalise avec les performances d'un moteur pur C++ ou qui s'y en approche assez pour faire tourner du code AAA ?

[loka]

Message de screetch 25/07/2008 à 21h17:

Mais tu le fais exprès ou tu le fais exprès ? Ton code compilé en C++ qui fait 10 megas en bytecode il ferait sûrement 7 mega et la JVM fait 5 méga en mémoire, que ce soit un hello world ou un jeu de 100 méga de code. Donc le surcoût par rapport au C++ est de 5 méga de jvm en plus qui est de plus en plus rattrappé par le fait que le bytecode est moins gros que le code généré par les compilos même en prenant en compte l'autre surcoût de la compilation des points chauds par la jvm (donc plus ton programme est gros, moins t'as du surcharge en % global du fait d'avoir une jvm).

le code java compilé n'est plus en bytecode, il est en instructions asm. et il n'y a pas de raison que l'asm généré par java soit plus petit que l'asm généré par un compilo C++. PAR DESSUS le code généré par Java, tu rajoutes la JVM, et PAR DESSUS le code assembleur de la JVM.

[loka]

Message de sachem 25/07/2008 à 21h41:

"Le langage Java est-il adapté pour les jeux vidéo ?"
La réponse est simple :
Oui si l'équipe de prod est composée de développeurs Java, sinon... non

Parce qu'on fera jamais programmer efficacement en C++ un aficionado du Java, et vice versa...

Sinon hors sujet, vu qu'il y a sans doute quelques experts dans cette discussion, est-ce que la technique du MDA est utilisée dans la production de certain jeux vidéo ?

[loka]

Message de TanEk 25/07/2008 à 21h46:

de plus, comment peux tu dire que le cout de la JVM est constant quel que soit la taille de l'executable ? si tu as plus de classes, tu as plus de code a compiler dynamiquement, tu as beaucoup plus de choses chargées...

Mais le code C++ est plus lourd et plus gros (voir l'exemple de bafman avec les templates qui génèrent beaucoup de codes) que le bytecode. Et java ne compile pas TOUT le programme (environ 20% d'un programme vu qu'on dit qu'un programme a 20% de zones critiques) ! Renseignes-toi sur la technologie JIT (Just In Time compilation). Je peux t'assurer que les fichiers jar contiennent uniquement du bytecode et pas de asm. La compilation est faite à la volée, à l'exécution.

Donc l'un dans l'autre ça se compense presque (le bytecode java doit être environ 20% plus léger que le code C++ et java rajoute 20% de code compilé... 20% - 20% = 0%). Le gros du truc c'est les 5 mégas de la JVM qui sont là même pour un "Hello World". Et je rappelle une énième fois que lorsqu'une classe n'est pas utilisée par la JVM elle n'est tout simplement pas chargée en mémoire ! Alors que pour le C++ elle y est toujours en mémoire même si on l'utilise jamais (après y'a peut-être des utilitaires pour cleans les dlls mais je ne les connais pas... et je ne pense pas que ça existe).

Là où on perd 4 octets pour chaque objet crée c'est les objets n'ayant pas de méthode virtuelle (style les float3 comme disait bafman). Mais il n'y en a pas dix-milles en mémoire. En général on ne manipule pas des float3 mais des tableaux de float (et là c'est pareil en java ou en C++, allez 4 octets pour chaque tableau crée... y'en a combien des tableaux en mémoire ? ) ou alors des float3 de façon temporaire (donc à un moment donné il n'y en a pas des masses en mémoire) pour des algorithmes ou comme attribut pour des objets (et y'en a pas des millions des objets graphiques...). Je conçois qu'on puisse perdre à cause de ça maximum 1mo. Donc 5 Mo + 1 Mo + allez 4 mégas pour être large on arrive à 10 Mo. Coût du Java en mémoire par rapport à C++ : 10 Mo maximum.

[loka]

Message de DzzDDzzD 26/07/2008 à 04h19:

le code java compilé n'est plus en bytecode, il est en instructions asm. et il n'y a pas de raison que l'asm généré par java soit plus petit que l'asm généré par un compilo C++. PAR DESSUS le code généré par Java, tu rajoutes la JVM, et PAR DESSUS le code assembleur de la JVM.

ben en fait si, parceque suivant la pateforme il sera compilé differemment, les optimisation dynamiques sont possibles.

Ceci n'est pas réalisable en Java car il n'existe pas d'equivalent réel aux template d'un point de vue génération de code à la compilation

java c'est de l'objet poussé à l'extreme, tout est objet vu de dedans : le prog, le pc, les methodes, les parametres des methodes etc... tu peux tout controler tout refaire en runtime.

http://java.sun.com/j2se/1.3/docs/ap.../Compiler.html

Les casual Games c'est une chose, les jeux du commerce une autre...
les "casual games" c'est une niche économique ou bien segment économique.
Rien ne prouve que cela soit un modèle économique efficace...

ouch surf un peu ca genere des milliards et c'est en plein expansion et c'est bien des jeux, et on parle de jeux dans ce topic.

Un programme compilé de façon optimisée prend beaucoup plus de place que du bytecode java

ca c'est claire, du point de vu de la taille (je parle de taille de transport le bytecode Java est largement inférieure au compilé).

Si on considere la JVM comme faisant partie du system (comme une librairie system genre directx), un hello word en java prend qq octets (400 octets à peu pres). Apres la JVM va compiler ce bytecode avec du code specifique à la plateforme si necessaire (utilisation de registres speciaux si possible, compil en 64 ou 32 bit) et le dev n'a pas a faire de if(monSystemeDisposeDe)... pour faire ces optimisations.

Le principe d'une Virtual Machine est en fait vraiment tres fort et devrait etre repris par d'autres languages. Apres celle de Java manque peutetre encore il est vrai de quelques optimisations mais c'est ca aussi qui est génial dans ce principe c'est qe le prog va s'améliorer avec le temps ! plus le temps passera et l'utilisateur mettra à jour ca JVM plus le prog/jeu, et tout les prog Java qu'il a, seront compilés de facon optimal à son system à chaque execution, et si il change de pc ou instal le jeux sur un autre pc c'est idem c'est comme si il avait chargé la version correspondante à sa machine sur le site de l'editeur, sauf que la l'editeur n'a pas à gerer plusieurs versions et le dev n'a pas à faire des optimisations en fonction des differentes cibles possibles et les optimisations qui arriveront dans les hardwares futurs seront pris en compte (par la JVM) contrairement à du language statique.

Aussi j'ai "lu dire" qu'on peu toujours faire mieu en C++ quand Java et c'est un peu bateau... c'est vrai si on prend une plateforme en particuler et qu'on optimise, mais dans ce cas la on peu aussi faire mieu en assembleur quand C++ y'a toujours qqs instructions en trop dans la version compilée, un peu tres bien coder une appli Web en C++ aussi et ne pas utiliser PHP par exemple ...

en fait je dirais que Java est (à l'exception des jeux programmés pour une plateforme cible particulière type Console ou Window ou etc ... et necessitant pour des besoins de perfs (FPS AAA par exemple) l'ajout d'optimisations specifiques à la pateforme en question) le language de loin le mieu adapté au dev de jeux, et encore plus pour les jeux Web necessitant d'etre cross-platforms et leger.

par exemple ce petit FPS tres sympa http://nightsquad2.freenet.de/nightsquad2/?lan=en qu'on instal pas et auquel on peu jouer de n'importe ou, sur une config tres modeste. (bon pas un exemple parfait car il tourne que sur window je crois... mais bon)

petites précisions aussi :
- developpez par une seule personne (pour une these)
- à peu pres 80 mo tout compris (en gros la 3d et les textures)
- uniquement window mais necessite pas grand chose pour le faire touner sur linux et mac.

donc voila un jeu qui n'a pas demandé bcp de ressource (1 dev + 1 designer) qui fonctionne sur le Web, et qui peu toucher trois type de platformes cibles (win/mac/lin). si fallait refaire ca en C++, ca serait galère ou pas ? pour que ca demarre dans le navigateur, que ca s'nstall tout seul, que prog et données tiennent dans 80 Mo, que ca fonctionne sur Mac, Linux et Window, et tout ca avec un seul dev ?

[loka]

Message de eclesia 26/07/2008 à 11h48:

n'oubliez pas qui sont les piliers du dev de jeux vidéo : Intel, NVidia, AMD/ATi et Microsoft, pas sun. il est fort probable quel e langage C# devienne vite tres tres adapté aux jeux, alors que le java sera toujours en retard, etant donné qu'il est poussé uniquement par Sun.

Les jeux se basent sur des normes, OpenGL ou DirectX pour la pluspart. du moment que JOGL suit les dernieres normes opengl on fait exactement la meme chose qu'en C++. qu'il y est 2 ou 30 entreprise derriere n'y change rien.
De plus JOGL a été fait Sun et NVidia.

le probleme de Java c'est qu'il ne gere pas le temps reel

Contre exemple avec un moteur java parfaitement fluide : http://www.avengina.org/?target=home

[loka]

Message de eclesia 27/07/2008 à 12h26:

visiblement aucun utilisateur de c++ ne veut admettre que le cout memoire de la machine virtuelle est faible.

Et bien on va le demontrer

Voici le code utilisé :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public class Main {
    public static void main(String[] args) {
        new Thread(){
            @Override
            public void run(){
                try {
                    sleep(30000);
                } catch (InterruptedException ex) {}
            }
        }.start();
    }
}

Un thread qui attend 30secondes.

Voici la consommation memoire de ce morceau de code :

En bref on voit que la jvm a alloué 4,5Mo environ a l'application mais que celle ci n'en utilise que 2.

J'ai ensuite lancé cette application comme un jar executable et voici le resultat réel :

On voit 8,2Mo utilisé.
On sait que 4,5Mo sont pour l'application.

On est donc a 3.7Mo pour le fonctionnement de la JVM.

[loka]

Message de eclesia 27/07/2008 à 12h49:

Hello world != real world

Je ne fais que montrer que tes arguments a l'encontre de la consomation memoire de java ne sont pas fondés.

Tanek te l'a dit à plusieurs reprises et j'en apporte un exemple.
De plus tu peux tres bien reproduire cet exemple sur ton pc.

Certes la taille pour la jvm va grossir avec le chargement progressif des classes necessaires. Il en va de meme pour une appli C++ qui charge des DLL.

J'ai montré que la jvm a une taille initiale de 4Mo (meme un peu moins). et non 20 comme beaucoup le pense.

[loka]

Message de screetch 27/07/2008 à 13h08:

encore une fois, hello world != real world, ce que tu dis ne "prouve" pas que la JVM a un cout statique de 4 megs, sur une appli plus grosse le cout augmentera.

vous avez aussi bazardé des chiffres sur le bytecode, comme quoi ca prendrait 20% de moins que du vrai code. je veux bien voir ca aussi (meme si c'est possible, je veux bien la source).

[loka]

Message de eclesia 27/07/2008 à 13h45:

ce que tu dis ne "prouve" pas que la JVM a un cout statique de 4 megs, sur une appli plus grosse le cout augmentera.

Tu ne lis que ce que tu veux bien lire.Je viens de dire la meme chose juste avant :

Certes la taille pour la jvm va grossir avec le chargement progressif des classes necessaires. Il en va de meme pour une appli C++ qui charge des DLL.

vous avez aussi bazardé des chiffres sur le bytecode, comme quoi ca prendrait 20% de moins que du vrai code. je veux bien voir ca aussi (meme si c'est possible, je veux bien la source).

Je ne suis pas en mesure de fournir ce genre de demonstration, je ne sais pas comment le faire .
(meme si ca me parait logique vu que le bytecode java n'a pas toute les contrainte d'un OS inscrite dedans, il est plus abstrait donc plus leger)

Je reste a ma place, je ne parle que de ce que je sais.

Alors je te retourne la question : Prouve nous que du bytecode java et plus gros que celui du C++. Apporte quelque chose de concret dans le debat pour une fois.

[loka]

Message de eclesia 27/07/2008 à 16h59:

Mettons que tu voies que ton programme d'exemple consomme 8,2 megs et que tu ne disposes que de 8 megs; comment ferait tu pour éliminer quelques allocations et tout faire rentrer ?

je viens d'englober mon bout de code dans une boucle histoire de créé un millier de thread. la quantité memoire consommer (dans le gestionnaire de processus) est la meme. juste le % d'utilisation du heapsize (les 4Mo alloué a l'appli) qui a augmenté.

pour 1000 thread l'utilisation de memoire a augmenter d'environ 700Ko dans le heap.Ce qui fait moins d'1 Ko par thread.

Autrement dit (vu que tu n'as pas l'air de comprendre) tu as un cout fixe minimum d'environ 4Mo pour la JVM, a quoi s'ajoute environ 1Mo pour l'appli vide.
Et apres tu ajoutes les objects.

Ca ne sert a rien de d'echanger plus loin si tu ne peux pas comprendre ce fonctionnement.

Edit : voila les resultats, qu'on ne m'accuse pas de ne pas fournir des preuves.



schema 1 : utilisation du heap
schema 2 :nombre de thread

[loka]

Message de Tarul 27/07/2008 à 20h45:

je ne vois pas le rapport avec ma question...
et ca ne prouve toujours pas que le surcout de la JVM n'augmente pas avec le nombre de classes et la taille du code...

si tu as trop de memoire consommée et que tu veux modifier ton programme pour libérer de la place, comment peux tu savoir quelles allocations sont grosses et ou tu pourrais appliquer des optimisations mémoires ?

Il est possible de voir avec l'outil de profiling de netbeans (et sans doute les autres) les objets qui survivent longtemps au GC et aussi la taille de leur empreinte mémoire. Cela permet de voir les fuites de mémoires d'un programme java et donc d'optimiser sa consommation mémoire.

[loka]

Message de eclesia 27/07/2008 à 22h27:

si tu as trop de memoire consommée et que tu veux modifier ton programme pour libérer de la place, comment peux tu savoir quelles allocations sont grosses et ou tu pourrais appliquer des optimisations mémoires ?

Pour ca Java propose les SoftReference, se sont des "pointeurs" particuliers.
Un object dont tu gardes la reference avec un de ses "pointeur" existera tant que tu as de la place memoire. Si a un moment la jvm arrive en saturation, elle supprimera ses objets.

Autrement dit tu predispose dans le code quel sont les objets qui pourront en cas de besoin etre supprimé.

La javadoc explique bien son usage dans les caches justement :
http://java.sun.com/j2se/1.4.2/docs/...Reference.html

[loka]

Message de Emmanuel Deloget 28/07/2008 à 12h41:

Si tu vend le jeux deux fois moins cher que sur WII je pense que ca peut le faire.....
Java à une meilleur productivité que C++ donc potentielement un prix de jeux moins cher

Dans un jeu AAA next-gen (même pour Wii, bien qu'on soit moins next-gen dans ce cas), ce qui coute le plus cher, ce n'est pas la partie programmation, c'est la partie artistique, très consommatrice en temps et en personnel (voir les credits de Red Steel (Wii) sur mobygames; ou, plus récemment, les crédits de GTA IV (PS3); dans les deux cas, la partie programmation est minoritaire, voire même anectotique dans le cas de GTA IV).

Le fait que Java ait une meilleure productivité ne va guère changer le fait qu'il faut plusieurs années/homme pour réaliser les différents assets (modèles, textures, sons, ...) et les mettre ensemble.

En ce qui concerne la productivité, certes le langage utilisé a un impact, mais il faut aussi trouver un moyen pour limiter le temps passés par les développeurs à se vautrer dans le plaisir procuré par le suivi inconditionnel de leur syndrome NIH propre. Bref: les développeurs utilisent des librairies, voire des moteurs complets - qui sont modifiés pour les besoins d'une production (Selon Mark Rein, ils sont utilisés tels quels (cf. Game Engine panel à la GCDC'07)). En supposant que le programmeur n'ai pas besoin de modifier le moteur, je ne vois pas quel gain de productivité Java pourrait apporter - le code qui utilise un moteur en Java ou dans un autre langage est sensiblement le même; cela dépends essentiellement de l'architecture du moteur, pas du langage utilisé).

Hello world != real world

Ce qui est ennuyeux. Il va faloir changer tout le texte des livres qui font un print "hello world!" pour le transformer en print "real world". Ca va couter cher aux éditeurs tout ça.

Quelqu'un a osé écrire que Java ne gère pas le temps réel. Je revois cette personne à Javolution et RT5J (quitte à radoter).

Quant aux jeux commerciaux utilisant Java (pour tout ou partie), voici une petite liste : http://safari.adobepress.com/0596007...e-CHP-1-SECT-6

Calmé?

Personnellement, oui, étant donné que je ne m'étais jamais énervé.

Pour ceux qui pensent que Java ne gère pas le temps réel, ils ont effectivement tort puisque Java a été conçu pour gérer le temps réel. Pour ce qui est de la gestion du temps interactif (qui est une notion plus souple que temps réel), bien évidemment que Java le gère aussi. Comment afficher l'interface graphique d'une application fenêtrée sans cette notion ? Et si on est capable d'afficher une interface graphique complexe de (mettons) 640x480, qu'est ce qui nous empêche d'afficher des graphismes plus sophistiqué de la même taille ?

Quand à la liste: interessante, mais les seuls AAA qui sont listés n'utilise Java que pour la partie scripting (non, Tom Clancy's Politika n'est pas AAA, même pour l'époque; je ne me rappelle même pas en avoir entendu parlé à sa sortie (ni après, d'ailleurs)). On notera toutefois Runescape, que j'avais totalement oublié.

Le fait est quand même que peu de studio s'aventurent à faire des jeux entièrement en Java. Avec la pénurie actuelle de développeurs Java, ils ne vont pas se lancer maintenant, d'autant plus que le gain supposé n'est pas clair - si il n'est pas inexistant. Un risque difficile à mitiger, selon moi.

Cela ne veut pas dire que Java n'est pas adapté à la création de jeux vidéo (pourquoi est-ce qu'il ne le serait pas?), bien qu'à mon humble avis, la technologie proposée n'est pas - à l'heure actuelle - assez rapide pour prétendre rivaliser avec un mix entre le le C, le C++ et l'ASM (bein voui; comment pensez vous que les "shaders" PS2 étaient écrits?). Va-t-elle le devenir dans le futur? Peut-être. Cela provoquera-t-il un changement dans les habitudes de programmation des développeurs de jeux vidéo ? Probablement pas. Même si les performances d"un programme Java deviennent exactement identiques à celle du même programme écrit en C++ hyper-optimisé-de-la-mort, il n'en reste pas moins que la base de code C++ sera 100 fois plus importante que la base de code Java, que l'expérience accumulée avec C++ sera bien plus importante que celle relative à Java. Puisque le temps de développement d'un jeu sera sensiblement le même (car ne dépendant pas spécifiquement du langage de développement - cf. Torpex Games avec Schyzoid: le jeu, développé en C# avec XNA, a pris autant de temps à développer qu'un jeu utilisant C++ et DirectX, ainsi que les paragraphe précédent ou j'insiste sur l'importance des parties du développement périphériques à la programmation), il n'y aura aucun gain à passer à Java. La question de la multiplateforme se règle d'elle même: les jeux sont déja multiplateforme. La question des fonctionnalités offertes par le langage est elle aussi réglée: même si Java offre plus de fonctionnalités que C++ à l'origine, la future version de C++ se rattrape bien. De plus, certaines fonctionnalités de Java ne sont que d'un intérêt limité pour le développement d'applications intensives.

Dans ces conditions, pourquoi prendre un risque ?

Et puis, je n'aime pas du tout du tout le pardigme du .equals()