Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Miguel Moquillon
Voici une page interessante sur les performances de Java.
http://java.sun.com/performance/index.jsp
Ton lien est très intéressant. Toutefois, si tu pouvais éviter d'écrire des sujets trop long, dont une bonne partie devrait faire partie du corps, ce serait sympa, merci. (Note: je t'épargnes la réf. vers la netiquette.)
Miguel
Voici une page interessante sur les performances de Java.
http://java.sun.com/performance/index.jsp
Ton lien est très intéressant.
Toutefois, si tu pouvais éviter d'écrire des sujets trop long, dont une
bonne partie devrait faire partie du corps, ce serait sympa, merci.
(Note: je t'épargnes la réf. vers la netiquette.)
Voici une page interessante sur les performances de Java.
http://java.sun.com/performance/index.jsp
Ton lien est très intéressant. Toutefois, si tu pouvais éviter d'écrire des sujets trop long, dont une bonne partie devrait faire partie du corps, ce serait sympa, merci. (Note: je t'épargnes la réf. vers la netiquette.)
Miguel
Olivier
Vincent Cantin wrote:
Voici une page interessante sur les performances de Java.
http://java.sun.com/performance/index.jsp
... De quoi laisser les trolls ignares au placard pour quelques jours (j'espere).
C'est super objectif les articles d'un éditeur qui vante les mérites de SA technologie...
olive
Vincent Cantin wrote:
Voici une page interessante sur les performances de Java.
http://java.sun.com/performance/index.jsp
... De quoi laisser les trolls ignares au placard pour quelques jours
(j'espere).
C'est super objectif les articles d'un éditeur qui vante les mérites de
SA technologie...
Voici une page interessante sur les performances de Java.
http://java.sun.com/performance/index.jsp
... De quoi laisser les trolls ignares au placard pour quelques jours (j'espere).
C'est super objectif les articles d'un éditeur qui vante les mérites de SA technologie...
olive
Jean-Marc Vanel
Vincent Cantin wrote:
Voici une page interessante sur les performances de Java.
http://java.sun.com/performance/index.jsp
Il y a aussi une techno. qui grandit lentement mais sûrement (comme Mozilla à une époque), c'est gcj (http://gcc.gnu.org/java/), le compilateur Java de la chaîne gcc.
Il est bien sûr + performant que Java, et il est train d'inclure les bibliothèques manquantes java.* et javax.* .
D'ores et déjà, on peut (parait-il) compiler une appli. réseau. Pour Swing et AWT, il manque des briques mais ils y travaillent.
Et l'avantage, c'est aussi de pouvoir mélanger du Java et du C++, de quoi réconcilier Grégory avec Java ;-) !
Vincent Cantin wrote:
Voici une page interessante sur les performances de Java.
http://java.sun.com/performance/index.jsp
Il y a aussi une techno. qui grandit lentement mais sûrement (comme
Mozilla à une époque), c'est gcj (http://gcc.gnu.org/java/), le
compilateur Java de la chaîne gcc.
Il est bien sûr + performant que Java, et il est train d'inclure les
bibliothèques manquantes java.* et javax.* .
D'ores et déjà, on peut (parait-il) compiler une appli. réseau. Pour
Swing et AWT, il manque des briques mais ils y travaillent.
Et l'avantage, c'est aussi de pouvoir mélanger du Java et du C++, de
quoi réconcilier Grégory avec Java ;-) !
Voici une page interessante sur les performances de Java.
http://java.sun.com/performance/index.jsp
Il y a aussi une techno. qui grandit lentement mais sûrement (comme Mozilla à une époque), c'est gcj (http://gcc.gnu.org/java/), le compilateur Java de la chaîne gcc.
Il est bien sûr + performant que Java, et il est train d'inclure les bibliothèques manquantes java.* et javax.* .
D'ores et déjà, on peut (parait-il) compiler une appli. réseau. Pour Swing et AWT, il manque des briques mais ils y travaillent.
Et l'avantage, c'est aussi de pouvoir mélanger du Java et du C++, de quoi réconcilier Grégory avec Java ;-) !
Jean Bernard Root
Bonjour,
Il est bien sûr + performant que Java, et il est train d'inclure les bibliothèques manquantes java.* et javax.* .
Ce "bien sûr" me gène.
Je n'arrive pas à comprendre commen gcj s'abstrait de façon aussi triviale des problèmes de la VM :
- le processus de GC, qui est la source de beaucoup des "problèmes" de performances de java, est assuré par un gros runtime. - on linke des .o natif, c'est vrai, mais ils ne font pas grand chose d'autres que d'appeler directement des fonctions dans le runtime - au final, on arrive à faire exactement ce que fait la VM, interprêter et pré-compiler du byte code.
J'ai des doutes sur les soit-disant performances de gcj, franchement ...
Il est vrai que les VM modernes avec "-server" se comportent un peu comme des diesels; il faut qu'elle "chauffent" avant d'en obtenir la quintescence, mais tout de même, une fois bien chaud, hotspot est sensé avoir tout précompilé comme gcj.
Avez-vous des benchmark sous la main pour affirmer que gcj est "bien sûr" plus performant que java ? J'aimerais bien les lire avant de me lancer dans la compilation d'un programme énorme de mon cru qui a des besoins cruciaux en performance ... je n'ai rien trouvé sur leur site, mais ce que je lis là ne m'impressione franchement pas (http://www.shudo.net/jit/perf-20000921/, bon ça date de quatre ans !), et les autres littératures font l'apologie de sa petite occupation mémoire (footprint), mais certainement pas de performances délirantes ...
Votre propre expérience va dans ce sens ? C'est bien plus rapide avec gcj ?
En tout cas, le développement en lui-même doit être considérablement ralenti (pas de tests unitaires à la compilation sans linker autant de programmes que tests ...)
Bonjour,
Il est bien sûr + performant que Java, et il est train d'inclure les
bibliothèques manquantes java.* et javax.* .
Ce "bien sûr" me gène.
Je n'arrive pas à comprendre commen gcj s'abstrait de façon aussi
triviale des problèmes de la VM :
- le processus de GC, qui est la source de beaucoup des "problèmes" de
performances de java, est assuré par un gros runtime.
- on linke des .o natif, c'est vrai, mais ils ne font pas grand chose
d'autres que d'appeler directement des fonctions dans le runtime
- au final, on arrive à faire exactement ce que fait la VM, interprêter
et pré-compiler du byte code.
J'ai des doutes sur les soit-disant performances de gcj, franchement ...
Il est vrai que les VM modernes avec "-server" se comportent un peu
comme des diesels; il faut qu'elle "chauffent" avant d'en obtenir la
quintescence, mais tout de même, une fois bien chaud, hotspot est sensé
avoir tout précompilé comme gcj.
Avez-vous des benchmark sous la main pour affirmer que gcj est "bien
sûr" plus performant que java ? J'aimerais bien les lire avant de me
lancer dans la compilation d'un programme énorme de mon cru qui a des
besoins cruciaux en performance ... je n'ai rien trouvé sur leur site,
mais ce que je lis là ne m'impressione franchement pas
(http://www.shudo.net/jit/perf-20000921/, bon ça date de quatre ans !),
et les autres littératures font l'apologie de sa petite occupation
mémoire (footprint), mais certainement pas de performances délirantes ...
Votre propre expérience va dans ce sens ? C'est bien plus rapide avec gcj ?
En tout cas, le développement en lui-même doit être considérablement
ralenti (pas de tests unitaires à la compilation sans linker autant de
programmes que tests ...)
Il est bien sûr + performant que Java, et il est train d'inclure les bibliothèques manquantes java.* et javax.* .
Ce "bien sûr" me gène.
Je n'arrive pas à comprendre commen gcj s'abstrait de façon aussi triviale des problèmes de la VM :
- le processus de GC, qui est la source de beaucoup des "problèmes" de performances de java, est assuré par un gros runtime. - on linke des .o natif, c'est vrai, mais ils ne font pas grand chose d'autres que d'appeler directement des fonctions dans le runtime - au final, on arrive à faire exactement ce que fait la VM, interprêter et pré-compiler du byte code.
J'ai des doutes sur les soit-disant performances de gcj, franchement ...
Il est vrai que les VM modernes avec "-server" se comportent un peu comme des diesels; il faut qu'elle "chauffent" avant d'en obtenir la quintescence, mais tout de même, une fois bien chaud, hotspot est sensé avoir tout précompilé comme gcj.
Avez-vous des benchmark sous la main pour affirmer que gcj est "bien sûr" plus performant que java ? J'aimerais bien les lire avant de me lancer dans la compilation d'un programme énorme de mon cru qui a des besoins cruciaux en performance ... je n'ai rien trouvé sur leur site, mais ce que je lis là ne m'impressione franchement pas (http://www.shudo.net/jit/perf-20000921/, bon ça date de quatre ans !), et les autres littératures font l'apologie de sa petite occupation mémoire (footprint), mais certainement pas de performances délirantes ...
Votre propre expérience va dans ce sens ? C'est bien plus rapide avec gcj ?
En tout cas, le développement en lui-même doit être considérablement ralenti (pas de tests unitaires à la compilation sans linker autant de programmes que tests ...)
Jean-Marc Vanel
Jean Bernard Root wrote:
Bonjour,
Il est bien sûr + performant que Java, et il est train d'inclure les bibliothèques manquantes java.* et javax.* .
Ce "bien sûr" me gène.
Je n'arrive pas à comprendre commen gcj s'abstrait de façon aussi triviale des problèmes de la VM :
- le processus de GC, qui est la source de beaucoup des "problèmes" de performances de java, est assuré par un gros runtime.
Le ramasse-miettes (Garbage Collector pour les intimes) est assuré par le projet: Boehm-Demers-Weiser conservative garbage collector http://www.hpl.hp.com/personal/Hans_Boehm/gc/
C'est un remplacement de malloc et new qui est utilisé par plein de projets.
- on linke des .o natif, c'est vrai, mais ils ne font pas grand chose d'autres que d'appeler directement des fonctions dans le runtime Il y a du vrai mais:
- du code purement algorithmique avec des types simples ou des classes maison peut ne rien appeler dans le runtime - si besoin est, après profiling, on peut implémenter les classes on méthodes couteuses en C++ avec JNI ou CNI Et on bénéficie du savoir-faire d'un véritable compilateur.
- au final, on arrive à faire exactement ce que fait la VM, interprêter et pré-compiler du byte code. En théorie, oui, en pratique non. J'ai fait ici un test (naïf mais
récent de quelques langages et environnements: http://jmvanel.free.fr/perf/java-cpp.html
J'ai parlé à un développeur de gcj à la conférence FOSDEM, et je pense que gcj s'est amélioré depuis. En tous cas il y a un facteur 10 entre C++ et Java.
Il est vrai que les VM modernes avec "-server" se comportent un peu comme des diesels; il faut qu'elle "chauffent" avant d'en obtenir la quintescence, mais tout de même, une fois bien chaud, hotspot est sensé avoir tout précompilé comme gcj. J'ai testé ça aussi, mais en fait pour un programme très court comme mon
test, qu'on fait tourner quelques secondes, il n'y a aucune différence.
Avez-vous des benchmark sous la main pour affirmer que gcj est "bien sûr" plus performant que java ? J'aimerais bien les lire avant de me lancer dans la compilation d'un programme énorme de mon cru qui a des besoins cruciaux en performance ... Une compilation ne coûte rien et peut rapprter gros ...
je n'ai rien trouvé sur leur site,
mais ce que je lis là ne m'impressione franchement pas (http://www.shudo.net/jit/perf-20000921/, bon ça date de quatre ans !), et les autres littératures font l'apologie de sa petite occupation mémoire (footprint), mais certainement pas de performances délirantes ...
Votre propre expérience va dans ce sens ? C'est bien plus rapide avec gcj ?
En tout cas, le développement en lui-même doit être considérablement ralenti (pas de tests unitaires à la compilation sans linker autant de programmes que tests ...)
On peut continuer à développer sur plateforme JDK, et faire les test finaux et le déploiement avec gcj.
Jean Bernard Root wrote:
Bonjour,
Il est bien sûr + performant que Java, et il est train d'inclure les
bibliothèques manquantes java.* et javax.* .
Ce "bien sûr" me gène.
Je n'arrive pas à comprendre commen gcj s'abstrait de façon aussi
triviale des problèmes de la VM :
- le processus de GC, qui est la source de beaucoup des "problèmes" de
performances de java, est assuré par un gros runtime.
Le ramasse-miettes (Garbage Collector pour les intimes) est assuré par
le projet:
Boehm-Demers-Weiser conservative garbage collector
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
C'est un remplacement de malloc et new qui est utilisé par plein de projets.
- on linke des .o natif, c'est vrai, mais ils ne font pas grand chose
d'autres que d'appeler directement des fonctions dans le runtime
Il y a du vrai mais:
- du code purement algorithmique avec des types simples ou des classes
maison peut ne rien appeler dans le runtime
- si besoin est, après profiling, on peut implémenter les classes on
méthodes couteuses en C++ avec JNI ou CNI
Et on bénéficie du savoir-faire d'un véritable compilateur.
- au final, on arrive à faire exactement ce que fait la VM, interprêter
et pré-compiler du byte code.
En théorie, oui, en pratique non. J'ai fait ici un test (naïf mais
récent de quelques langages et environnements:
http://jmvanel.free.fr/perf/java-cpp.html
J'ai parlé à un développeur de gcj à la conférence FOSDEM, et je pense
que gcj s'est amélioré depuis. En tous cas il y a un facteur 10 entre
C++ et Java.
Il est vrai que les VM modernes avec "-server" se comportent un peu
comme des diesels; il faut qu'elle "chauffent" avant d'en obtenir la
quintescence, mais tout de même, une fois bien chaud, hotspot est sensé
avoir tout précompilé comme gcj.
J'ai testé ça aussi, mais en fait pour un programme très court comme mon
test, qu'on fait tourner quelques secondes, il n'y a aucune différence.
Avez-vous des benchmark sous la main pour affirmer que gcj est "bien
sûr" plus performant que java ? J'aimerais bien les lire avant de me
lancer dans la compilation d'un programme énorme de mon cru qui a des
besoins cruciaux en performance ...
Une compilation ne coûte rien et peut rapprter gros ...
je n'ai rien trouvé sur leur site,
mais ce que je lis là ne m'impressione franchement pas
(http://www.shudo.net/jit/perf-20000921/, bon ça date de quatre ans !),
et les autres littératures font l'apologie de sa petite occupation
mémoire (footprint), mais certainement pas de performances délirantes ...
Votre propre expérience va dans ce sens ? C'est bien plus rapide avec gcj ?
En tout cas, le développement en lui-même doit être considérablement
ralenti (pas de tests unitaires à la compilation sans linker autant de
programmes que tests ...)
On peut continuer à développer sur plateforme JDK, et faire les test finaux
et le déploiement avec gcj.
Il est bien sûr + performant que Java, et il est train d'inclure les bibliothèques manquantes java.* et javax.* .
Ce "bien sûr" me gène.
Je n'arrive pas à comprendre commen gcj s'abstrait de façon aussi triviale des problèmes de la VM :
- le processus de GC, qui est la source de beaucoup des "problèmes" de performances de java, est assuré par un gros runtime.
Le ramasse-miettes (Garbage Collector pour les intimes) est assuré par le projet: Boehm-Demers-Weiser conservative garbage collector http://www.hpl.hp.com/personal/Hans_Boehm/gc/
C'est un remplacement de malloc et new qui est utilisé par plein de projets.
- on linke des .o natif, c'est vrai, mais ils ne font pas grand chose d'autres que d'appeler directement des fonctions dans le runtime Il y a du vrai mais:
- du code purement algorithmique avec des types simples ou des classes maison peut ne rien appeler dans le runtime - si besoin est, après profiling, on peut implémenter les classes on méthodes couteuses en C++ avec JNI ou CNI Et on bénéficie du savoir-faire d'un véritable compilateur.
- au final, on arrive à faire exactement ce que fait la VM, interprêter et pré-compiler du byte code. En théorie, oui, en pratique non. J'ai fait ici un test (naïf mais
récent de quelques langages et environnements: http://jmvanel.free.fr/perf/java-cpp.html
J'ai parlé à un développeur de gcj à la conférence FOSDEM, et je pense que gcj s'est amélioré depuis. En tous cas il y a un facteur 10 entre C++ et Java.
Il est vrai que les VM modernes avec "-server" se comportent un peu comme des diesels; il faut qu'elle "chauffent" avant d'en obtenir la quintescence, mais tout de même, une fois bien chaud, hotspot est sensé avoir tout précompilé comme gcj. J'ai testé ça aussi, mais en fait pour un programme très court comme mon
test, qu'on fait tourner quelques secondes, il n'y a aucune différence.
Avez-vous des benchmark sous la main pour affirmer que gcj est "bien sûr" plus performant que java ? J'aimerais bien les lire avant de me lancer dans la compilation d'un programme énorme de mon cru qui a des besoins cruciaux en performance ... Une compilation ne coûte rien et peut rapprter gros ...
je n'ai rien trouvé sur leur site,
mais ce que je lis là ne m'impressione franchement pas (http://www.shudo.net/jit/perf-20000921/, bon ça date de quatre ans !), et les autres littératures font l'apologie de sa petite occupation mémoire (footprint), mais certainement pas de performances délirantes ...
Votre propre expérience va dans ce sens ? C'est bien plus rapide avec gcj ?
En tout cas, le développement en lui-même doit être considérablement ralenti (pas de tests unitaires à la compilation sans linker autant de programmes que tests ...)
On peut continuer à développer sur plateforme JDK, et faire les test finaux et le déploiement avec gcj.
