Java pour les jeux par navigateur ?

[Sephi-Chan]

Ton exemple est étonnant Rygnes, puisque de par sa nature compilée, une application JEE doit être plus rapide qu'une application écrite dans un langage interprété, c'est justement pour cela qu'on utilise des caches d'Opcode en PHP.

Je pense que la lenteur vient d'ailleurs. Peut-être que le serveur est sous-dimensionné ou qu'il sert à d'autres services ?


Sephi-Chan

[rygnes]

Ne te réfère pas toujours à la théorie.
Si on en croit la théorie un processeur double coeur multiplie par deux ses performances (sous réserve que les applications utilise sa caractéristique), en pratique ça n'a jamais été le cas.

Le serveur ?
Je te rassure, il n'y a pas qu'un serveur machine qui gère le site...
Je ne fais qu'un constat.
Je ne peux pas vraiment en dire plus.

[pascal]

au taf, on a une appli java + oracle.

j'ai l'impression que ce qui cloche, c'est mettre une DB derrière java.

A+

Pascal

[Mycroft]

Je sais pas si le Java c'est le meilleur exemple, parce que c'est du code qui tourne sur une machine virtuelle. J'aurais tendance à croire que c'est plus lent dans tous les cas que du code natif. (Apparament avec de la compilation Just-in-Time, ça peut être équivalent voir meilleur dans certains cas que du code natif.)

Par contre de l'opcode PHP, c'est directement du code machine non (une fois que c'est compilé une fois) ?

Si c'est le cas très naïvement je dirais que de l'opcode php doit être plus rapide que du Java.

Edit : en lisant quelques liens sur Java vs Langage Machine, c'est clair que c'est pas clair . Dans certains cas Java peut être meilleur dans d'autres non. Et à côté des performances pures en temps CPU pour un serveur il faut aussi prendre en compte des problèmes de RAM ou même de temps de réponses. Généralement Java est plus rapide que du code interprété, mais si on regarde java vs opcode, c'est plus flou. En tout cas, ça dépasse mes compétences de loin.

Ca m'intéresserait de savoir ce que ton prof pense du problème Java vs Code Compilé (C, C++) en 2009. Ca sort largement du cadre du PHP mais ça m'intéresse.

Edit2 : Donc j'ai bien dit une boulette le "opcode" PHP c'est pas du code machine. C'est du code qui passe dans le Zend Engine qui est l'équivalent d'une machine virtuelle pour le PHP.

Au final on en revient à savoir quelle solution produit le meilleur bytecode et quelle VM est la meilleure...

[Allwise]

Y a pas photo, du code compilé est toujours plus rapide que du code interprété puisqu'au final, ce code interprété va être parsé et va taper sur des fonctions de plus bas niveau (fonctions C pour PHP et certainement pour Java). Donc si tu écris directement les fonctions de bas niveau, le "code natif", ça ne peut qu'être plus rapide, et plus rapide aussi que du code qui a été précompilé Just in Time. Puis le code intermédiaire obtenu doit encore être traduit en langage machine avant d'être exécuté

La machine virtuelle, même avec du code déjà compilé, est aussi une étape supplémentaire avant l'exécution de ce code. L'avantage d'employer une machine virtuelle, c'est surtout qu'on a pas à se soucier de l'architecture de la machine sur laquelle le programme doit tourner. Elle fait ce qu'il faut pour que le programme tourne de la même façon partout. N'empêche que ça alourdit un peu le processus.

En ce qui concerne PHP, c'est son moteur Zend qui s'occupe de traduire le code source et de l'exécuter, mais apparemment il est pas tip top niveau performances...

[Mycroft]

Y a pas photo, du code compilé est toujours plus rapide que du code interprété puisqu'au final, ce code interprété va être parsé et va taper sur des fonctions de plus bas niveau (fonctions C pour PHP et certainement pour Java).

En fait pour le PHP:
Code --> passage dans un parser --> bytecode --> passage dans VM --> code machine.

Pour Java:
Code --> compilation --> bytecode --> passage dans une VM --> code machine

Pour C/C++:
Code --> compilation --> code machine

En gras ce qui se passe au runtime.
En utilisant les caches d'opcode de PHP, tu pars du bytecode aussi en php.

Donc si tu écris directement les fonctions de bas niveau, le "code natif", ça ne peut qu'être plus rapide, quand bien même le code a été précompilé Just in Time. Puis le code intermédiaire obtenu doit encore être traduit en langage machine avant d'être exécuté

C'est le premier résultat de Google Java vs C++ est à priori les arguments sont pas idiots :
http://www.idiom.com/~zilla/Computer/jav...hmark.html

Un des arguments de l'article c'est que des optimisations sur le bytecode, donc au moment du runtime, permettent des gains dans certains cas par rapport à du code machine qui est par définition statique. L'argument c'est qu'au moment où tu écris ton code tu n'est pas au courant de certaines optimisations directement liées à la façon dont le code est utilisée.

Je sais pas si c'est vrai ou faux, c'est des querelles d'expert que je trancherais pas. Mais ça parait plus compliquer que "Java est toujours plus lent que du code compilé". Il y a des benchmarks où c'est faux.

L'article est plutôt "pro Java".

La machine virtuelle, même avec du code déjà compilé, est aussi une étape supplémentaire avant l'exécution de ce code. L'avantage d'employer une machine virtuelle, c'est surtout qu'on a pas à se soucier de l'architecture de la machine sur laquelle le programme doit tourner. Elle fait ce qu'il faut pour que le programme tourne de la même façon partout. N'empêche que ça alourdit un peu le processus.

En ce qui concerne PHP, c'est son moteur Zend qui s'occupe de traduire le code source et de l'exécuter, mais apparemment il est pas tip top niveau performances...

Pour ça je suis d'accord . Et même entre deux JVM tu peux avoir des gros écarts...