Discussion :

[shenron666]

très fort le jeu en "youtube"

gouessej, tu serais gentil de lire la totalité de mes posts avant d'y répondre, pas juste les termes qui ne te plaisent pas
pour résumer
- je n'ai jamais dit qu'il y avait une machine virtuelle sur wii
- je demande des jeux de moins de 10 ans, jmonkey c'est bien c'est beau mais c'est pas un jeu
- glu est une boite à outils pour gl et par conséquent ça utilise jogl au final
- Commander: Europe at War est un bon exemple qu'un jeu commercial (au tour par tour) peut-etre écrit en java, qui plus est il a eu de bonnes critiques
- les développeurs indépendants intéressés par le PSN ok, quel rapport avec java puisqu'il n'y a pas de machine virtuelle sur ps3 et c'est certainement la plateforme la moins probable pour en accueillir une à cause de son cpu
- java est plus lent qu'un langage compilé, ce n'est pas un préjugé c'est un fait et en toute logique il est impossible qu'un langage interprété soit aussi rapide qu'un langage compilé
- je n'ai pas dit que Sun ne poussait pas, mais qu'il semblait que Sun ne poussait pas, une fois de plus tu lis ce que tu veux bien lire...

attendons donc de voir ce que donnera le jeu de statégie au tour par tour Poxnora s'il est porté sur ps3
redéveloppé dans un autre langage ou développement d'une machine virtuelle ?
sur ce, bonne nuit

[mavina]

excuses moi mais je n'ai pas compris

tu ne pense pas forcément au portage dès le début

Oh que si ! Si tu n'y penses pas dès le début, tu t'en mords les doigts

F.

[millie]

- java est plus lent qu'un langage compilé, ce n'est pas un préjugé c'est un fait et en toute logique il est impossible qu'un langage interprété soit aussi rapide qu'un langage compilé

Sauf que ça fait depuis le début que certains disent que la JVM recompile en natif lors de l'exécution les passages les plus utilisés (via hotspot). Même si la JVM actuelle n'est pas 100% au point et qu'il existe énormément d'optimisation à faire et qui ne sont pas fait, il serait tout à fait possible d'avoir un langage interprété aussi rapide qu'un langage compilé dans le cas général puisque le langage interprété peut être recompilé au moment de l'exécution.

Mais là, je parle de manière général

[shenron666]

Oh que si ! Si tu n'y penses pas dès le début, tu t'en mords les doigts

F.

justement
comme je disais, les kits de développement console sont payants, avec peu de moyens c'est difficile et risqué de développer sur console, tu sors un titre sur pc qui marche bien mieux que prévu et du coup l'éditeur de propose/demande de le porter sur console

comme la JVM n'existe pas sur console, ce serait donc un mauvais choix stratégique de développer en java car il faudrait redévelopper le titre pour le portage, ce qui est bien plus couteux que de porter un titre développé en C ou en C++

certains disent que la JVM recompile en natif lors de l'exécution les passages les plus utilisés (via hotspot).

certains le disent... bon je veux bien y croire, mais la JVM ne recompile pas l'intégralité du code, il reste toujours du code interprété
et de là à avoir une JVM qui compile et optimise aussi bien qu'un vrai compilateur je n'y crois pas une seconde

[millie]

j
certains le disent... bon je veux bien y croire, mais la JVM ne recompile pas l'intégralité du code, il reste toujours du code interprété
et de là à avoir une JVM qui compile et optimise aussi bien qu'un vrai compilateur je n'y crois pas une seconde

Dans le "certains le disent", j'en fais partie ^^

Et bien théoriquement, ce serait possible, mais la JVM demande à l'heure actuel encore beaucoup d'optimisation.

Après, il y a un avantage par rapport à une compilateur classique, c'est qu'il n'est pas nécessaire de tout optimiser car la JVM sait quelles sections de codes sont les plus utilisées (donc ce n'est pas forcement utile d'optimiser une partie appelée une fois toutes les 10min)

[screetch]

Sauf que ça fait depuis le début que certains disent que la JVM recompile en natif lors de l'exécution les passages les plus utilisés (via hotspot). Même si la JVM actuelle n'est pas 100% au point et qu'il existe énormément d'optimisation à faire et qui ne sont pas fait, il serait tout à fait possible d'avoir un langage interprété aussi rapide qu'un langage compilé dans le cas général puisque le langage interprété peut être recompilé au moment de l'exécution.

Mais là, je parle de manière général

mais quid du temps necessaire pour compiler ? c'est pas gratuit la compilation...

[millie]

mais quid du temps necessaire pour compiler ? c'est pas gratuit la compilation...

Ca ne compile pas en une fois et le temps est quand même bien répartit pour que ce soit quasiment invisible pour l'utilisateur du jeu.

Et s'il y avait des ralentissements les 5 premières minutes, on peut imaginer des systèmes de cache pour les fois suivantes.

[screetch]

et le cout en memoire de la compilation ?

[screetch]

En gros, il n'y a rien qu'un "profile guided optimization" ne saurait faire, sauf que le "profile guided optimization" du C++ fonctionne offline, et donc pas de recompilation a la volée, d'ou un executable plus rapide
un executable aussi rapide, auquel on a retiré le surcout de la compilation à la volée

mis devant des faits vous avez encore du mal a admettre...

C++ plus rapide que java, cout mémoire moins important
MAIS rien n'empeche de faire un jeu en Java
MAIS une certaine baisse de performance va empecher de faire aussi bien qu'en C++, le top du top est de laisser a java les parties de code non critiques et d'ecrire les parties importantes et C++ pour des optimisations de cache mémoire ou autres.

[millie]

C++ plus rapide que java

Je n'ai jamais dit le contraire pour les machines virtuelles à l'heure actuelle...

Je répondais à :

en toute logique il est impossible qu'un langage interprété soit aussi rapide qu'un langage compilé

Théoriquement, c'est possible d'avoir un langage interprété aussi rapide qu'un langage compilé.

[screetch]

il serait tout à fait possible d'avoir un langage interprété aussi rapide qu'un langage compilé dans le cas général puisque le langage interprété peut être recompilé au moment de l'exécution.

Et donc, non, pas possible, a moins de ne pas compter le temps de compilation...

[deadalnix]

Attention, on va partir dans la technique.

Qui ici, sait comment sont résolus les appels de fonction en JAVA ? A en lire certains, j'ai bien l'impression que non.

Le méchanisme, bien que très souple, promet de ne jamais avoir d'appels aussi rapides qu'en natif.

[millie]

Et donc, non, pas possible, a moins de ne pas compter le temps de compilation...

Avec des sytèmes de caches, cela peut être que pendant les 5 premières minutes de la première exécution. Rien de bien violent pour les jeux récents qui mettent autant de temps à démarrer.
On peut même imaginer que le code soit déjà préoptimisé par un mécanisme du type hotspot dès l'installation sur la machine. Et la JVM aura déjà des parties en grandes parties compilées dès la première exécution.

Je rappelle que je parle pas de la JVM à l'heure actuelle...

[bafman]

En gros, il n'y a rien qu'un "profile guided optimization" ne saurait faire, sauf que le "profile guided optimization" du C++ fonctionne offline, et donc pas de recompilation a la volée, d'ou un executable plus rapide

encore faut-t il qu'il marche sur des gros projet... on a jamais réussi à en tirer quoi que ce soit chez nous

[millie]

et le cout en memoire de la compilation ?

De manière générale (je parle de machine virtuelle en général lors de toute l'exécution du programme), je ne vois effectivement pas trop comment il serait possible d'utiliser moins de mémoire par contre puisqu'il faut que la JVM soit en mémoire + le bytecode (quoique...) + éventuellement le code compilé.

Je parle indépendamment du garbage collector.

[shenron666]

Théoriquement, c'est possible d'avoir un langage interprété aussi rapide qu'un langage compilé.

là dessus il m'est impossible d'être d'accord à moins de compiler l'intégralité du byte code
sans cela, il y a un surcout lors du passage :
- code interprété -> code compilé
- code compilé -> code interprété

note : si la JVM compile le "byte code" en langage natif ce n'est plus de l'interprété

[millie]

note : si la JVM compile le "byte code" en langage natif ce n'est plus de l'interprété

La limite peut être flou. Qu'est-ce qu'un langage interprété pour toi ?

EDIT : Je sens le découpage de thread sous peu

[shenron666]

si le code est compilé et exécuté directement par le hardware c'est du code natif, si le code nécessite un "convertisseur" pour être compris c'est de l'interprété

si la JVM génère du code natif tel un compilateur il y a certes un flou sur la façon dont il faut considérer le code exécuté

honnêtement si ça permet à java d'être plus efficace il n'y a pas à s'en priver
peut-être qu'à l'avenir es JVM feront plus office de compilateur que d'interpréteur

sinon on peut aussi dire que le compilateur C++ est un interpréteur

[millie]

si le code est compilé et exécuté directement par le hardware c'est du code natif, si le code nécessite un "convertisseur" pour être compris c'est de l'interprété

En fait, je pense que c'est toujours un peu flou.

Car un .exe n'est finalement pas exécuté directement par le hardware, un .exe n'est qu'un conteneur qui a un ensemble d'informations qui permet au système d'exploitation de le charger en mémoire, et de lancer l'exécution d'une partie du fichier .exe (le code déjà compilé).

Mais finalement, si on faisait un nouveau format qui contient du code machine mais qui nécessite une machine virtuelle pour l'exécuter (on peut imaginer que la machine fasse des choses en plus comme intercepter les appels systèmes pour simuler une sandbox, ce qui se fait facilement sous UNIX).
Donc finalement, ce cas-ci, est-ce du code compilé ou interprété ? Puisqu'il nécessite de toute façon quelque chose en plus pour l'exécuter.

honnêtement si ça permet à java d'être plus efficace il n'y a pas à s'en priver
peut-être qu'à l'avenir es JVM feront plus office de compilateur que d'interpréteur

Probablement.

[kremvax]

Dans la théorie, on pourrait aussi très bien imaginer que la JVM profite des architectures multicoeurs des processeurs récents pour compiler du java avec 0 perte de temps, en monopolisant un cœur donc.