Discussion :

[loka]

[B]Message de TanEk 25/07/2008 à 12h56:[/B

J'ai fait du C++ puis du Java et au bout de 6 mois - 1 an je suis revenu vers C++ car je devais toujours passer par des bricolages en Java. C++ et un bon framework ( je ne parle pas de celui de microsoft ) est bien plus efficace que Java selon moi.

Quand Java n'avait pas les template je suis d'accord que dans certains cas il fallait bidouiller pour arriver à faire des choses aussi simples qu'en C++. Et c'est d'ailleurs pour cette raison que je ne me suis mis à Java que très récemment. Mais depuis que Java a cela (plus pas mal d'autres trucs), la puissance du langage C++ (et je ne parle qu'en terme de langage) est kif kif par rapport à Java (dans le sens où Java a certains trucs que C++ n'a pas et vice versa).

Pourrais-tu expliciter les bidouilles que t'étais obligé de faire en Java et pas en C++ ?

[loka]

Message de screetch 25/07/2008 à 13h42:

le probleme dans ces discussions, c'est que les developpements amateurs ont toujour eu et auront toujous 5 a 10 ans de retard sur l'industrie du jeu vidéo. La preuve, c'est que personne ici ne parle du futur, ni meme du present, mais tous parlent du passé. Les developpements amateurs s'etendent entre les clones de tetris et mario bros jusqu'aux clones de Quake III (2000...)

Le présent, c'est les processeurs multi coeurs (2 a 4) et les cartes graphiques multi coeur
Le futur, c'est les processeurs MASSIVEMENT multi coeurs (32 a 128) et les cartes graphiques generalistes multi coeurs (32 a 128 coeurs egalement)

qui ici programme en multi coeur ? et je parle pas de ceux qui savent faire new Thread et des lock de mutex a tout va, je parle de gens qui savent faire un flot d'execution continu sans mettre de lock global qui ferait passer un programme multithread en sequentiel.

Qui connait l'utilisation de Intel Thread checker ? qui peut me fournir une api JAVA similaire a l'api Intel Thread Building Blocks ?

personne evidemment (ou peu)

et pourquoi ces choses n'existent pas en JAVA ? car c'est Intel qui les fait, et que Intel a tout a gagner a faire vendre des jeux. En effet, les plus grosses pubs pour les plus gros processeurs sont les gros jeux récents, ceux qui marchent bien avec la config a 3000 euros. Si on attend sur Word pour faire vendre des nouveaux core 2 quad, c'est pas gagné...

Java n'a rien a gagner a suivre d'aussi pres l'actualité materielle, et a 5 bonnes années de retard sur les developpeurs de jeux qui travaillent en partenariat avec Intel, AMD/ATi et nVidia pour que lorsque le jeu sort, il utilise deja la pleine puissance des machines.


alors java est adapté pour les jeux qui ont été fait il y a 5 a 20 ans (exemple : sur mobile).
et la "recherche", les nouveaux paradigmes de programmation concurrentiels et le gain de cycles se font en C++.

or, 90% des gens qui s'essayent a la programmation de jeux s'essayent sur des vieux jeux, et ca marche donc bien en java. Mais les jeux commerciaux style action/FPS sont et seront fait en C++ pendant encore quelques années.

[loka]

Message de bafman 25/07/2008 à 13h51:

[disclaimer]
Je tiens a préciser que dans ce post, je parle uniquement de developpement de jeux 100% Java, pas de mix Java/C++/.Net/...
[/disclaimer]

les principaux problèmes de Java au niveau du développement de Jeux AAA mainstream sont connu depuis longtemps et sont intrinsèque à la plateforme.

Par exemple, la gestion mémoire incontrôlable.
Par incontrôlable, je veut dire qu'on ne peut pas maitriser précisément (et j'insiste sur le précisément avant qu'on ne me dise qu'on peut paramètrer la JVM ) la taille mémoire alloué ainsi que l'emplacement. La taille importe car quand on se retrouve avec des petits objets (des float3 ou des types de vertex compressé qui font quelques octets) qui sont très nombreux et auquels la VM ajoute un overhead de quelques octets pour chaque allocation, forcement, on explose vite la mémoire, et surtout on utilise plus de mémoire système que besoin et on ajoute du striding a la carte graphique, ce qui est mauvais aussi bien pour le transfert sur le port graphique et pour le cache de la carte graphique.
Le problème de l'emplacement mémoire, c'est qu'il est difficile en Java d'assurer que plusieurs objets d'un même type seront alloué dans des zones mémoire proche. Ceci est particulièrement utile dans les jeux pour garantir de bonne performance au niveau du cache processeur. Ceci peut être fait en C++ en utilisant des pool avec des allocation "in place". En Java, de part l'abstraction apporté par la VM, on ne peut pas garantir de genre d'optimisations...

il faut bien garder à l'esprit qu'une console comme la PS3, c'est 256Mo de mémoire système dont ~90Mo utilisé par l'OS. Du coup, si une JVM tournai dessus, on ne pourrai néanmoins jamais proposer de jeux mieux ou équivalent à ceux développé en C++ rien qu'a cause de ce surcout mémoire...

l'autre problème de la VM viens du garbage collector. Certes on peut le contrôler plus ou moins, mais dans tous les cas, le passage du garbage collector est le meilleurs tueurs de cache au monde et quand on fait un jeu temps réel, ce qui importe, c'est avant tout d'avoir un frame rate constant. Avec le garbage collector, on a un truc qui, plus ou moins régulièrement, nous fait des piques de frame rate...

A part ces problèmes qui se pose sur des titre AAA mainstream, il n'y a effectivement pas de problème à développer de jeux en Java. mais il faut bien garder à l'esprit que pour un editeurs, si il a le choix de pouvoir proposer plus pour un même support physique en choisissant le C++, il ne va pas chercher à passer à Java (sauf en cas e limites de budget, mais encore une fois, je parle de AAA )

[loka]

Message de FloMo 25/07/2008 à 14h15:

Pourrais-tu expliciter les bidouilles que t'étais obligé de faire en Java et pas en C++ ?

Accéder à du multimédia, intégrer et modifier du contenu web, utiliser des feuilles de style pour le rendu des éléments graphiques, concevoir des animations, enregistrer les préférences simplement, accéder aux répertoires par défaut du système, ... le tout en multi-plateformes, sans recoder.

[loka]

Message de kpouer 25/07/2008 à 14h17:

Accéder à du multimédia, intégrer et modifier du contenu web, utiliser des feuilles de style pour le rendu des éléments graphiques, concevoir des animations, enregistrer les préférences simplement, accéder aux répertoires par défaut du système, ... le tout en multi-plateformes, sans recoder.

Euh c'est quand même un peu vague. Par exemple enregistrer les préférences d'un utilisateur, je vois mal en quoi Java serait moins capable que C++ de le faire, c'est super basique non ?

[loka]

Message de bafman 25/07/2008 à 14h22:

Attention, ce débat est sur les capacité de Java pour faire des jeux vidéo, pas Java vs C++ qui existe déjà ici

[loka]

Message de FloMo 25/07/2008 à 14h23:

Euh c'est quand même un peu vague. Par exemple enregistrer les préférences d'un utilisateur, je vois mal en quoi Java serait moins capable que C++ de le faire, c'est super basique non ?

Justement, Java ira écrire dans un fichier ou quoi alors que C++ aura une fonction de lecture et une fonction d'écriture générique qui enregistre soit en XML ( standard Mac ) soit dans le registre ( standard Windows ) soit dans un fichier texte ( standard Linux ) . Un appel de fonction ( méthode statique plutôt ) seulement, pas une usine à gaz.

Mais le plus flagrant c'est pour le rendu web : je n'ai jamais réussi à le faire fonctionner correctement ( Windows ok, mais Linux plante ) dans Java alors que je l'ai fait en 2 minutes en C++.

[loka]

Message de FloMo 25/07/2008 à 14h25:

Pour recadrer sur le jeu vidéo :
- langage de DirectX ? C++
- langage de OpenGL ? C++
- langage de SDL ? C++

Ce n'est pas le fruit du hasard.

[loka]

Message de kpouer 25/07/2008 à 14h32:

Justement, Java ira écrire dans un fichier ou quoi alors que C++ aura une fonction de lecture et une fonction d'écriture générique qui enregistre soit en XML ( standard Mac ) soit dans le registre ( standard Windows ) soit dans un fichier texte ( standard Linux ) . Un appel de fonction ( méthode statique plutôt ) seulement, pas une usine à gaz.

Mais le plus flagrant c'est pour le rendu web : je n'ai jamais réussi à le faire fonctionner correctement ( Windows ok, mais Linux plante ) dans Java alors que je l'ai fait en 2 minutes en C++.

Euh c'est tout simplement que tu as une api en c++ qui fait ca, ca n'a rien a voir avec le langage lui même. C'est comme si tu passais de Java à c++ et tu reprochais a c++ de ne pas retrouver les mêmes fonctions

Pour recadrer sur le jeu vidéo :
- langage de DirectX ? C++
- langage de OpenGL ? C++
- langage de SDL ? C++

Ce n'est pas le fruit du hasard.

Effectivement ce n'est pas le fruit du hazard, c'est le fruit d'une époque.
Ce n'est pas un argument, sinon les jeux seraient pas en c++, ils seraient en C, puisqu'avant de passer au c++ ils étaient tous en C.
Ou ils seraient en assembleur, puisqu'avant on programmait les jeux en assembleur.

[loka]

Message de FloMo 25/07/2008 à 14h40:

Euh c'est tout simplement que tu as une api en c++ qui fait ca, ca n'a rien a voir avec le langage lui même. C'est comme si tu passais de Java à c++ et tu reprochais a c++ de ne pas retrouver les mêmes fonctions

Dans ces cas-là, ils fourniraient un binding Java officiel.

Effectivement ce n'est pas le fruit du hazard, c'est le fruit d'une époque.
Ce n'est pas un argument, sinon les jeux seraient pas en c++, ils seraient en C, puisqu'avant de passer au c++ ils étaient tous en C.
Ou ils seraient en assembleur, puisqu'avant on programmait les jeux en assembleur.

Les jeux étaient même codés en Basic à une époque, et c'est à chaque fois à l'apparition d'un nouveau langage qu'ils ont adapté les plateformes.

Hors, Java existe depuis longtemps.

[loka]

Message de DzzDDzzD 25/07/2008 à 14h41:

le probleme dans ces discussions, c'est que les developpements amateurs ont toujour eu et auront toujous 5 a 10 ans de retard sur l'industrie du jeu vidéo. La preuve, c'est que personne ici ne parle du futur, ni meme du present, mais tous parlent du passé. Les developpements amateurs s'etendent entre les clones de tetris et mario bros jusqu'aux clones de Quake III (2000...)

ben non, le problème c'est que tu fais l'amalgam entre "jeu vidéo" et "société de consomation qui te gave" et que tu pense que tout le monde veu jouer au tout dernier jeu utilisant les derniers shaders et des CPU à 8 cores et qu'il faut absolument acheter la toute derniere carte graphique qui sera d'ailleur obsolete dans six mois.... Mais un jeu vidéo c'est pas forcement un FPS ou un MMORPG. Et un jeu qui n'est pas un FPS ou un MMO n'est pas forcement un jeu amateur.... comme un film qui n'est pas américain n'est pas forcement un film amateur.

[loka]

Message de kpouer 25/07/2008 à 14h44:

Dans ces cas-là, ils fourniraient un binding Java officiel.

Quel est le binding officiel en c++ ?

Les jeux étaient même codés en Basic à une époque, et c'est à chaque fois à l'apparition d'un nouveau langage qu'ils ont adapté les plateformes.

Hors, Java existe depuis longtemps.

Mais Sun a eu la volonté d'imposer Java coté serveur pour commencer, et ca leur a plutot bien réussi ...

[loka]

Message de screetch 25/07/2008 à 15h06:

ben non, le problème c'est que tu fais l'amalgam entre "jeu vidéo" et "société de consomation qui te gave" et que tu pense que tout le monde veu jouer au tout dernier jeu utilisant les derniers shaders et des CPU à 8 cores et qu'il faut absolument acheter la toute derniere carte graphique qui sera d'ailleur obsolete dans six mois.... Mais un jeu vidéo c'est pas forcement un FPS ou un MMORPG. Et un jeu qui n'est pas un FPS ou un MMO n'est pas forcement un jeu amateur.... comme un film qui n'est pas américain n'est pas forcement un film amateur.

la question n'est pas a propos de moi ou toi mais a propos de ce qui se fait en ce moment dans les jeux vidéo : du multitaches. merci de rester dans le sujet du debat

[loka]

Message de TanEk 25/07/2008 à 15h15:

Par incontrôlable, je veut dire qu'on ne peut pas maitriser précisément (et j'insiste sur le précisément avant qu'on ne me dise qu'on peut paramètrer la JVM ) la taille mémoire alloué ainsi que l'emplacement. La taille importe car quand on se retrouve avec des petits objets (des float3 ou des types de vertex compressé qui font quelques octets) qui sont très nombreux et auquels la VM ajoute un overhead de quelques octets pour chaque allocation, forcement, on explose vite la mémoire, et surtout on utilise plus de mémoire système que besoin et on ajoute du striding a la carte graphique, ce qui est mauvais aussi bien pour le transfert sur le port graphique et pour le cache de la carte graphique.

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.

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

Le problème de l'emplacement mémoire, c'est qu'il est difficile en Java d'assurer que plusieurs objets d'un même type seront alloué dans des zones mémoire proche. Ceci est particulièrement utile dans les jeux pour garantir de bonne performance au niveau du cache processeur. Ceci peut être fait en C++ en utilisant des pool avec des allocation "in place". En Java, de part l'abstraction apporté par la VM, on ne peut pas garantir de genre d'optimisations...

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.

il faut bien garder à l'esprit qu'une console comme la PS3, c'est 256Mo de mémoire système dont ~90Mo utilisé par l'OS. Du coup, si une JVM tournai dessus, on ne pourrai néanmoins jamais proposer de jeux mieux ou équivalent à ceux développé en C++ rien qu'a cause de ce surcout mémoire...

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). Pour le reste, la taille des objets en java est égale à la taille des objets natif à quelque chose prêt (par exemple pour un tableau on a la taille qui est stockée, mais ne me dites pas qu'en C++ on ne doit pas créer un int size poru stocker la taille du tableau pour travailler avec, donc ça revient au même). Après java stocke un peu plus d'informations pour chaque classe crée mais c'est minime (ça prend quoi 1 mo max ?). Donc à part ces 5 Mo, qui peuvent être problématiques sur des architectures embarquées, il n'y a AUCUN surcoût.

l'autre problème de la VM viens du garbage collector. Certes on peut le contrôler plus ou moins, mais dans tous les cas, le passage du garbage collector est le meilleurs tueurs de cache au monde et quand on fait un jeu temps réel, ce qui importe, c'est avant tout d'avoir un frame rate constant. Avec le garbage collector, on a un truc qui, plus ou moins régulièrement, nous fait des piques de frame rate...

Ceci est n'importe quoi encore une fois car avec le nombre de coeur toujours grandissant des processeurs, avoir un garbage qui tourne en threaded sur un p'tit coeur tranquilou ce sera IMPOSSIBLE de faire chuter les FPS de façon dramatique (je pencherai pour une baisse de l'ordre de <1%).

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.

A part ces problèmes qui se pose sur des titre AAA mainstream, il n'y a effectivement pas de problème à développer de jeux en Java.

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.

Ensuite un langage n'est bien que s'il a des outils existants pour le faire marcher et il est vrai que ne pas avoir direct x en java est un énorme handicap pour ce dernier.

De plus les majors actuels fournissent les technologies de pointent en C++ uniquement. Par exemple OpenGL existe maintenant en java mais ça n'a pas été soutenu par des majors donc il est fort probable que la version 3.0 de opengl ne soit accessible en java que bien après la version c/(c++ ?). Ce qui est aussi un handicap en soit !

[loka]

Message de screetch 25/07/2008 à 15h27:

les couts cachés du java :
- le programme java lui meme est equivalent au programme jeu compilé en C++; il faut faire tenir le code en mémoire.
- le code compilé par la JVM doit bien etre stocké quelque part
- le code non compilé est lui aussi en mémoire

ce n'est pas un cout fixe et on ne peut pas parler comme ca de "4 megs". ca depend de la taille du programme a compiler/interpreter.

le surcout est plus proche des 20 megas (taille du code compilé et du bytecode non compilé) pour un exe de la taille des jeux actuels.

[loka]

Message de kpouer 25/07/2008 à 15h37:

les couts cachés du java :
- le programme java lui meme est equivalent au programme jeu compilé en C++; il faut faire tenir le code en mémoire.
- le code compilé par la JVM doit bien etre stocké quelque part
- le code non compilé est lui aussi en mémoire

ce n'est pas un cout fixe et on ne peut pas parler comme ca de "4 megs". ca depend de la taille du programme a compiler/interpreter.

le surcout est plus proche des 20 megas (taille du code compilé et du bytecode non compilé) pour un exe de la taille des jeux actuels.

20 Mo me parraissent beaucoup, mais même si c'est vrai, on parle de jeu, les trucs qui prennent 800Mo de ram minimum. 20 Mo de plus ou de moins c'est pas ca qui change la donne

[loka]

Message de DzzDDzzD 25/07/2008 à 15h40:

la question n'est pas a propos de moi ou toi mais a propos de ce qui se fait en ce moment dans les jeux vidéo : du multitaches. merci de rester dans le sujet du debat

je ne pense pas etre sortit du débat, je precisais et la à toi particulièrement par rapport à ton post que le monde du jeu est plus vaste et ne se résume pas à afficher le plus de polygones possible à l'écran.


par exemple, je joue un peu à des jeux CD (RA2 oui c'est tres vieu mais j'adore, et BF2) mais les jeux ou je passe le plus de temps c'est les jeux en lignes les "Casual Games".

[loka]

Message de screetch 25/07/2008 à 15h46:

je ne pense pas etre sortit du débat, je precisais et la à toi particulièrement par rapport à ton post que le monde du jeu est plus vaste et ne se résume pas à afficher le plus de polygones possible à l'écran.


par exemple, je joue un peu à des jeux CD (RA2 oui c'est tres vieu mais j'adore, et BF2) mais les jeux ou je passe le plus de temps c'est les jeux en lignes les "Casual Games".

ces jeux ont été fait a une epoque ou c'etait le top du top, et meme si c'est possible de les refaire maintenant en java, il aurait été impossible de les faire a l'epoque en java. tout comme il est impossible de faire aujourd'hui en java des jeux comme total commander, mais dans 5/10 ans ce sera possible. ce que j'ai dit ne change pas, et j'ai terminé en disant, comme je l'ai dit deja auparavant, que 90% desj eux peuvent etre fait en java, mais pas les 10% qui sont les plus demandeurs en ressources CPU et graphiques.

[loka]

Message de screetch 25/07/2008 à 15h48:

20 Mo me parraissent beaucoup, mais même si c'est vrai, on parle de jeu, les trucs qui prennent 800Mo de ram minimum. 20 Mo de plus ou de moins c'est pas ca qui change la donne

un exe compilé prend deja 10 megs en mémoire sans compté les dependances de DLL deja chargées.

une console, c'est exactement 512 megs et pas un octet de moins. sur ces 512 megs, il faut caser les ressources graphiques ET la mémoire gameplay ET l'executable ET les dll. alors 20 megs de plus, c'est costaud. ca fait quand meme 5%, c'est pas negligeable.

[loka]

Message de TanEk 25/07/2008 à 16h40:

Un programme compilé de façon optimisée prend beaucoup plus de place que du bytecode java justement à cause des inlining, etc. qui sont fait partout. Et le JIT ne compilera que les parties critiques (on dit que c'est de l'ordre de 10% à 20% d'un gros programme qui est critique). Donc il n'y aura que 10 à 20% du code qui sera compilé. Donc cette histoire du 20 Mo en plus par rapport à un langage compilé c'est vraiment mais alors vraiment exagéré. Je me demande si sur de gros programmes très complexes la taille mémoire du bytecode+des parties de codes compilées en java n'est pas aussi grande que le code compilé entièrement de façon statique. Allez je suis gentil, supposons qu'on perd encore 5 Mo à cause du bytecode compilé (ce qui est vraiment un maximum et je répète qu'on peut très bien arriver à une équivalence voire peut-être même gagner en mémoire)... 10 Mo max. Gros max. Car sachez que les classes ne sont chargées que si elles sont utilisées. ce qui n'est pas le cas pour les programmes compilés. On charge toutes les dlls, tout. Alors que ce n'est peut-être pas nécessaire...

Et la taille des programmes ne grossit pas aussi vite que la taille des ressources graphiques donc aujourd'hui la surcharge d'une machine virtuelle est de l'ordre de 2% si on a 500 Mo de ram (pour 10 Mo en plus) mais vous savez très bien que les mémoires vont augmenter (et les programmes aussi mais pas aussi vite) et donc bientôt la surchage d'une machine virtuelle sera de l'ordre de <1% ce qui est "rien", vous en conviendrez.

Un des débats sous-jacent à cette conversation est le suivant : un programme exécuté avec une machine virtuelle est-il aussi rapide qu'un programme exécuté en natif ?

Le "bon sens" dirait que le programme exécuté en natif est plus rapide mais lorsqu'on s'y penche de plus prêt et qu'on regarde l'évolution actuelle et réelle qui est mesurable, le programme exécuté sur la machine virtuelle devient de plus en plus rapide et arrive maintenant à surpasser le programme exécuté en natif dans certains domaines. Et donc rien n'interdit que ça n'aille pas dans ce sens et qu'au bout d'un moment le programme exécuté sur une machine virtuelle aille plus vite qu'un programme exécuté directement en natif.

Pourquoi ? A cause des optimisations dynamiques qui ne sont pas très présentes actuellement dans les JVMs car très difficiles à faire mais qui seront de plus en plus nombreuses au fur et à mesure de l'avancée sur la théorie de la grammaire, etc. et qui ne sont pas possibles sur du hardware à l'heure actuelle.

Il faut arrêter de croire que si l'on contrôle tout alors on va faire des programmes optimisés. Nous ne réfléchissons pas comme des machines, nous sommes faillibles. Le contrôle de la mémoire peut-être effectué dans certains cas particuliers (et rien n'interdise que dans les prochaines versions de java on ne puisse pas forcer l'allocation des objets dans une zone mémoire pour l'envoyer au cache... seulement ce n'est pas implémenté car pas forcément nécessaire dans l'utilisation actuelle de java...) mais doit dans la majorité des cas être contrôlé par la machine. Mais de là à devoir accéder au niveau du pointeur, cela n'a presque plus d'intérêt actuellement.

S'en est de même pour la compilation, il faut qu'elle devienne dynamique et gérée par une machine virtuelle.

Vous allez me dire je parle du futur mais non. Je suis persuadé qu'un programme complexe codé en java et en C++ est kiffe kiffe en terme de performance avec un certain avantage pour le C++ avec la dernière jvm de sun sur une plateforme "idéale" quand même vu les implémentations actuelles (ceci avec mon expérience de programmeur sur les programmes faits en C++ et java, la différence d'exécution est imperceptible). Mais encore plus pour un jeu-vidéo qui est en général GPU-bound. Et cette différence est vouée à disparaître (ça ne m'étonnerait pas si la version 8 ou 9 de la JVM de Sun arrive à des performances équivalentes à un compilateur C++ sur des gros programmes) avec le temps et ira à l'avantage d'un langage sur machine virtuelle.

Donc il y a à l'heure actuelle de forte chances de pouvoir faire un programme AAA sur une machine virtuelle (Java ou peut-être C# si les majors décident, car c'est eux qui décident et pas nous ) et même si ce n'est pas le cas (ce qui est fortement improbable) ce sera faisable très prochainement et sera mais alors sûrement plus rapide qu'un jeu compilé de façon statique. Et je m'arrêterai là sur ma participation à cette discussion car je pense en avoir fait le tour personnellement .