A l'est de Java

Démarré par Noxneo, 26 Décembre 2010 à 04:33

0 Membres et 1 Invité sur ce sujet

26 Décembre 2010 à 04:33 Dernière édition: 02 Janvier 2011 à 23:39 par Guillaume
Citation de: Wouf le 26 Décembre 2010 à 00:07
(oublie Java, c'est lent et ça plante :ninja:).




Citation de: Guillaume le 26 Décembre 2010 à 04:33
Citation de: Wouf le 26 Décembre 2010 à 00:07
(oublie Java, c'est lent et ça plante :ninja:).
Mieux vaut tout coder soit même en assembleur, c'est sûr que ce sera plus rapide ! (après pour ne pas planter on repassera :P)
Citation
Ash Nazg Durbatulùk, Ash Nazg Gimbatul,
Ash Nazg Thrakatulùk agh bruzum-ishi krimpatul.
The fellowship of the Ring - J.R.R. Tolkien

Citation de: BenObiWan le 26 Décembre 2010 à 11:20
Citation de: Guillaume le 26 Décembre 2010 à 04:33
Citation de: Wouf le 26 Décembre 2010 à 00:07
(oublie Java, c'est lent et ça plante :ninja:).
Mieux vaut tout coder soit même en assembleur, c'est sûr que ce sera plus rapide ! (après pour ne pas planter on repassera :P)

http://www.menuetos.net/

:P

Hey, je déconne  :D

Puis là, tu t'enfonces. Chez moi, Minecraft rame, plante et les graphs sont pourtant pas fameux :P
Les graphs franchement je m'en tappe, tant que c'est fun. Mais voilà, si la vm foire, ça l'est tout de suite moins ^^
Biensûr, il est toujours possible de contourner ces difficultés et d'optimiser son programme en défiant les habitudes Java, mais alors autant passer à un autre langage.

Attention, j'aime bien Java. Surtout dans un but éducatif par rapport à la POO. Ca oblige le programmeur à prendre de bonnes habitudes. Mais pour un jeu, franchement bof, quoi.
Puis même, t'as déjà essayé d'utiliser l'interface de Matlab en ssh -X ?  :mrgreen:

En plus, depuis qu'Oracle l'a récupéré, je m'inquiète quelque peu sur son avenir et aussi par rapport à la portabilité de la VM officielle. D'ailleurs, la communauté semble se tourner vers OpenJDK, une vm open-source. C'est bien, mais elle est encore plus entâchée de bugs. En définitive, Java restera suffisemment performant ... sous Windows. Et s'il perd sa portabilité, à quoi bon poursuivre dans cette voie ... C'était l'une des raisons qui ont motivé sa conception, après tout.

Citation de: BenObiWan le 26 Décembre 2010 à 11:20
Mieux vaut tout coder soit même en assembleur, c'est sûr que ce sera plus rapide ! (après pour ne pas planter on repassera :P)
Vive la portabilité ...
Après, tu peux faire un morpion en Brainfuck si tu veux x3
Je ne voulais pas critiquer les langages non compilés. Il y a d'autres langages interprêtés ou à VM qui possèdent une meilleure implémentation, c'est tout. Après, c'est toujours mieux de les utiliser en complément à un langage compilé, plus judicieux pour les parties les plus coûteuses du programme (sauf ptet pour le prototype).

Cela dit, je me trompe peut être ... Ca vous tente un nouveau topic pour en parler ?  :)
Marre des pavés ? Marchez dans la boue!
ハハ、あなたは私の罠に落ちた!

Citation de: Wouf le 29 Décembre 2010 à 00:46
Les graphs franchement je m'en tappe, tant que c'est fun. Mais voilà, si la vm foire, ça l'est tout de suite moins ^^
Biensûr, il est toujours possible de contourner ces difficultés et d'optimiser son programme en défiant les habitudes Java, mais alors autant passer à un autre langage.

j'aime bien Java. Surtout dans un but éducatif par rapport à la POO. Ca oblige le programmeur à prendre de bonnes habitudes. Mais pour un jeu, franchement bof, quoi.
Hum si c'est la vm java dont tu te plains, je connais des programmes java qui tournent 24/24 pendant des mois sans planter (et pas sans rien faire). Elle est vachement stable donc accuser la vm mouais...
Évidemment si le problème est un OutOfMemoryError c'est le programme qui est mal codé, mais ça que ce soit java ou un autre langage, le problème est le même.

Citation de: Wouf le 29 Décembre 2010 à 00:46
En plus, depuis qu'Oracle l'a récupéré, je m'inquiète quelque peu sur son avenir et aussi par rapport à la portabilité de la VM officielle. D'ailleurs, la communauté semble se tourner vers OpenJDK, une vm open-source. C'est bien, mais elle est encore plus entâchée de bugs. En définitive, Java restera suffisemment performant ... sous Windows. Et s'il perd sa portabilité, à quoi bon poursuivre dans cette voie ... C'était l'une des raisons qui ont motivé sa conception, après tout.
OpenJDK = Sun => Oracle hein ;)
C'est du opensource avec une petite laisse. Sun avait prévu de faire disparaitre la version propriétaire, Oracle a annoncé une version proprio et payante plus optimisée. Niveau bug spécifique à OpenJdk ça devrait disparaitre avec la version 7 en théorie.

Citation de: Wouf le 29 Décembre 2010 à 00:46
Citation de: BenObiWan le 26 Décembre 2010 à 11:20
Mieux vaut tout coder soit même en assembleur, c'est sûr que ce sera plus rapide ! (après pour ne pas planter on repassera :P)
Vive la portabilité ...
Do you understand the concept of irony?
Citation
Ash Nazg Durbatulùk, Ash Nazg Gimbatul,
Ash Nazg Thrakatulùk agh bruzum-ishi krimpatul.
The fellowship of the Ring - J.R.R. Tolkien

02 Janvier 2011 à 23:23 #5 Dernière édition: 02 Janvier 2011 à 23:25 par Guillaume
Le problème du java, c'est que c'est mis entre les mains de programmeurs incompétents/débutant qui ne cherchent pas a comprendre du moment que leur programme marche un minimum. Du genre des mecs qui utilisent les méthodes de tri standard qu'ils ne pourraient même pas implémenter eux même. Ou encore pire, des étudiants a qui on donne ça et on ne demande pas de chercher plus loin.

Apres, si tu prends un bon programmeur, il fera des bons programmes, que tu lui demandes de faire du java, du c ou du c#.

02 Janvier 2011 à 23:35 #6 Dernière édition: 02 Janvier 2011 à 23:43 par Wouf
CitationDo you understand the concept of irony?
Naaaa x3
Mais si hein, regarde la phrase juste en dessous ^^

Je t'avoue que je n'ai jamais compris d'où venaient les failles de plus en plus nombreuses de la part de la vm ... Serait-ce possible que seule la version Linux soit en cause  :o ?

CitationÉvidemment si le problème est un OutOfMemoryError c'est le programme qui est mal codé, mais ça que ce soit java ou un autre langage, le problème est le même.
Entièrement d'accord !
Et c'est d'autant plus gratifiant pour le programmeur d'y arriver  ;)
Mais j'ai l'impression que ce genre de programmes biens codés sont malheureusement plus rares en Java, où du moins, sont moins mis en avant. Peut être parce que le langage a eu un tel engouement que tous les kikoolol s'y sont mis et lui ont fait de l'ombre. Tu sais, je ne demande qu'à croire au Java, qui reste pour moi une belle expérience. Mais j'ai beau changer de langage, je reviens toujours sur le C et le C++ en dépit de leurs manques (srtt syntaxique pour le C++). D'autre part, je suis heureux d'apprendre que la version 7 du Java améliorera l'openJDK  :)
Tout autant que de découvrir un nouveau programmeur Java qui pourra faire évoluer mon raisonnement ^^

PS : Serait-il possible qu'un modo découpe le sujet pour en faire un nouveau topic, afin que l'on puisse éventuellement poursuivre sans partir en HS. Merci d'avance =3


EDIT : arg, Guillaume a posté entre-temps xD
RE-EDIT : Merci Guillaume (punaise, faudrait un diminutif là, c'est long à tapper  :ninja:)
Marre des pavés ? Marchez dans la boue!
ハハ、あなたは私の罠に落ちた!

Citation de: Wouf le 02 Janvier 2011 à 23:35
Peut être parce que le langage a eu un tel engouement que tous les kikoolol s'y sont mis et lui ont fait de l'ombre.

C'est à peu près ça. Il est de plus en plus utilisé pour enseigner la programmation dans les universités, parce qu'il permet d'attaquer direct l'orienté objet, de faire faire aux étudiants des trucs qu'ils feront en entreprise, et que c'est possible de rapidement faire des applications moyennement complexes vu qu'il ne faut pas s'emmerder avec tout ce qui est structures de données, méthodes de tri/ajout/etc., gestion mémoire,...

Et les entreprises s'en servent bcp pour les raccourcis sus-cités, ainsi qu'une portabilité qui leur permet d'étendre leurs plateformes cible sans rajouter de temps de développement, de mettre des développeurs peu expérimentés dessus, etc.

Bref le Java en tant que le langage, moi je le trouve très bien conçu, et la VM n'a franchement pas à pâlir comparé à ce qui se fait de similaire.
Juste que le langage est victime de son succès :P

Un gros plus un sur tout ce qu'à dis Guillaume. :D
Citation de: Wouf le 02 Janvier 2011 à 23:35
CitationDo you understand the concept of irony?
Naaaa x3
Mais si hein, regarde la phrase juste en dessous ^^
:P

Citation de: Wouf le 02 Janvier 2011 à 23:35
Je t'avoue que je n'ai jamais compris d'où venaient les failles de plus en plus nombreuses de la part de la vm ... Serait-ce possible que seule la version Linux soit en cause  :o ?
J'utilise la version linux quotidiennement et de manière intensive, jamais eu de problèmes de failles dans la VM :o
La seule fois ou j'ai réussi à la tuer c'est en changeant un fichier .jar pendant qu'un programme tournait (et quand il a eu besoin d'une classe dans ce fichier jar boom avec un joli message de debug, pas une simple stack trace)
Tu veux dire quoi par faille en fait?
Citation
Ash Nazg Durbatulùk, Ash Nazg Gimbatul,
Ash Nazg Thrakatulùk agh bruzum-ishi krimpatul.
The fellowship of the Ring - J.R.R. Tolkien

Ben je ne sais pas trop ... soit je vois ma RAM s'emballer alors même que j'ai fermé la VM  :blink:
Soit mes programmes se ferment sans rien dire et je perds tout mon travail x3
Puis le manque de réactivité des interfaces telles que Matlab (bon mon laptop se fait vieux, certes ^^, mais je n'ai pas ce problème avec les autres programmes C, C++ ou python).
Les applets Java qui surchargent mon processeur (mais c'est pareil pour flash ^^).
Et enfin, le site de notre université qui affiche des bugs de plus en plus délirants (base de données Oracle justement).
Mais ça, je suis sûr que c'est un problème de programmation :P
(s'il y a un membre du Segi parmi vous, patapé XD)
Faudrait aussi que j'essaie avec Mono pour voir s'il y a une différence

Pour continuer dans la lancée de ce qui a été dit précédemment (en fait, ce que j'écrivais pendant que Beno a posté  :D):
Ouais, sans doute ^^
C'est clair que le C++ est beaucoup plus dur à maîtriser (je suis encore loin de pouvoir m'en vanter).
Et beaucoup codent souvent comme des malpropres, malheureusement x3

Si j'ai bien capté, c'est dû au fait que le C++ est un langage évolutif, auquel on greffe de nouvelles fonctionnalités au cours du temps, tout en préservant son passé pour des raisons de rétrocompatibilité.
Si je ne me trompe pas, une des forces du Java a été de profiter de l'expérience de tels langage pour ne garder que les tournures satisfaisantes. Lui donnant ainsi son aspect de langage purifié (pour l'époque).

Il y a encore un an, j'adorais le Java pour tout celà. Aussi parce qu'il force les bonnes habitudes (exception à la moindre dérive, comme par exemple un indice hors du tableau). Il me semblait qu'il introduisait bien la programmation orientée objet, mieux que le C++. J'étais tellement emballé que je créais des exceptions partout, voyais du polymorphisme partout, ... Bref, je visais la modularité par dessus tout.
Conscient que le C++ était plus approprié pour développer un jeu vidéo (plus performant), j'ai voulu y translater cette vision des choses. Malheureusement, les libs n'utilisaient pas du tout cette vision des choses, et me faisaient râler (par exemple, l'absence d'exceptions, ...).
Puis, au fil du temps, j'ai vu plein de gens critiquer les performances d'un excès de modularité ...
Et je me suis fait 2 nouveaux amis programmeurs, qui m'ont exposé leur dégoût du Java (trop modulaire et pas assez performant) et du C++ (syntaxe srtt). Au final, la désillusion a pris le pas ... Mais je suis resté sur le C++ car il suffit de coder proprement pour casser la plupart des arguments esthétiques que l'on m'opposait.
En fait, je préfère le C mais bon ... Y a pas de namespaces ^^
Marre des pavés ? Marchez dans la boue!
ハハ、あなたは私の罠に落ちた!

Mouais, je suis en train d'avoir la vision que en gros, quand il s'agit de faire un projet "non spécialisé" à but seul de "production" (ie. pas un truc de recherche, ou fait pour un but de performance/précision extrême), on peut prendre n'importe quel langage grand public - C++/Java/etc. - et que il faut arrêter de se poser 36000 questions et qu'il faut juste commencer à coder.

Pour Project Infinite, j'aurais pu me toucher la nouille pendant 30 ans sur quel langage prendre, quelles bibliothèques, blabla, mais au final j'ai pris ce que j'avais sous la main et je me suis mis au boulot. Passer trois plombes à se décider sur ce genre de choses, c'est le meilleur moyen de ne jamais rien faire- et c'est ce genre de choses qui m'est arrivé par le passé.

Si vous voulez faire un jeu vidéo, prenez un langage que vous aimez bien et avec lequel vous êtes confortable- que ce soit du C++, Python, Java, Game Maker- prenez les bibliothèques qui vous embêtent le moins, et mettez vous à coder.

Bon après ça ne s'applique pas à toutes les circonstances; dans mon boulot par exemple, c'est fréquent de faire des trucs spécialisés où le choix d'un langage atypique (Haskell, Prolog, Clojure, etc.) fait le jour et la nuit comparé à quelque chose de plus générique.

On est d'accord : trop de questions tue !
J'ai aussi abandonné pas mal de projets à cause de ça :mrgreen:
D'un autre côté, ne pas se poser assez de question mène justement à des projets kikoolol plein de problèmes.
Si c'est pour des petits projets (pour essayer qqch par exemple) pourquoi pas, mais quand on vise le long terme, autant prendre ses précautions. Et c'est au début du projet qu'il faut se poser ces questions et pas après, sinon on risque tout recommencer x3
Je vois ça comme un investissement.
Puis même si on ne mène pas un projet à son terme, pour peu que l'on se soit posé des questions, on a gagné en expérience. Mais récemment, j'ai un peu changé mon fusil d'épaule et je me dis qu'avant de me lancer dans de tels projets, il me faut d'avantage d'expérience. Du coup, j'ai pensé à me lancer dans plusieurs petits projets, chacun apportant sa touche de nouveauté. Et de temps en temps, je complète mes notes sur les  "éventuels projets à longs termes" que j'aimerai un jour concrétiser. On verra ce que ça donne ^^
La plupart resteront probablement au stade papier, mais ça a le mérite d'entretenir ma motivation.
Y en a justement un où je m'amuse à concevoir les spécifications du langage de prog de mes rêves, en combinant mes expériences des différents langages. A chacun son château en Espagne  :D

Oui, pour des petits jeux, je conseille du plus haut niveau. Game Maker n'est pas mal (même s'il lui manque des fonctions locales aux objets). J'ai récemment ré-essayé Game Editor qui est vraiment cross-platform, mais l'interface n'est pas des plus plaisantes. Ca aussi ça doit rentrer en compte, je trouve. Même la colo syntaxique peut contribuer à la productivité  :P
J'étais en train d'étudier Python/Pygame pour faire mes essais de jeu. Lua/Löve me parraît bien aussi, faudra que j'essaie un de ces 4 ^^
Marre des pavés ? Marchez dans la boue!
ハハ、あなたは私の罠に落ちた!

Ca résume bien ma pensée à propos de RPG Maker aussi :rolleyes:
Finalement, quoiqu'on utilise comme langage / outil / environnement, si on ne fait pas un minimum d'efforts et qu'on fait de la merde, bah évidemment, ça sera lent, ça va ramer et ça sera pourri.

Citation de: Wouf le 03 Janvier 2011 à 00:24
Ben je ne sais pas trop ... soit je vois ma RAM s'emballer alors même que j'ai fermé la VM  :blink:
Soit mes programmes se ferment sans rien dire et je perds tout mon travail x3
Puis le manque de réactivité des interfaces telles que Matlab (bon mon laptop se fait vieux, certes ^^, mais je n'ai pas ce problème avec les autres programmes C, C++ ou python).
Les applets Java qui surchargent mon processeur (mais c'est pareil pour flash ^^).
La ram alors que tu as coupé le process c'est pas la vm, vu que si le process ne tourne plus je vois pas comment il peut encore prendre de la ram ;)
Les programmes qui plantent sans rien dire et le manque de réactivité -> mal codés.
Les applets ouais ça pue. D'ailleurs je pense que toute l'histoire "java c'est lent" vient des applets, qui forcément vu qu'ils faut charger toute la vm dans une sandbox à coté du navigateur sont lentes... Surtout quand on compare aux langages purement web qui sont pris en charge directement par le serveur et le navigateur. D'ailleurs ils veulent modulariser la VM pour entre autre améliorer ça (je sais plus si c'est dans Java 7 ou repoussé dans le 8)

Coté choix du langage pour faire un jeu amateur, à part éventuellement si c'est pour de la 3D, Java convient très bien. Pour tirer parti de la carte graphique et faire un beau jeu 3D, Java n'est pas le langage que je choisirait. Et c'est peut être juste un apriori à la con du style "Java c'est lent", je n'ai jamais testé la 3D ni en Java ni dans un autre langage. Pour faire un jeu en 2D je ne vois pas pourquoi Java ne serait pas approprié.

C++ j'ai regardé pour faire un projet il y a quelques années. Ce qui m'avait bloqué c'est l'absence de thread dans la bibliothèque standard. (Et à l'époque ils n'avaient pas encore annoncé qu'ils incluraient boost) Et je n'ai pas eu à nouveau l'occasion de tester depuis.

Et pour d'autres projets quels qu'il soient, c'est sur que se poser 36000 questions sur le langage ne sert à rien :P
Il faut juste réfléchir un peu à ce que l'on veut faire, et surtout voir quels langages sont maitrisées par les gens qui doivent participer au projet. (surtout si on est pressé :P)
Citation
Ash Nazg Durbatulùk, Ash Nazg Gimbatul,
Ash Nazg Thrakatulùk agh bruzum-ishi krimpatul.
The fellowship of the Ring - J.R.R. Tolkien

Citation de: Wouf le 03 Janvier 2011 à 01:31
D'un autre côté, ne pas se poser assez de question mène justement à des projets kikoolol plein de problèmes.
Si c'est pour des petits projets (pour essayer qqch par exemple) pourquoi pas, mais quand on vise le long terme, autant prendre ses précautions. Et c'est au début du projet qu'il faut se poser ces questions et pas après, sinon on risque tout recommencer x3
Je vois ça comme un investissement.

Attention, je ne parle pas de bâcler la conception/spécs du pojet. Bien sûr qu'il faut s'attarder sur ces éléments, qui ne sont que très peu reliés au choix du langage.

Maintenant que tu le dis, c'est vrai que j'ai confondu les 2 ^^

Je suis d'accord, le choix du langage n'a pas énormément d'impacts en général. Les perfs associées ne varient généralement que d'un facteur multiplicatif. Et cette différence s'estompe avec les progrès technologiques : ce qui rame aujourd'hui sur mon ordi ne ramera probablement plus demain. Rien à voir avec un choix algorithmique et la complexité qui en découle  ^_^

En fait, embarqué ou non ; haut ou bas niveau ; pradigme oo, impératif ou fonctionnel ; au script ou à la souris ; ... La question du langage se résume srtt à ça (contraintes cible, temps, argent).
Bref faut pas une plombe pour trancher, c'est clair  :lol:

Le reste est plus d'ordre subjectif (syntaxe, habitudes, ...). Le principal étant d'être à l'aise et qu'il plaise à l'équipe.
Z'avez raison  :)

Citation de: BenObiWan le 03 Janvier 2011 à 12:19
Les applets ouais ça pue. D'ailleurs je pense que toute l'histoire "java c'est lent" vient des applets, qui forcément vu qu'ils faut charger toute la vm dans une sandbox à coté du navigateur sont lentes... Surtout quand on compare aux langages purement web qui sont pris en charge directement par le serveur et le navigateur. D'ailleurs ils veulent modulariser la VM pour entre autre améliorer ça (je sais plus si c'est dans Java 7 ou repoussé dans le 8)
Ah ouais, maintenant que tu le dis, je me rappelle que c'est le premier argument qui m'avait amené à réfléchir sur les inconvénients du langage. Après réflexion, j'en ai peut-être fait une généralisation abusive. Je ne savais pas qu'il y avait une différence notable entre les applets et les programmes classiques.  :ninja:

Citation de: BenObiWan le 03 Janvier 2011 à 12:19
Pour tirer parti de la carte graphique et faire un beau jeu 3D, Java n'est pas le langage que je choisirait. Et c'est peut être juste un apriori à la con du style "Java c'est lent", je n'ai jamais testé la 3D ni en Java ni dans un autre langage.
J'avais vu un site qui montrait des réalisation 3D en Java qui n'étaient que 2x plus lentes qu'en C++. De toutes façons, ça utilise des libs binding C style OpenGL. Donc 3D ou 2D, je crois pas que ça change grand chose (sauf avec Java2D qui est en pur Java je crois). C'est comme pour SolarusDX, il est scripté en Lua ok, mais il profite quand même des algos coûteux en C et C++.
Les lenteurs éventuelles proviendraient de la VM et si elle est stable, ça ne devrait pas poser de soucis.  ^_^

En fait, je suis en train de me demander si mes problèmes de lenteur ne viennent pas de la combinaison de Linux sur une machine peu puissante. En effet, j'ai remarqué que Linux aime bien prendre la quasi totalité de la RAM non occupée pour en faire de la cache disque dur. Heureusement, la cache étant dynamique, elle diminue dès qu'un nouveau programme s'ouvre et demande sa RAM. Mais ça ne se fait pas instantanément. Et si la demande de RAM est trop importante, tout est alloué en swap sur le disque dur (paradoxe x3), plutôt que de ralentir le temps que la RAM se libère. Du coup, c'est très lent !
Et si je démonte/remonte ma partition swap, elle est certes tranférée dans la RAM, mais pas au même endroit que le reste de la mémoire du programme. Ce qui rompt donc avec le principe de localité (2 accès proches en temps le sont aussi en mémoire) --> cache miss entre cache processeur et RAM.

Tout ça, c'est indépendant de Java. Ca m'arrive fréquemment quand je lis de longs pdf.  :P
En fait, ce n'est pas à l'ouverture du pdf, mais quand je le consulte, donc quand le programme demande plus de RAM en cours d'exécution.
Et je me demande si c'est pas pareil avec la VM. En effet, quand je lance la VM, pas de soucis. Mais quand en cours d'exécution elle demande plus de RAM (à chaque lancement d'un nouveau bytecode Java?) , ça foire ...

Peut être que je me plante carrément dans mon analyse, mais après tout, ça pourrait ptet expliquer cette lenteur vis-à-vis du Java et non des programes natifs en général.  :unsure:
Quant aux autres langages interprètés, je ne remarque sans doute rien parce que leurs logiciels sont en général moins conséquents les logiciels Java. (faudrait une grosse IHM python pour comparer avec Matlab lol)
Z'en pensez quoi ?  :)
Marre des pavés ? Marchez dans la boue!
ハハ、あなたは私の罠に落ちた!

Juste une petite remarque pour rebondir sur Minecraft : le jeu n'est généralement pas lent chez moi, mais j'ai plusieurs fois vu java manger environ 1,2Go de RAM (sur 2Go, et là c'était lent par contre), ce qui est -je trouve- complètement démesuré pour Minecraft quoi... :o (quand je vois que HL2 prend moins de 300Mo à côté).
Je sais même pas si la démo de Crysis prenait autant quand je l'avais testé... c'est dire x).

Donc bon, on peux pas dire que Java soit non plus dépourvu de problèmes côté perfs je pense, Notch code quand même assez bien à ce que je sache :P (après j'ai rien contre les programmes en java en général, j'en utilise plusieurs qui fonctionnent parfaitement).
Côté code j'ai rien à dire, jamais touché au java ^^.

    







Le fait que la machine Java prenne 1.2 Go sur tes 2Go ne veut pas dire grand chose; souvent les VM cachent de manière assez lourde, et prennent tout ce qu'elles peuvent. Sur ces 1.2 Go, il n'y en avait peut être que le quart qui était vraiment utilisé, le reste étant alloué par la VM "au cas où" pour que les allocations soient plus rapides.

Si tu avais eu 512 Mo de RAM, la machine en aurait peut être prise que 300, et les performances auraient été identiques en ce qui te concerne.

Ouais enfin prendre plus d'un Go si seul le quart est utilisé je trouve ça dommage, si les VM sont indépendantes de Java, alors mon coup de gueule c'est pour elles :P. Laisser le choix à l'utilisateur du cache maxi disponible sinon...

    







Ben non c'est pas dommage- avoir de la RAM inutilisée, c'est Mal. La VM en libère selon les demandes de l'OS, mais elle fait en sorte de maximiser ce qu'elle a à sa disposition. Entre avoir de la RAM qui sert à rien ou de la RAM pré-allouée, la 2ème option est la mieux.

Sinon "les VM sont indépendantes de Java" => non en fait la VM est ce qui exécute le code Java. Il faut voir un peu ça comme les vieilles machines à musique, qui prenaient des cartes perforées pour jouer des morceaux: quand on compile un programme Java, on obtient un bytecode (la carte perforée), et la VM est ce qui lit ce bytecode (tout comme la machine à musique lit la carte perforée). Cela permet de réutiliser les cartes perforées où l'on veut, du moment que la machine à musique est construite sur les mêmes spécifications. C'est pour ça que ton programme Java tournera sur la VM de Sun, sous une VM indépendante, sous Linux, Windows, Mac, etc.

De la pré-allocation c'est peut-être bien, mais faudrait le lagg en moins dans ce cas là :P.
Pourquoi du lagg si il y a plus de mémoire que nécessaire de disponible d'ailleurs ?

Merci pour la petite explication en tout cas ^_^.

    







CitationPourquoi du lagg si il y a plus de mémoire que nécessaire de disponible d'ailleurs ?

Si tu parles de Minecraft, il y'a effectivement un lag quand on va dans un chunk non visité au préalable, tout simplement parce qu'il faut le générer. Là c'est le processeur qui taxe.

D'ailleurs, Minecraft n'est pas un exemple idéal pour analyser les performances de Java, tout simplement parce que Notch (en tant que bon codeur :ninja:) a dit qu'il s'occuperait de l'optimisation "plus tard"©

Non mais quand je lagg c'est quand j'ai beaucoup de RAM récupérée par java (l'exemple de tout à l'heure avec le +1Go quoi), ça n'a rien à voir avec la génération de chunks là, quand je me ballade dans de nouveaux endroits et que la consommation est "normale" je n'ai aucun problème :P.

Alors je comprends pas deux choses :
- Pourquoi des fois ça prend 300/600mo, et d'autres fois plus d'un Go ?
- Et surtout : Pourquoi si une grosse partie de ma RAM est pré-allouée dans le but de s'en servir plus rapidement après (d'après ce que j'ai compris), ce qui en résulte c'est du lagg ? Ah moins que le memory leaks touche aussi les clients, et pas que les serveurs SMP ?

    







09 Janvier 2011 à 20:04 #23 Dernière édition: 09 Janvier 2011 à 20:06 par BenObiWan
Citation de: Wouf le 08 Janvier 2011 à 13:09
Citation de: BenObiWan le 03 Janvier 2011 à 12:19
Les applets ouais ça pue. D'ailleurs je pense que toute l'histoire "java c'est lent" vient des applets, qui forcément vu qu'ils faut charger toute la vm dans une sandbox à coté du navigateur sont lentes... Surtout quand on compare aux langages purement web qui sont pris en charge directement par le serveur et le navigateur. D'ailleurs ils veulent modulariser la VM pour entre autre améliorer ça (je sais plus si c'est dans Java 7 ou repoussé dans le 8)
Ah ouais, maintenant que tu le dis, je me rappelle que c'est le premier argument qui m'avait amené à réfléchir sur les inconvénients du langage. Après réflexion, j'en ai peut-être fait une généralisation abusive. Je ne savais pas qu'il y avait une différence notable entre les applets et les programmes classiques.  :ninja:
La grosse différence, c'est que tu dois charger la VM, qui doit downloader l'applet et la lancer. Un programme java en ligne de commande il doit charger la VM et prendre les classes. Ah y'a quasi pas de diff?  :unsure:
Nan la différence n'est pas technique, c'est juste qu'une applet c'est dans ton navigateur, où tu as l'habitude que les pages web se chargent rapidement et donc le temps de chargement de l'applet parait long. Un programme java il doit aussi charger la VM & co, mais on est habitué à ce qu'un programme se charge un peu avant d'être utilisable, donc c'est moins apparent.

Citation de: Daru13 le 08 Janvier 2011 à 16:56
Ouais enfin prendre plus d'un Go si seul le quart est utilisé je trouve ça dommage, si les VM sont indépendantes de Java, alors mon coup de gueule c'est pour elles :P. Laisser le choix à l'utilisateur du cache maxi disponible sinon...
Il y a des options pour ça, d'ailleurs si il prend 1.2Go sur 2Go, c'est que dans Minecraft il a mis une valeur en paramètre du lancement de la jvm. Sans rien paramétrer, dans mes souvenirs une jvm de base prend un truc genre 1/4 de la mémoire physique. Après ça dépend du système d'exploitation, des options qu'on lui passe, de la mémoire dispo etc... C'est un beau bordel d'ailleurs de trouver les bonnes options à passer à un programme java pour la gestion de sa mémoire (notamment le paramétrage du garbage collector) pour tirer la meilleur perf en fonction de son profil d'utilisation de la mémoire.

Citation de: Daru13 le 08 Janvier 2011 à 19:04
Non mais quand je lagg c'est quand j'ai beaucoup de RAM récupérée par java (l'exemple de tout à l'heure avec le +1Go quoi), ça n'a rien à voir avec la génération de chunks là, quand je me ballade dans de nouveaux endroits et que la consommation est "normale" je n'ai aucun problème :P.
Ca s'appelle Swap out / Swap in ça :P

Citation de: Daru13 le 08 Janvier 2011 à 16:56
- Pourquoi des fois ça prend 300/600mo, et d'autres fois plus d'un Go ?
Parce que :P
Sur le même ordi? Mémoire virtuelle ou résidente?

Citation de: Daru13 le 08 Janvier 2011 à 16:56
- Et surtout : Pourquoi si une grosse partie de ma RAM est pré-allouée dans le but de s'en servir plus rapidement après (d'après ce que j'ai compris), ce qui en résulte c'est du lagg ? Ah moins que le memory leaks touche aussi les clients, et pas que les serveurs SMP ?
Alors la j'ai du mal a voir la relation Java <-> memory leak <-> serveur SMP...
Si tu avais une memory leak avec Java tu aurais un beau "OutOfMemoryError" au bout d'un moment, j'ai pas l'impression que quelqu'un ait parlé de ça pour l'instant.
Ensuite un memory leak tu peux en avoir sur autre chose qu'une machine SMP, ça n'a rien à voir, c'est juste un programme mal codé.
Citation
Ash Nazg Durbatulùk, Ash Nazg Gimbatul,
Ash Nazg Thrakatulùk agh bruzum-ishi krimpatul.
The fellowship of the Ring - J.R.R. Tolkien

CitationIl y a des options pour ça, d'ailleurs si il prend 1.2Go sur 2Go, c'est que dans Minecraft il a mis une valeur en paramètre du lancement de la jvm.
Sachant qu'à quelques mo près ma RAM est toujours chargée à peu près pareil quand je lance le jeu, pourquoi j'ai de telles variations de consommation ?

CitationCa s'appelle Swap out / Swap in ça :P
Et... ? C'est normal ?
Si oui, je ne vois pas l'intérêt de récupérer de la RAM pour au final faire lagguer par la suite...

CitationParce que :P
Tout est logique (surtout en info) :ninja:.

CitationSur le même ordi? Mémoire virtuelle ou résidente?
Sur le même ordi, oui. Par contre je ne sais pas c'que c'est la mémoire virtuelle/résidente :P.

CitationAlors la j'ai du mal a voir la relation Java <-> memory leak <-> serveur SMP...
Si tu avais une memory leak avec Java tu aurais un beau "OutOfMemoryError" au bout d'un moment, j'ai pas l'impression que quelqu'un ait parlé de ça pour l'instant.
Ensuite un memory leak tu peux en avoir sur autre chose qu'une machine SMP, ça n'a rien à voir, c'est juste un programme mal codé.
SMP = Survival MultiPlayer, en gros le mode multi de minecraft.
Rien à voir avec une machine ici ^^.

Par rapport au memory leak, je ne sais pas ce que c'est d'un point de vue technique, mais les admins du serveur sur lequel je jouent expliquaient qu'à cause de ça la RAM sur le serveur se remplissait sans se vider (et au bout 'un moment on lagguait comme pas possible et fallait reboot le serveur).
Je me demandais donc si ça touchait aussi les clients minecraft ^_^.

    







Citation de: Daru13 le 09 Janvier 2011 à 20:50
CitationIl y a des options pour ça, d'ailleurs si il prend 1.2Go sur 2Go, c'est que dans Minecraft il a mis une valeur en paramètre du lancement de la jvm.
Sachant qu'à quelques mo près ma RAM est toujours chargée à peu près pareil quand je lance le jeu, pourquoi j'ai de telles variations de consommation ?
Suivant ce qu'il a chargé comme décors/objet etc... Et la dernière fois que le garbage collector java est passé :P

Citation de: Daru13 le 09 Janvier 2011 à 20:50
CitationCa s'appelle Swap out / Swap in ça :P
Et... ? C'est normal ?
Si oui, je ne vois pas l'intérêt de récupérer de la RAM pour au final faire lagguer par la suite...
Oui c'est un processus normal de ton OS qui fait passer les parties inutilisées d'un process dans le swap lorsqu'il a besoin de mémoire, et forcément quand tu les réutilises il doit les recharger et ça fait mal.

Citation de: Daru13 le 09 Janvier 2011 à 20:50
CitationSur le même ordi? Mémoire virtuelle ou résidente?
Sur le même ordi, oui. Par contre je ne sais pas c'que c'est la mémoire virtuelle/résidente :P.
http://fr.wikipedia.org/wiki/M%C3%A9moire_virtuelle

Citation de: Daru13 le 09 Janvier 2011 à 20:50
CitationAlors la j'ai du mal a voir la relation Java <-> memory leak <-> serveur SMP...
Si tu avais une memory leak avec Java tu aurais un beau "OutOfMemoryError" au bout d'un moment, j'ai pas l'impression que quelqu'un ait parlé de ça pour l'instant.
Ensuite un memory leak tu peux en avoir sur autre chose qu'une machine SMP, ça n'a rien à voir, c'est juste un programme mal codé.
SMP = Survival MultiPlayer, en gros le mode multi de minecraft.
Rien à voir avec une machine ici ^^.

Par rapport au memory leak, je ne sais pas ce que c'est d'un point de vue technique, mais les admins du serveur sur lequel je jouent expliquaient qu'à cause de ça la RAM sur le serveur se remplissait sans se vider (et au bout 'un moment on lagguait comme pas possible et fallait reboot le serveur).
Je me demandais donc si ça touchait aussi les clients minecraft ^_^.
Ok GG minecraft d'avoir réutilisé un acronyme informatique classique... SMP = Symmetric multiprocessing = une machine multiprocesseurs. Donc ouais quand tu parles d'un gros serveur SMP moi je comprend une grosse machine multiprocesseurs, je voyais pas ce que ça foutait dans la discussion :P
Et sinon oui si il y a des memory leak dans minecraft, c'est susceptible d'impacter le client aussi.
Citation
Ash Nazg Durbatulùk, Ash Nazg Gimbatul,
Ash Nazg Thrakatulùk agh bruzum-ishi krimpatul.
The fellowship of the Ring - J.R.R. Tolkien

Pour l'histoire de la mémoire virtuelle/résidente, je n'ai aucun partition swap de "prédéfinie" façon Ubuntu si c'est ce que tu voulais dire (en même temps est-ce possible avec Windows ?).

Maintenant je ne sais pas si Vista va piocher sur la partition système quand il en a besoin, il me semble que oui...
M'enfin quand Minecraft consomme beaucoup, je n'ai pas 100% de ma RAM de prise non plus (vers 70-80% il me semble).

    







Citation de: Daru13 le 10 Janvier 2011 à 01:26
Pour l'histoire de la mémoire virtuelle/résidente, je n'ai aucun partition swap de "prédéfinie" façon Ubuntu si c'est ce que tu voulais dire (en même temps est-ce possible avec Windows ?).

Maintenant je ne sais pas si Vista va piocher sur la partition système quand il en a besoin, il me semble que oui...
Windows utilise quand même de la mémoire virtuelle, même si ils n'ont pas jugé bon de faire une partition séparée. C'est un fichier caché c:\pagefile.sys si je me souviens bien.
Citation
Ash Nazg Durbatulùk, Ash Nazg Gimbatul,
Ash Nazg Thrakatulùk agh bruzum-ishi krimpatul.
The fellowship of the Ring - J.R.R. Tolkien

Je sait que les fuite de mémoire sont corrigé sur le smp. Je fait moi meme tourner un serveur hMod avec quelque plugins avec 400 mo max alloué et jamais je n'ai eu de probleme. 4 personne sur le serveur la consomation monte a 250 environ.

Chez moi minecraft connsome environ 200 mo sur 1go alloué

Et j'ai un Vista avec 3 go de ram

Autoriser un client Java à choper plus d'un Go de RAM, dans les paramètres jvm, c'est chaud quand même  :linkXD:

Et juste en complément, pour l'avoir un peu tripatouiller, utiliser Java3D sur ce genre d'applications ne me semble pas la meilleure des idées, surtout si le graphe d'objets est mal géré.. ça explose vite ces petites choses.

En complément (bis) sur le choix du langage d'un nouveau projet dont les specs sont prêtes, y a un point dont (sauf erreur) personne n'a parlé : le parc d'appli du SI de l'entreprise (ça équivaut aussi un peu au final aux compétences des dév' qu interviennent sur le SI,; je l'accorde). Dans un SI full .Net y a peu de chances que Java soit choisi par exemple. Ne serait-ce que pour des questions d'inter-opérabilité qui se règlent bien plus vite et d'éventuelles réutilisation de composants.

Java, c'est le must pour les technologies embarquées :ninja:

oj> Minecraft utilise lwjgl, pas Java 3d.

Citation de: 19oj19 le 16 Janvier 2011 à 10:09
Autoriser un client Java à choper plus d'un Go de RAM, dans les paramètres jvm, c'est chaud quand même  :linkXD:
Si tu parle de mon cas et bien c'est le launcher de minecraft qui réserve tout un go. Disont que j'ai un launcher (exe) un peu spécial qui me permet de jouer meme si une certaine condition n'est pas remplie. Haeummm bref passon.

Et puis vu que j'ai de la ram plus qu'il n'en faut, je me suis fait un ramdrive de 1 go et je fou le smp et minecraft dessu quand je veut jouer. Sa aide quand ton disque dur est pas yabe.

CitationSa aide quand ton disque dur est pas yabe.

Hein?...Je veux dire...hein?

Bon sinon, tu aurais pu faire encore moins subtil pour dire que tu as un launcher qui te permet de jouer à Minecraft sans l'avoir acheté :rolleyes:

Ce que je veut dire c'est que mon disque dur fait un vacarme quand il lit/écrit et il est pluto lent. Et de deux sitot que j'ai la possibilité de l'acheter je l'achete, et puis moi et la subtilité sa fait 10. donc la prochaine fois je vais me la fermer, ou me pendre :ninja:

Citation de: Morwenn le 16 Janvier 2011 à 13:01
Java, c'est le must pour les technologies embarquées :ninja:
Tu sais qu'il existe des processeurs capables de lire du bytecode Java nativement (quelques exemples:P

Citation de: Guillaume le 16 Janvier 2011 à 18:55
oj> Minecraft utilise lwjgl, pas Java 3d.
Quand j'ai vu les 2 premières initiales, j'étais déjà mort de rire "LightWeight" ^^
Cela dit, ça pourrait être intéressant comme lib ...
Mais si j'ai bien compris, cette lib est plus un ensemble de bindings style OpenGL/AL qu'une véritable API Java.
Citation de: Games Creators NetworkLWJGL est une bibliothèque pour Java permettant de développer des jeux 2D ou 3D bénéficiant de l'accélération matérielle. Elle est très simple d'utilisation et n'utilise pas (ou très peu) de notions orientées objet. Et pour cause : il s'agit d'un OpenGL binder (ou wrapper).
Ca rejoint ce que je disais au tout début du débat : on peut effectivement coder des choses performantes en Java, mais bien souvent à la condition de rompre avec les habitudes Java ...  :(

Ca m'a justement rappelé deux arguments que l'on m'opposait pour la lenteur de Java :
- Exceptions partout par convention (lourd à l'exécution)
- Résolution dynamique des liens imposée pour les méthodes (toutes les méthodes sont virtuelles selon la terminologie C++)

De quoi relancer le débat, je suis impatient de voir la vision des programmeurs Java :)
BenO, Chris, 19oj19 ^^ ? Et Guillaume aussi, toi qui connait un paquet de langages, t'en pense quoi ^^ ?
Marre des pavés ? Marchez dans la boue!
ハハ、あなたは私の罠に落ちた!

On m'appelle ? Les exceptions sont bien plus efficaces à l'éxécution que de faire des tests à la main en permanence sur des codes d'erreur de retour des fonctions.
Pour la liaison dynamique des fonctions, oui ça ralentit le programme puisque ça ajoute potentiellement un niveau d'indirection à chaque appel de fonctions. "Potentiellement" car si tu codes correctement, tu déclares final les méthodes qui ne peuvent pas être redéfinies. En C++, c'est les méthodes non-final qu'on doit déclarer avec un mot-clé (virtual). Ce qui revient finalement au même.
Cela dit, C++ propose d'autres moyens que la liaison dynamique pour résoudre les mêmes problèmes encore plus efficacement (éviter le niveau d'indirection), comme les templates. Je vous cite un paragraphe qui l'explique mieux que moi :
Citation
Since Java has nothing similar to templates, it must use dynamic binding for all this stuff, and dynamic binding of necessity means a function call. Normally not a big deal, but in C++ we want to enable extremely high performance code. That is, C++ has a "pay for it only if you use it" philosophy, which means the language must never arbitrarily impose any overhead over what the physical machine is capable of performing (of course a programmer may, optionally, use techniques such as dynamic binding that will, in general, impose some overhead in exchange for flexibility or some other "ility", but it's up to the designer and programmer to decide whether they want the benefits (and costs) of such constructs).
Ce paragraphe est tiré de la FAQ C++ Lite que je recommande fortement à la lecture ^^

Si Java est relativement lent c'est parce que c'est un langage qui n'est que partiellement compilé. Même si la JVM est capable de trouver certaines optimisations spécifiques à l'exécution, un programme java correctement codé reste nettement plus lent qu'un programme C++ correctement codé.
Bref, si la vitesse d'exécution est le critère important dans un projet, il est clair que java n'est pas à recommander. Mais reconnaissons que c'est peu souvent le critère fondamental. Notch a dû estimer que ce n'était pas le critère le plus essentiel dans Minecraft, et je suis d'accord avec lui Comme tout est cubique et pixellisé, ce n'est pas un jeu qui demande autant que la plupart des jeux en 3D actuels et il peut parfaitement tourner en Java. Bien sûr, à condition d'utiliser une bibliothèque digne de ce nom et surtout pas cette horreur de java3d.

A titre personnel maintenant, j'aime bien Java, mais moins qu'avant. Il y a des petites choses qui me gênent comme la lourdeur d'écriture pour faire des choses simples. Comme lire dans un fichier : BufferedReader reader = new BufferedReader(new InputStreamReader(new FileReader(new File(...)))) (ok, je caricature). Ou comme la gestion assez catastrophique des types primitifs et celle de la généricité.
Chaîne Twitch : diffusion en direct de sessions de développement de Solarus, de création de jeux, de parties de jeux vidéo.
Chaîne YouTube : replays des diffusions en direct, tutos Solarus
Compte Twitter : pour être au courant des nouveautés
Chat Discord : pour discuter en direct avec la communauté Solarus

Faites du Php5 ou du Jquery :ninja:

Je rejoins Chris sur le mécanisme d'exceptions, c'est quand même très efficace pour la gestion d'erreurs et épargne beaucoup de tests inutiles qui pour le coup ralentissent vraiment le temps d'exécution.  Sans parler de la hiérarchie de classes des Exceptions qui permettent un traitement très fin de celles-ci, avec la possibilité future de catcher plusieurs types d'exeptions d'un coup.. non non, c'est vraiment très bien pensé^^

Bon, par contre, la déclaration final des méthodes non redéfinissables, j'avoue ne jamais le faire, au même titre que les classes qui ne doivent pas être héritées d'ailleurs. Pour les titres primitifs, c'est nettement moins pénible depuis Java 5 avec l'auto(un)boxing qui convertit tout seul dans le type objet associé

Pour la gestion des types génériques "catastrophiques", j'veux bien que tu développes Chris parce que je te suis pas spécialement sur ce point^^

Pour finir Wouf, quand tu dis "coder des choses performantes, faut s'éloigner de Java", je suis qu'à moitié d'accord. Y a des problématiques particulières sur lesquelles, je suis totalement d'accord, un langage semi-compilé est peu adapté, mais y a tout un tas de cas où les différences sont nettement moins grandes et où l'essentiel des performances est ailleurs (temps réseau et accès BDD, pour ne citer que les plus  courants). C'est pas 4-5 instructions sur un résultat sortis d'une BDD qui coûtent en temps^^

Typiquement, la gestion de graphe d'objets 3D un tant soit peu complexes (et mes petites terrasses en bois c'est de la gnognotte hein) est la dernière chose à faire en Java pur (même si derrière t'utilises forcément OpenGL ou assimilés)

J'ai mis le mot "catastrophique" car j'ai du mal à m'empêcher d'être provoquant, je voulais créer une réaction ^^. Les types génériques en Java sont bidons car ils ne sont qu'une surcouche permettant uniquement de simplifier l'écriture du code (et d'éviter des cast pour récupérer le contenu d'un Vector par exemple). Mais en interne, un Vector<truc> est toujours stocké avec des Object, la seule chose que fait la généricité, c'est faire le cast automatiquement. Cela évite des erreurs à l'exécution puisqu'elles peuvent être détectées à la compilation. Donc c'est mieux qu'avant Java 1.5 où on n'avait même pas ça.
En C++, la généricité (aussi appelée classes templates) génère une classe *différente* pour chaque type donné en paramètre dans l'ensemble du programme. La classe list<int> et la classe list<TaClasse*> sont deux classes différentes au moment de l'exécution (d'où le nom de "template"), ce qui permet au compilateur d'effectuer des optimisations spécifiques dans chacune.
En Java, non : la généricité n'est que du sucre syntaxique, y'a rien en-dessous. Et en plus, lorsqu'on utilise des types primitifs, ils sont boxed/unboxed dans les classes enveloppes Integer, Character, etc... ce qui crée des nouvelles instances à chaque fois, bref c'est catastrophique pour les performances si les performances sont cruciales.
Mais encore une fois, comme le dit 19oj19, si les performances ne sont pas le goulot d'étranglement de votre application, il n'y a pas de problèmes à utiliser un langage qui n'est plus le plus rapide du monde.
Chaîne Twitch : diffusion en direct de sessions de développement de Solarus, de création de jeux, de parties de jeux vidéo.
Chaîne YouTube : replays des diffusions en direct, tutos Solarus
Compte Twitter : pour être au courant des nouveautés
Chat Discord : pour discuter en direct avec la communauté Solarus

19 Janvier 2011 à 07:53 #40 Dernière édition: 19 Janvier 2011 à 08:39 par BenObiWan
Citation de: Christopho le 18 Janvier 2011 à 23:59
Et en plus, lorsqu'on utilise des types primitifs, ils sont boxed/unboxed dans les classes enveloppes Integer, Character, etc... ce qui crée des nouvelles instances à chaque fois, bref c'est catastrophique pour les performances si les performances sont cruciales.
Pas tout à fait. Il n'existe dans tout le programme qu'un seul objet Integer de chaque valeur. Bref les Boolean ne coûtent presque rien (2 objets), et les autres ça dépend de l'amplitude des variables que l'on utilise. En fait je ne suis pas si sur qu'en interne à la JVM cela coûte tant que ça : la classe Integer tu la charges une fois et après il a une instance par valeur, doit y avoir une table de hash static ou autre structure du genre pour avoir l'objet associé à chaque valeur, mais un objet Integer à part un champ int value je pense qu'il ne contient pas grand chose (à la réflexion il y a le moniteur que contient Object). Donc coté chargement/déchargement il n'y a pas tant d'opérations que ça. Coté boxing/unboxing je pense qu'ils l'ont bien optimisé dans la JVM ou alors ce sont des boulets. Le truc très chiant c'est qu'il n'y a pas d'opérateurs sur ces objets (vu que contrairement à C++ ou python on ne peut pas redéfinir les opérateurs) et donc la syntaxe est lourde (si on active les warnings sur le boxing/unboxing :P)

Du coté de la généricité, déjà c'est un grand pas en avant (omg comment c'était chiant d'utiliser le collection framework en java 1.4). Concernant ta comparaison avec C++, de toute façon java c'est de l'interprété, je pense pas qu'ils puissent faire bien mieux que ce qu'ils ont fait au niveau compilation (ils ne vont pas générer un .class pour chaque cas possible...)

EDIT : la douche réveillant, j'ai des trucs à corriger sur ce que j'ai dit sur les types primitifs :P
Donc si on y réfléchi, le choix qu'ils ont fait de créer un seul objet pour chaque valeur de type primitif, c'est bien dans certains cas et naze dans d'autres. Déjà le moniteur il ne sert à rien, puisque que prendre le lock sur un Boolean qui vaut "true" c'est prendre le lock sur tous les Boolean qui valent true. Pire, si on prend le lock pour changer la valeur, vu que cela change la référence de l'objet dès que l'on change la valeur on n'a plus le lock sur ce que l'on veut. (C'est comme ça que j'ai découvert qu'il n'y avait qu'un seul Integer en mémoire qui valait 1 :P) Donc oui le moniteur ne sert à rien à part à produire du code non thread safe en croyant le faire.
Là où ça peut se poser un problème de perf c'est que dès que l'on fait une opération sur un objet englobant d'un primitif ça génère de nouveaux objets.
Prenons un int/Integer, je vois trois gros cas d'utilisation :

  • Si c'est pour servir comme clé dans une collection et ne pas faire d'opérations arithmétique dessus, utiliser Integer c'est bien.
  • Si c'est pour faire des calculs ou un compteur, utiliser int c'est bien.
  • Si c'est comme valeur d'une collection, c'est la merde. Par exemple compter les mots d'un texte et les stocker dans une HashMap<String,Integer> : on passe son temps à faire ++ sur un Integer ce qui génère un nouvel objet, enfin pas exactement puisqu'il va réutiliser les valeurs 2 3 etc... qu'il a utilisé pour les autres mots. Bref potentiellement c'est la merde dans certains cas. Il faudrait faire des benchs pour tester.

EDIT2: Et pour ceux qui se demandent pourquoi ils ont fait ça comme ça, c'est simple, Thead-safety : avec cette méthode un objet Integer contient un champ value final, et donc est thread-safe. Avec un objet Integer ayant un champs value qui peut changer, il faudrait rajouter des synchronized sur chaque opération ce qui est coûteux en perf. Bref à mon avis ils ont fait les tests et ils ont décidé que vu les cas d'utilisations et que de toute façon c'est le GC qui se chargera de libérer les objets inutiles et non le programmeur, c'était le meilleur choix à faire.
Citation
Ash Nazg Durbatulùk, Ash Nazg Gimbatul,
Ash Nazg Thrakatulùk agh bruzum-ishi krimpatul.
The fellowship of the Ring - J.R.R. Tolkien

20 Janvier 2011 à 14:09 #41 Dernière édition: 20 Janvier 2011 à 14:12 par Wouf
Wahouw, j'ai appris plein de trucs  :)

Alors tout d'abord, les exceptions :
Je savais qu'elles offraient plus de modularité et une manière plus élégante de traiter les erreurs (quoique parfois c'est lourd quand on doit les imbriquer parce que 2 méthodes instancient la même classe d'exception), mais je ne savais pas qu'elles étaient plus performantes que les tests classiques  :o
J'avoue que je suis perplexe, je suis en train de me renseigner ... Apparemment, au fil des améliorations, elles n'impacteraient presque plus sur les performances. Par ailleurs, cela dépendrait fortement de l'implémentation du compilo puisqu'il n'y a pas vraiment de norme (certains allant même jusqu'à ne fournir aucune garantie). Mais je n'ai pas encore fini ma recherche ^^  (J'ai trouvé ça ici)
A l'époque où je n'avais encore jamais entendu parler de programmation concurrente, je m'amusais à simuler certains aspects des exceptions avec une variable globale style errno, mais personnalisée  :P

Ensuite, la résolution dynamique des liens pour les méthodes :
Je n'avais jamais réalisé que méthodes stérilisée et virtuelle était mutuellement exclusives x3
Alors revient la question complexe du "comment savoir qu'un(e) objet/méthode ne pourra pas être réutilisé(e)". Dans une lib, c'est assez limpide, mais pour un moteur ... Dur ! Mais ça, c'est une autre histoire qui sort du sujet ^^
Message reçu, FAQ C++ Lite ajoutée à mes favoris  ;)

La généricité et/ou templates :
Je ne connaissais pas leur différence entre Java et C++, à savoir le sucre syntaxique ou la production de classes distinctes. Je n'ai jamais manipulé de templates et je savais juste que c'était un moyen élégant pour faire une sorte de polymorphisme vérifié à la compilation. En classe de POO (Java), on s'en tenait aux casts pour les collections :P
Un peu comme en C avec les pointeurs void ^^

Pour la comparaison des performances entre machine virtuelle et compilé en natif :
Je suis d'accord ! Ca ne se compare pas à partir du moment où on les utilise dans des domaines qui leur conviennent. Pour Minecraft, c'est clair qu'on s'en fiche plus que pour Zelda TP x3
Puis, une appli sur machine virtuelle est plus sécurisée qu'un processus natif (garde fou entre OS/appli), ce qui me semble intéressant pour une appli réseau/MMO. Un autre raison qui a mené à la conception du Java, si je ne me trompe ^^
Je le dis et je le redis donc : je ne critique pas le Java parce qu'il est à VM ! En revanche, l'implémentation de celle-ci, c'est autre chose  :ninja:

Pour la lourdeur d'écriture et l'impossibilité de surcharger les opérateurs :
On est d'accord, rien que System.out.println("Il vous reste " + lifes + " vies !") ; m'embêtait déjà  :mrgreen:
Et l'imposibilité d'importer un package sous un autre nom aussi (alias). Si on a besoin de 2 libs avec des méthodes communes au sein du même fichier, c'est la galère du nom à ralonge. Srtt avec la convention anti-collision de nom NomEntreprise.secteur.equipe.projet.package (que je plussoie à 100% si et seulement si on a des alias de packages).

Et enfin, les types primitifs :
Alors là, je suis tombé sur le rembourage  :blink:
Je ne savais pas du tout qu'ils étaient implémentés par des objets et qu'il fallait effectuer l'emballage/déballage entre int/Integer en permanence !!
Je croyais que les classes Integer et compagnie étaient apparues pour combler le manque de pointeurs comme en C/C++. C'était pour moi une façon de passer, par exemple, un entier par adresse, un peu lourd, certes.
Ce que dit BenO sur l'implémentation "une instance par valeur, avec membre constant" me laisse aussi sans voix  :o
En revanche, j'avoue que je ne te suis pas trop sur les blocages des moniteurs (hérités de la classe Object?!). En effet, si chaque valeur est une instance différente, on peut dire que modifier la valeur d'une variable primitive revient à faire pointer la référence cachée vers une autre instance. Logique puisque les champs des instances sont constants (final). De là, je ne vois pas l'intérêt de locker l'instance puisqu'elle est en lecture seule. Ce qu'on bloque, c'est la référence vers l'instance. Et donc le problème reste exactement le même, qu'on utilise des types primitifs emballés dans des instances ou des valeurs classiques comme en C. Donc soit j'ai mal compris, soit le problème est ailleurs  ^_^

Citation de: BenObiWan le 19 Janvier 2011 à 07:53

  • Si c'est pour faire des calculs ou un compteur, utiliser int c'est bien.
  • Si c'est comme valeur d'une collection, c'est la merde. Par exemple compter les mots d'un texte et les stocker dans une HashMap<String,Integer> : on passe son temps à faire ++ sur un Integer ce qui génère un nouvel objet, enfin pas exactement puisqu'il va réutiliser les valeurs 2 3 etc... qu'il a utilisé pour les autres mots. Bref potentiellement c'est la merde dans certains cas. Il faudrait faire des benchs pour tester.
Heu, je veux pas charrier, mais c'est exactement pareil entier ou table d'entier : en modifiant souvent la valeur de ta variable, tu t'exposes à la création éventuelle de nouvelles instances (valeurs non encore attribuées au programme)  :P
Perso, je me demande si ce ne serait pas encore plus simple de préallouer toutes les instances en début de programme (une pour chaque valeur).
Et pourquoi ne pas faire ces fameuses instances en fonction de leur réprésentation binaire. Ainsi, 2^64 instances suffisent. En effet : bool, int, ... sont codés pareil, c'est l'interprêtation qui diffère et celle-ci peut être déduite par le type de la variable primitive Nan, je suis bête : le type primitif étant une sorte de référence, il n'y aura plus moyen de les distinguer si elles pointaient vers des instances d'une même classe x3


Bref, merci à tous pour cette mine d'information ;)
Marre des pavés ? Marchez dans la boue!
ハハ、あなたは私の罠に落ちた!

Citation de: Wouf le 20 Janvier 2011 à 14:09Pour la lourdeur d'écriture et l'impossibilité de surcharger les opérateurs :
On est d'accord, rien que System.out.println("Il vous reste " + lifes + " vies !") ; m'embêtait déjà  :mrgreen:
Et l'imposibilité d'importer un package sous un autre nom aussi (alias). Si on a besoin de 2 libs avec des méthodes communes au sein du même fichier, c'est la galère du nom à ralonge. Srtt avec la convention anti-collision de nom NomEntreprise.secteur.equipe.projet.package (que je plussoie à 100% si et seulement si on a des alias de packages).

Y a désormais un printf en Java depuis la 1.5 ^^ (Go go gadgeto javadoc)  Et puis bon, le sysout, c'est sympa mais techniquement on s'en sert pas vraiment, on va plutôt passer par des APIs de logging (Log4J, par exemple) qui seront plus intéressantes en termes de possiblités

Les imports de packages avec des noms à rallonge.. bof, ça gêne pas vraiment hein, les IDE  proposent de générer eux mêmes les impots (ctrl-shift-I dans Netbeans, ctrl-shift-O dans Eclipse). 

20 Janvier 2011 à 15:23 #43 Dernière édition: 20 Janvier 2011 à 15:30 par Wouf
Ah, je ne savais pas pour le printf Java. Bon à savoir ^^
Mais bon, il y a sûrement d'autres exemples.
Enfin, ça reste préférable à la notation parenthésée préfixe-only du scheme/lisp  :mrgreen:

Citation de: 19oj19 le 20 Janvier 2011 à 14:42
Les imports de packages avec des noms à rallonge.. bof, ça gêne pas vraiment hein, les IDE  proposent de générer eux mêmes les impots (ctrl-shift-I dans Netbeans, ctrl-shift-O dans Eclipse).  
Là, je me suis peut être mal exprimé  :P
Les packages, c'est génial pour contrer les collisions de nom ... Quand on s'en sert bien !
Ca te permet de définir plusieurs classes de même nom, sans risque de conflit.
Mais pour bien faire, il faut que les noms de package soient différents, sinon ça ne sert à rien.
Comme un des principes de Java est que tout programme puisse être utilisé par un autre, il faut trouver des noms internationnalement uniques. D'où le nom à ralonge (plus un nom est grand, plus la probabilité de collision décroit) style be.ac.ulg.oop.project2007.boigelot.vector, qui profite, en plus, du nom de l'entreprise ou du domaine (garanti unique par copyright).  :)
Maintenant, quand tu importes un package dans le fichier courant, tu casses cette unicité au sein de celui-ci. En général, ce n'est pas grave, car tu n'importes pas suffisemment de packages pour risquer une collision de nom au sein d'un seul fichier. Mais ... Ca peut arriver !!
Si 2 packages ont des classes de même nom, tu ne peux pas les importer tous les 2. Il te faut donc utiliser le nom à rallonge pour chaque appel à l'une de ces classes. Ce qui est bien plus lourd que l'importation en début de fichier.
C'est pour cette raison qu'on a inventé les alias de namespaces en C++ ou de modules en python. Tu peux te pemettre d'importer les packages sous un nom plus court puisque la probabilité de collision a fortement chuté (la collision ne concerne plus que le fichier courant)  ;)

De manière générale, il est plus prudent de ne jamais importer d'autres packages que ceux de ton framework de base. Ainsi, si tu utilises un autre package, ben tu peux le renommer par un diminutif style SDL. Pour chaque appel de classe, tu devras donc te retapper le préfixe, mais comme il est plus court, ce n'est pas trop grave. Le principal, c'est de garder l'unicité du nom de package original.
Malheureusement, en Java, ce n'est pas possible, contrairement à C++, Python, Lua, Go, ...

Peu de gens comprennent vraiment l'intérêt de cette fonctionnalité ou s'en foutent carrément (projet égocentrique). C'est manifestement le cas du namespace sf:: de la SFML écrite en C++ par Laurent Gomilla  :unsure:

Conclusion : en Java, faute d'avoir mieux, on utilise les noms à rallonge et on importe tout dans le fichier courant en croisant les doigts. Sinon on se prend la tête avec des mégas préfixes à chaque appel de classe :ninja:
Marre des pavés ? Marchez dans la boue!
ハハ、あなたは私の罠に落ちた!

20 Janvier 2011 à 15:44 #44 Dernière édition: 20 Janvier 2011 à 15:47 par 19oj19
Conceptuellement, c'est quand même  à chier si t'as des packages qui contiennent des classes avec le même nom dans une appli à toi. Le but du package est quand même d'organiser ton application en en séparant les fonctionnalités (couche métier, couche ihm, couche dao éventuellement...) et le nom d'une classe se doit d'être globalement explicite.  

Derrière bien sûr, tu peux avoir des collisions entre tes classes et celles de librairies/framework que tu serais suceptibles d'utiliser dans le cadre de ton projet.  Mais là encore, faut se poser la question du juste nommage de tes classes. Tu vas pas t'amuser à nommer une classe Driver dans un contexte JDBC par exemple.

Alors si tu vas jusqu'à avoir deux classes avec le même nom dans le "même" package (mais bon, qui fout des classes dans les mêmes packages que les librairies qu'il utilise, franchement ?)

Pour moi c'est une fausse problématique et j'ai jamais été confronté à des collisions de nom.. aaprès, si t'as des exemples dans lesquels ça t'est arrivé, je suis preneur^^

20 Janvier 2011 à 16:39 #45 Dernière édition: 20 Janvier 2011 à 16:44 par Wouf
Décidément  :P

Citation de: Wouf le 20 Janvier 2011 à 15:23
Comme un des principes de Java est que tout programme puisse être utilisé par un autre, il faut trouver des noms internationnalement uniques. D'où le nom à ralonge (plus un nom est grand, plus la probabilité de collision décroit) style be.ac.ulg.oop.project2007.boigelot.vector, qui profite, en plus, du nom de l'entreprise ou du domaine (garanti unique par copyright).  :)
C'est évident que tu ne vas pas toi-même nommer deux classes à l'identiques au sein d'un même package, ni définir de nouvelles classes de même nom au sein d'un autre package.
Il faut arrêter la vision égocentrique du "ce projet ne concerne que moi", en particulier pour des moteurs/librairies distribuées sur la toile.

Prenons un exemple concret :
Mr X crée une librairie qui joue des musiques MP3, il appelle son paquage com.kikooworld.mp3Music.X .
Celui-ci contient une classe Loader qui permet de charger un MP3.
Mr Y crée, quant à lui, une lib qui joue des sons MIDI. Il fait un paquage com.wargamer.midiDouze.Y .
Celui-ci contient aussi une classe Loader, celle-ci permettant de charger des morceaux MIDI.

Toi, tu veux créer un moteur audio qui joue à la fois des musiques MP3 et MIDI.
Pour celà, tu comptes créer une classe qui charge indifféremment les deux types de fichiers grâce aux Loaders respectifs (reconnaissance d'après l'extension par exemple).
Donc tu crées ton fichier et tu fais
import com.kikooworld.mp3Music.X.Loader ;
import com.wargamer.midiDouze.Y.Loader ;

Ah merde  :paf:

Du coup, obligé de tapper tout le package quand tu utilises la classe Loader :
com.kikooworld.mp3Music.X.Loader mp3Loader = new com.kikooworld.mp3Music.X.Loader(file1) ;
com.wargamer.midiDouze.Y.Loader mdiLoader = new com.wargamer.midiDouze.Y.Loader(file2) ;

et ainsi de suite ...

Ce qui aurait donné avec alias :
import com.kikooworld.mp3Music.X as mp3;
import com.wargamer.midiDouze.Y as mdi ;

// ...

mdi.Loader mdiLoader = new mdi.Loader(file1) ;
mp3.Loader mp3Loader = new mp3.Loader(file2) ;


C'est mieux comme ça ?  :)


EDIT : Normalement tu es bloqué parce que tu n'as aucun contrôle sur le nom des libs extérieures. Si celles-ci sont open-source, tu peux t'amuser à les renommer (merci la fonction remplacer d'Eclipse ^^). D'autre part, pour les projets fermés, il existe des outils qui permettent de changer les noms au sein des binaires (en C du moins).
Mais c'est un peu con de dédoubler une lib à cause de ça ^^
En effet, si 3 programmes ont besoin de la même lib et font pareil sous des noms différents. Ben faudra installer les 3 libs alors qu'une aurait suffit.
Marre des pavés ? Marchez dans la boue!
ハハ、あなたは私の罠に落ちた!

Dans ton exemple, les mecs qui ont pondu ces librairies sont des tocards, puisqu'effectivement ils ont nommé ces classes de façon nombriliste (mais je crois que là dessus on est d'accord :mrgreen: )

Au pire, tu contournes le problème subtilement en faisant dans ton coin une classe MP3Loader et MIDILoader qui héritent chacune du bon loader et sont appelées par ton appli avec d'éventuels bonus pour ta gestion. C'est pas super joli si tu fais juste un bête héritage mais bon,  tu peux difficilement faire autrement dans ce genre de cas à défaut d'alias

20 Janvier 2011 à 17:40 #47 Dernière édition: 20 Janvier 2011 à 17:44 par Wouf
Meuh non, ils ont bien nommé leurs libs au contraire ^^
Leurs noms de domaine kikooworld.com et wargamer.com sont uniques (j'ai choisi ces noms-là par manque d'inspiration x3), donc ça devrait suffire.
Le problème ne vient pas d'eux, mais d'un manque du langage ... qui pourrait être aisément comblé à la compilation :ninja:.

J'aime bien ta solution :)
Mais ... Elle a plein de désavantages : surchouche, contraignant, perfs, ...
Sans compter que le gars a peut être fait son nombriliste en stérilisant ses classes (final) pour plus de perfs x3 Conclusion, je préfère encore me tapper les noms à rallonge  :ninja:

Mais rien ne t'empêche de faire ton propre script qui parserait le code et ferait la substitution des alias avant chaque compilation  :)
(Y aurait pas un plug-in qui fait ça, des fois ?)

En fait, l'avantage avec la communauté Java, c'est que le problème se règle facilement car ils adoptent la convention des noms à rallonge. En revanche, l'inverse est plus dur. T'as beau avoir des alias, tu ne pourras rien faire pour agrandir les noms de package des libs extérieures, comme sf::  :P
Enfin, je vais arrêter de critiquer cette lib puisqu'elle est censée faire office de framework pour les petits projets ^^
Marre des pavés ? Marchez dans la boue!
ハハ、あなたは私の罠に落ちた!

CitationMeuh non, ils ont bien nommé leurs libs au contraire ^^
Leurs noms de domaine kikooworld.com et wargamer.com sont uniques, donc ça devrait suffire.

Mais ça n'empêche pas de mettre un nom de classe explicite au lieu de mettre un Loader beaucoup trop générique. L'arborescence de packages unique ne justifie pas cette faute de conception à mes yeux.

CitationJ'aime bien ta solution :)
Mais ... Elle a plein de désavantages : surchouche, contraignant, perfs, ...
Sans compter que le gars a peut être fait son nombriliste en stérilisant ses classes (final) pour plus de perfs x3

Effectivement, on peut se faire ponwed si la classe est final u_u

Par contre, le surcouche n'est pas forcément une mauvaise chose, étant donné que ça nous permet de nous abstraire du Loader qu'on utilise. On peut ainsi avoir accès à une multitude de loaders plus ou moins dynamiquement sans qu'on le voit, fussent-ils originaires de librairies différentes. Bon, là ça dépend plus de tes besoins, je le reconnais, et les alias peuvent être une solution tout aussi valable.

Perso sur ce genre de choses, je ferai même une interface ILoader, et derrière des classes implémentant ça et étendant chacun des loaders externes. Possible que les perfs se prennent un peu de plomb dans l'aile (et encore, ce n'est ni plus ni moins que de l'encapsulation) et on a un chouette modèle objet dans notre appli^^

Ah, ok !
J'avais pas compris que c'était le Loader que tu critiquais ^^
Ben perso, je trouvais que c'était justement ça l'avantage des packages : se permettre des noms simples, sans risquer de collision de nom. J'ai toujours fait ainsi en tout cas, même si ce n'est pas un argument :P

Ouais, la surcouche oo, c'est cool !
Mais si on est déjà en train de faire une surcouche d'une surcouche, ça devient vite lourd  :ninja:

Bref, on est finalement d'accord ^^
Il n'empêche, je trouve que ça ne coûterait pas grand chose de rajouter les alias au langage. C'est comme en Vala, ça manque x3
Sauf que là, il est trop tard pour eux, n'ayant pas adopté la convention des noms à rallonge dès le début :mrgreen:
Marre des pavés ? Marchez dans la boue!
ハハ、あなたは私の罠に落ちた!