Tu ne vois pas la différence avec SDL qui propose une api pour les jeux, avec gestion des sprites, etc ?
Non, je ne vois pas la différence, puisque conceptuellement il n'y en a aucune.
Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
Donc tu es train de me dire que si la bibliothèque utilisée est mal programmée, les performances du langage qui appellent la bibliothèque sont plus importantes que si la bibliothèque est bien écrite (en toute logique, c'est l'inverse puisqu'il y a moins d'overhead) ? Tu n'as pas l'impression de raconter n'importe quoi ?
Du reste les bibliothèques ont bon dos dans ton argumentation : si une GUI en Java rame c'est à cause de Swing ; si un jeu en Java tourne correctement c'est d'autant mieux car la bibliothèque sous-jacente est pourrie. Heureusement que tu finis tous tes messages en disant que tes interlocuteurs sont de mauvaise foi :-)
Je ne dis pas le contraire, je réponds à l'affirmation stupide que Java ça rame
C'est marrant : pour une fois que je ne dis pas cela, tu te mets en tête de le réfuter. C'est une obsession chez toi ?
Il existe des bibliothèques Java qui permettent de faire de la programmation orientée objet en pur Java (pour l'utilisateur de la bibliothèque) tout en obtenant d'excellentes performances.
Je ne comprends pas : il faut une bibliothèque pour faire de l'objet performant en Java ? En C++, en Ada 95, c'est livré d'origine.
Mais tu es vraiment crétin, c'est ça ?
Je ne veux pas t'imiter dans l'insulte, mais j'impression que c'est toi qui est trop crétin pour comprendre que :
- je suis d'accord depuis le début que les primitives graphiques sont codées en natif
- c'est précisément l'argument que j'employais pour dire que le "rendu complexe" (je rigole doucement) d'Arkanae ne prouvait rien quant aux performances de Java
l'occupation mémoire (vrai problème mais intimement lié à l'aspect très dynamique du langage)
C'est supposément un mémo interne Sun Microsystems. Voici un passage qui concerne l'occupation mémoire de Java (les chiffres sont crédibles et restent à peu près valables à mon avis) :
« Given this data, it appears that the JRE can actually be simpler than the Python RE since Java does at least some of this work at compile time. The example above of "Hello World" is a good method for getting an idea of the minimum support code required at runtime. This support code includes garbage collector, byte code interpreter, exception processor and the like. Hello World written in Java2 requires 9M for this most basic support infrastructure. By comparison, this is slightly larger than automountd on Solaris8. The Python runtime required to execute Hello World is roughly 1.6M.
Further examples of what is possible include the compiling OO languages Eiffel and Sather which fit their garbage collector, exception processor and other infrastructure into roughly 400K of resident set. While the Java VM (as demonstrated above) grows rapidly as more complex code is executed, the Python VM grows quite slowly. Indeed, an inventory control program written entirely in Python having a SQL database, a curses UI, and network connectivity requires only 1.7M of resident set. This seems to indicate that the resident set requirements of the JRE could be reduced by at least 80%. »
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à -1.
Non, je ne vois pas la différence, puisque conceptuellement il n'y en a aucune.
Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
Donc tu es train de me dire que si la bibliothèque utilisée est mal programmée, les performances du langage qui appellent la bibliothèque sont plus importantes que si la bibliothèque est bien écrite (en toute logique, c'est l'inverse puisqu'il y a moins d'overhead) ? Tu n'as pas l'impression de raconter n'importe quoi ?
Du reste les bibliothèques ont bon dos dans ton argumentation : si une GUI en Java rame c'est à cause de Swing ; si un jeu en Java tourne correctement c'est d'autant mieux car la bibliothèque sous-jacente est pourrie. Heureusement que tu finis tous tes messages en disant que tes interlocuteurs sont de mauvaise foi :-)
Je ne dis pas le contraire, je réponds à l'affirmation stupide que Java ça rame
C'est marrant : pour une fois que je ne dis pas cela, tu te mets en tête de le réfuter. C'est une obsession chez toi ?
Il existe des bibliothèques Java qui permettent de faire de la programmation orientée objet en pur Java (pour l'utilisateur de la bibliothèque) tout en obtenant d'excellentes performances.
Je ne comprends pas : il faut une bibliothèque pour faire de l'objet performant en Java ? En C++, en Ada 95, c'est livré d'origine.
Mais tu es vraiment crétin, c'est ça ?
Je ne veux pas t'imiter dans l'insulte, mais j'impression que c'est toi qui est trop crétin pour comprendre que :
- je suis d'accord depuis le début que les primitives graphiques sont codées en natif
- c'est précisément l'argument que j'employais pour dire que le "rendu complexe" (je rigole doucement) d'Arkanae ne prouvait rien quant aux performances de Java
l'occupation mémoire (vrai problème mais intimement lié à l'aspect très dynamique du langage)
Voici une URL intéressante :
http://internalmemos.com/memos/memodetails.php?memo_id=1321(...)
C'est supposément un mémo interne Sun Microsystems. Voici un passage qui concerne l'occupation mémoire de Java (les chiffres sont crédibles et restent à peu près valables à mon avis) :
« Given this data, it appears that the JRE can actually be simpler than the Python RE since Java does at least some of this work at compile time. The example above of "Hello World" is a good method for getting an idea of the minimum support code required at runtime. This support code includes garbage collector, byte code interpreter, exception processor and the like. Hello World written in Java2 requires 9M for this most basic support infrastructure. By comparison, this is slightly larger than automountd on Solaris8. The Python runtime required to execute Hello World is roughly 1.6M.
Further examples of what is possible include the compiling OO languages Eiffel and Sather which fit their garbage collector, exception processor and other infrastructure into roughly 400K of resident set. While the Java VM (as demonstrated above) grows rapidly as more complex code is executed, the Python VM grows quite slowly. Indeed, an inventory control program written entirely in Python having a SQL database, a curses UI, and network connectivity requires only 1.7M of resident set. This seems to indicate that the resident set requirements of the JRE could be reduced by at least 80%. »