Articles précédents : Code
- [26] GFS à nouveau en GPL et résultats financiers de Red Hat
- [79] Linux VServer, pour ceux qui ne connaissent pas...
- [34] XFS inclus dans le noyau 2.4
- [48] Alsa-Project : Tout va très vite....
- [146] Tentative d'insertion d'une porte dérobée dans le noyau Linux
- [83] SCO enfonce le clou.
- [40] Relic Entertainment ouvre le code source de Homeworld
- [22] QTopia et bientot Opie sur le Yopy
- [20] Temps réel avec le noyau Linux
- [1] Concours de programmation - tous à vos claviers !
Liens connexes
- Java3D sur java.net (1078 hits)
- Le message sur la liste (250 hits)
- Looking Glass (817 hits)
- Les screenshots (1148 hits)
Dépêche modérée par
Pour mémoire, Java3D est une API de haut niveau permettant de profiter en Java de l'accélération matérielle des cartes 3D, en se plaçant notamment au dessus d'OpenGL ou de DirectX sous Windows.
Java3D permet aussi de réaliser des applications 3D portables d'un système à l'autre.
NdM : Nardiz nous apprend également : Après avoir ouvert le code de Java3D, Sun décide de mettre le desktop Looking Glass en GPL. Pour rappel, ce projet est un véritable desktop 3D initié par Kawahara, un développeur employé par Sun.
![[en]](../../../images/en.png)
Java3D sur java.net (1078 hits)-
Le message sur la liste (250 hits)
-
Looking Glass (817 hits)
-
Les screenshots (1148 hits)
> Lire la dépêche (154 commentaires, moyenne: 1,9).
- j3d-core : le noyau de Java3D qui contient entre autre le wrapper OpenGL/DirectX (javax.media.j3d.*)
- j3d-core-utils : un ensemble "d'outils" pour Java3D (com.sun.j3d.*)
- vecmath : la bibliothèque de mathématiques vectorielles
- j3d-examples : les exemples
j3d-code et vecmath sont distribués sous la Java Distribution License et la Java Research License de Sun. Les packages j3d-core-utils et j3d-examples sont pour leur part distribués sous une licence BSD.
Excellent
Voici une excellente occasion d'avoir un Java 3D au poil sur Linux et FreeBSD ; et même de tester gjc et de le compiler en natif pour plus de performance.
Par ailleurs, notez qu'il pourra ainsi figurer dans la section main de Debian, une première le Java de Sun.
Mais heu... c'est utilisé ? ;-) Je veux dire, ils ne le font pas parce que Java 3D est peu utilisé, qu'il a peu de valeur stratégique et qu'ils comptent sur le modèle communautaire pour pousser à son utilisation ?
Groar !
-
[^]Re: Excellent
Posté par nardzir () le 28/06/2004 à 17:41. (lien). Évalué à 11.le compiler en natif pour plus de performance.
Le mythe sur les performances de java ont la vie dur ;)
http://www.osnews.com/story.php?news_id=7372(...)
Je ne pense pas que le gain soit reelement important.
Mais heu... c'est utilisé ? ;-) Je veux dire, ils ne le font pas parce que Java 3D est peu utilisé, qu'il a peu de valeur stratégique et qu'ils comptent sur le modèle communautaire pour pousser à son utilisation ?
Le vrai probleme est que les developpeurs ont tendance a associer le mot lenteur a Java. Des applications 3D necessitent beaucoup de ressources par definition et il parait a priori naturel que Java ne soit pas le bon choix. Donc tout le monde se tourne vers le C/C++ et la communauté Java faisant de la 3D est par consequent tres reduite. C'est bien dommage. D'autant plus que Java3D est tres interessant car d'un niveau beaucoup plus haut qu'un simple bindings OpenGL.
La liberation des sources va certainement permettre de mettre au gout du jour ce moteur 3D avec l'ajout de fonctionnalité lui faisant cruellement défaut.-
[^]Re: Excellent
Posté par Baptiste SIMON (Jabber id, page perso, ) le 28/06/2004 à 18:32. (lien). Évalué à 8.Je ne pense pas que le gain soit reelement important.
alors si mm compilé Java est aussi lent, je comprends qu'on ne l'utilise que pour son haut niveau d'abstraction !
nb: pour ceux qui n'auraient pas compris, c juste que ca me lourde ce troll sur java-lent java-rapide... dès qu'on parle java, il suffit que l'aspect rapidité soit évoqué discretement qqpart pour que cette polémique absolument inutile ne refasse surface... et c pire encore qd on parle de gcj.
ok je -->[]... retourne à mes occupations.--
BeTa-
[^]Re: Excellent
Posté par nardzir () le 28/06/2004 à 19:17. (lien). Évalué à 3.Je n'ai pas voulu relancer le troll, j'ai juste voulu expliquer en quoi le mythe sur la lenteur de Java est responsable du peu d'engoument enver Java3D.
alors si mm compilé Java est aussi lent
Je n'ai pas dit ca, c'est juste que les machines virtuelles actuelles sont capables d'effectuer les memes optimisations que les compilateurs. Ce qui explique qu'au final il n'y a pas tant de difference. Ceci n'est valide que pour la derniere version ainsi que sous Windows, car sous Linux la JVM reste encore lente.-
[^]Re: Excellent
Posté par Aurélien Girard () le 29/06/2004 à 09:10. (lien). Évalué à 4.En tout cas les applications interactives en Java sont abominablement lentes.
Le temps de chargement est délirant, la réactivité poussive même sur les machines extrêmement puissantes d'aujourd'hui. Et je ne parle pas de le consommation totalement surréaliste de RAM.
Java c'est certainnement formidable coté serveur, mais coté client c'est la pire des abominations.-
[^]Re: Excellent
Posté par ndesmoul () le 29/06/2004 à 09:23. (lien). Évalué à 4.Sur les dernières JVM j'ai trouvé que le temps de chargement c'était amélioré, surtout sous Windows. Sous Linux c'est pas encore ça. La réactivité poussive (je pense que tu parles de l'aspect graphique) c'est grandement amélioré. Encore une fois sous Linux c'est pas encore ça, mais ça s'améliore.
Actuellement chaque appli java lancée charge en mémoire toutes les classes dont elle a besoin, même si une autre application les utilise déjà, d'où surconsommation de mémoire pour un langage déjà gourmant. Le jour où les JVM seront capables de faire partager ces ressources, ça sera une belle avancée: temps de chargement plus court, moins de mémoire consommée... Ce genre de fonctionnalité est prévue, mais je sais pas pour quand.-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 29/06/2004 à 09:31. (lien). Évalué à 4.Le J2SE 1.5 implementera deja du partage de classes entre differentes JVM.
One of the more significant updates is the introduction of class data sharing in the HotSpot JVM. This technology not only shares read-only data between multiple running JVMs, but also improves startup time, as core JVM classes are pre-packed.
Voir http://java.sun.com/developer/technicalArticles/releases/j2se15/(...)
Donc c'est pour bientot ;-)--
Vache qui rit, à moitié dans son lit
-
-
[^]Pour information...
Posté par Roger Rabbit () le 29/06/2004 à 09:37. (lien). Évalué à 2.Sur ma machine ( laptop centrino 1.7 ) , une application
Swing de taille raisonnable ( ie : je ne parle pas de netbeans )
met moins de 2 seconde entre la ligne de commande et l'affichage.
Par comparaison mozilla met 9 sec au premier démarrage
puis 4 seconde apres.
Netbeans met 20 sec entre le démarrage et le moment
ou je peux éditer le projet en cours. Mais netbeans est
un monstre en terme de programme.
( Mon jre est de plus configuré en mode server qui ralentit
encore plus le chargement initial, en mode client l'application
swing de base s'affiche en moins de 2 sec )-
[^]Re: Pour information...
Posté par Moonz () le 30/06/2004 à 18:34. (lien). Évalué à 2.Parce que Mozilla c'est un exemple de poids plume ?
Compare Jext et Kate par exemple. Et pas seulement et terme de vitesse de lentement. Je ne pense pas que Jext en sorte gagnant... En tout cas à l'époque où je l'avais testé sur un Pentium 400 Mhz Jext était presque inutilisable...
-
-
[^]Re: Excellent
Posté par Ph Husson (page perso, ) le 29/06/2004 à 21:25. (lien). Évalué à 0.J'pensais ça comme tout le monde (et je le penses encore un peu)
et un jour j'ai testé un jeu java sous mac os 9 (ui bon c pas x mais bon voila quoi)
et la fluidité!!!
j'aurais dis que c'etait du java!! apres c'etait quelle VM je sais pas trop :(
mais bon c'est juste pour dire que c'est pas java qui est lent mais les vm :)
(c'est un imac 450mhz pour info)
-
-
-
-
[^]Re: Excellent
Posté par Bière Drabo () le 28/06/2004 à 18:35. (lien). Évalué à 1.Parce que ce n'est pas un mythe, et quelques benchmarks spécialement taillés pour Java n'y changeront rien. Il y a des cas où Java va plus vite, dans des domaines spécialisés, et alors ça vaut le coup de l'utiliser, mais ce n'est pas le cas des applications généralistes.
-
[+] [^]Re: Excellent
Posté par Jean-Marc Spaggiari (page perso, ) le 28/06/2004 à 19:09. (lien). Évalué à -4.Trop gros, passera pas...
Moi je dis, le C c'est de la merde, c'est trop lent. J'ai programmer un projet en assembleur, ben j'explosais toutes les personnes qui l'avait fait en C. C'est pour ca que linux est si lent...-
[^]Re: Excellent
Posté par Eric Boulat () le 28/06/2004 à 19:21. (lien). Évalué à 1.Moi je dis l'assembleur c'est pour les feignants ! Sous dos, je codais directement en code machine avec debug et mon code était plus petit et plus performant ;-)
-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 28/06/2004 à 19:26. (lien). Évalué à 7.je pense que le problème de performance est un peu "débile". Java n'est pas ni beaucoup plus rapide que C++, ni beaucoup moins rapide que C++.
L'important est de savoir avec quel langage vous pouvez développer le plus vite et le mieux.
Une journée d'un développeur coûte plus cher qu'une barrette de RAM-
[^]Re: Excellent
Posté par Tennis Prono (page perso, ) le 28/06/2004 à 19:45. (lien). Évalué à 5.Une journée d'un développeur coûte plus cher qu'une barrette de RAM
mais coûte moins cher que 10000 barettes de RAM.--
Pas de bureau 3d libre sans drivers libres!-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 28/06/2004 à 20:33. (lien). Évalué à 1.tu connais beaucoup de soft qui consomme 5 GO de RAM ?
Je développe des saisies déportées 100% Java ( Thinlet, Hibernate, hsqlDB ) et elles tournent sur de petites config. ca ne rame pas et c'est bien sur multi plateforme.-
[^]Re: Excellent
Posté par Brice Carpentier (Jabber id, page perso, ) le 28/06/2004 à 22:57. (lien). Évalué à 5.si tu considères le nombre de machines qui vont utiliser l'application, je pense que l'ont peut facilement dépasser les 5Go de ram :)
--
Développeur OpenSource
-
[^]Re: Excellent
Posté par duf (Jabber id, ) le 28/06/2004 à 23:05. (lien). Évalué à 6.Moi je connais weblogic, je teste souvent ce produit en métrologie, bah le nombre d'applets qui sont livrées avec des fuites mémoires... quand tu lances la console pour monitorer la JVM pour comprendre pourquoi ça rame et pourquoi tu as les ressources systèmes qui sont si élevées alors que pour le moment tu ne simules que 2 utilisateurs en même temps... c'est simple tu vois le garbage collector passer toutes les 10s, ça fait du temps cpu système en plus du temps user, ça te fait swapper alors tu as le wait IO qui monte qui monte, ça fait partir la mémoire en live, les performances sont pourries... enfin bon c'est pas java qui est en cause mais ceux qui l'utilisent. Mon avis complètement personnel c'est que java permet pleins de trucs bien trop facilement et les développeurs ne font plus attention à ce qu'ils font, limite ils codent comme des pieds et tous les mois on a droit à un lot d'aberration pas possible sur des applis qui coûtent des fortunes...
Faudrait trouver le moyen pour que java rende le codeur moins fainéant et plus attentif à ce qu'il code, mais bon, doux rêve....-
[^]Re: Excellent
Posté par snt () le 29/06/2004 à 06:48. (lien). Évalué à 3.J'ai fait tres peu de Java alors je connais pas trop. Tu peux juste donner un exemple de code produisant un memory leak ? Et le meme code corrigé ? ( c'est pour ma culture perso )
-
[^]Re: Excellent
Posté par snt () le 29/06/2004 à 07:00. (lien). Évalué à 7.Je me pré-réponds à moi meme :
http://www-106.ibm.com/developerworks/java/library/j-leaks/(...)
Que je viens de parcourir rapidement. Conclusion :
"le developpeur java n'a pas besoin de se soucier de la gestion de la memoire" me semble beaucoup moins evident maintenant.-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 29/06/2004 à 07:10. (lien). Évalué à 5.C'est le probleme de Java : il a l'air simple et la reputation de l'etre ... Hors il ne l'est pas. Programmer en Java c'est facile, bien programmer en Java c'est aussi difficile que de bien programmer en C, en PERL ou quoi que ce soit.
Bien sur il faut faire attention a la gestion de la memoire en Java. Il faut toujours assigner null a une reference lorsqu'on ne l'utilise plus.--
Vache qui rit, à moitié dans son lit-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 07:33. (lien). Évalué à 1.Je ne dis pas qu'il n'y a jamais de fuites de mémoire en Java mais à mon avis, c'est très rare !
et je ne pense pas qu'il faile mettre à null une reference quand tu ne l'utilises plus...-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 29/06/2004 à 07:42. (lien). Évalué à 6.C'est moins rare que ce que tu penses, surtout dans les applications J2EE ou tu peux avoir des hashmap qui cachent des objets qui eux meme ont encore peut etre des reference sur d'autres trucs ...
Mettre les references a null quand tu ne les utilises plus est un bon reflexe. Avec ca tu es sur que tu n'auras pas de mauvaise surprise, c'est une precaution. En plus, ca n'a aucun impact negatif.
De toute maniere, ce n'est pas Java qui est en cause, c'est le developpeur. C'est a lui de veiller a ne pas faire n'importe quoi avec la memoire.--
Vache qui rit, à moitié dans son lit-
[^]Re: Excellent
Posté par Frédéric Desmoulins (page perso, ) le 30/06/2004 à 10:06. (lien). Évalué à 3.Les WeakReference et WeakHashMap sont vos amis.
WeakHashMap: http://java.sun.com/j2se/1.4.2/docs/api/java/util/WeakHashMap.html(...)
WeakReference: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference(...)
Comment ca marche: http://java.sun.com/developer/technicalArticles/ALT/RefObj/index.ht(...)
-
-
[^]Re: Excellent
Posté par reno () le 29/06/2004 à 20:36. (lien). Évalué à 2.> Je ne dis pas qu'il n'y a jamais de fuites de mémoire en Java mais à mon avis, c'est très rare !
> et je ne pense pas qu'il faile mettre à null une reference quand tu ne l'utilises plus
Et tu fondes ton avis sur quoi?
Moi, cela parait me plus sage de mettre a null les reference que tu ne vas plus utilisée: autrement une fuite de mémoire causée par une arborescence de reference pointée par un objet a longue durée de vie (une objet d'une classe singleton par exemple) peut arriver vite..
Et la le GC ne peut pas désallouer un nombre important d'objet d'ou la fuite de mémoire..
Je pense que les 4 (5?, plus?) types de références (weak et autres) qui ont été introduites dans Java, ce n'est pas juste pour le plaisir!
Aussi la réputation (méritée à mon avis) que Java c'est hyper-gourmand en RAM, c'est en partie a cause de developpeurs qui gere mal leur mémoire : non mise a null des references inutiles, par exemples..
-
-
[^]Faux
Posté par Roger Rabbit () le 29/06/2004 à 08:46. (lien). Évalué à 6.Salut,
Je ne suis pas d'accord avec le fait de nuller une variable après usage.
C'est un mythe qui a la vie dure. Soi disant le fait de nuller une variable
facilite la suppression de l'objet par le garbage collector, c'est faux, et au pire
ca va entrainer une diminution des performances.
Il ne sert à rien de nuller une variable après usage sauf dans quelques cas
particuliers comme :
* utilisation de champs statiques ou privés pour stocker des données temporaires.
* utilisation de tableau pour stocker des objets de maniere temporaire.
A part dans le cas de données temporaires, la variable est de tout facon nullé en sortie de méthode. Si ce n'est pas le cas c'est que le scope de la variable est mauvais.
Pour ceux que ca interesse, plus d'infos la :
Java theory and practice: Garbage collection and performance
http://www-106.ibm.com/developerworks/library/j-jtp01274.html#resou(...)
et la
How you reference objects can seriously affect the garbage collector
http://www-106.ibm.com/developerworks/java/library/j-perf08273.html(...)-
[^]Re: Faux
Posté par Nelis (page perso, ) le 29/06/2004 à 08:59. (lien). Évalué à 2.Pour les variables locales, je suis d'accord ca ne sert a rien. Par contre pour certaines variables referencees dans plusieurs objets et de scope plus global, ca peut-etre utile.
Je ne termine pas toutes mes methodes par
myObj1 = null;
myObj2 = null;
...
mais dans certaines methodes de cleanup je fais bien attention a nettoyer les references.
C'est au developpeur a savoir ce qu'il fait (comme toujours)--
Vache qui rit, à moitié dans son lit
-
-
[^]Re: Excellent
Posté par Croconux () le 29/06/2004 à 15:17. (lien). Évalué à 2.Il faut toujours assigner null a une reference lorsqu'on ne l'utilise plus.
Du coup le garbage collector présenté comme la solution à tous les problèmes n'est plus qu'une béquille. En général il y a quelques sections de code où on n'est pas sûr du moment où on pourra se débarrasser d'un objet (est-ce qu'il y a encore un thread qui traine susceptible d'y toucher) mais on peut isoler des points où on sait qu'on peut liquider tout. Pour gérer ça pas besoin d'un garbage collector. Il suffit de gérer une relation parent-enfant. En créant un objet on désigne son parent. A partir de là le parent gère la durée des objets en question. Le destructeur du parent appelle un delete sur tous ses enfants. Quand on rentre dans une section multi thread chiante on alloue tous les objets créés de cette façon. Quand on en sort on peut libérer les parents et du coup on libère toute la merde accumulée.-
[^]Re: Excellent
Posté par Roger Rabbit () le 29/06/2004 à 16:03. (lien). Évalué à 2.non c'est faux pour le coup d'assigner des null,
cf mon post plus bas ...
-
[^]Re: Excellent
Posté par reno () le 29/06/2004 à 20:42. (lien). Évalué à 2.> le garbage collector présenté comme la solution à tous les problèmes n'est plus qu'une béquille.
Ah? Tu as vu ou que le GC résout tous les problemes?
Tu le sorts de ton chapeau?
Le GC ne s'occupe que de la mémoire pas des autres ressources donc il ne résoud évidemment pas tous les problemes..
>Il suffit de gérer une relation parent-enfant.
En ajoutant un compteur? C'est sûr que créer soi-même son propre GC, ça résoud le probleme!-
[^]Re: Excellent
Posté par Matthieu Moy (page perso, ) le 30/06/2004 à 07:24. (lien). Évalué à 2.> En ajoutant un compteur?
Même le compteur de référence, c'est pas absolu comme méthode. Tu crée un cycle et hop, une fuite de mémoire ...
-
-
-
[^]Re: Excellent
Posté par xsnipe () le 29/06/2004 à 15:45. (lien). Évalué à 1.N'étant pas expert java mais développant une petite appli avec ce langage, peux-tu me dire les réels apports (pas théoriques j'entends) de cette approche, je mets pas en doute mais j'aimerai savoir...
--
Debian ... gentoo moi ça et vite :)
-
-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 08:07. (lien). Évalué à 1.Oui, sauf qu'appeler ça un memory leak, c'est du foutage de gueulle intégral. Oui, si on conserve une référence sur un objet, celui-ci n'est pas détruit. Grande découverte qui signifie donc qu'il faut faire attention à ce qu'on fait. Le développeur Java doit donc gérer ses objets proprement, rien de bien extraordinaire. Par contre, il ne gère pas la mémoire...
-
[^]Re: Excellent
Posté par renoo () le 29/06/2004 à 09:37. (lien). Évalué à 5.Non c'est une vraie fuite de mémoire, tu conserves quelque chose dont tu n'auras plus jamais besoin. Où est concetuellement la différence avec un malloc sans free ?
-
[^]Re: Excellent
Posté par Vivi (page perso, ) le 29/06/2004 à 11:07. (lien). Évalué à 2.Où est concetuellement la différence avec un malloc sans free ?
la différence est que tu as perdu le pointeur vers la zone mémoire donc tu ne peux plus faire de free, l'information te permettant de libérer la mémoire est perdue.-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 29/06/2004 à 11:21. (lien). Évalué à 2.ca tombe bien parce qu'en Java tu ne peux pas faire de free. Par contre en perdant la reference, le GC sait qu'il peut nettoyer l'objet.
--
Vache qui rit, à moitié dans son lit
-
-
-
[^]Re: Excellent
Posté par reno () le 29/06/2004 à 20:47. (lien). Évalué à 1.Oui euh, la difference est un peu trop subtile pour moi sur le coup dans les deux cas la consommation mémoire est supérieure a ce qu'elle devrait être, donc il y a bien fuite mémoire que ce soit causé par une "mauvaise gestion de la mémoire" ou une "mauvaise gestion d'objet qui consomme de la mémoire", franchement c'est du pinaillage..
-
[^]Re: Excellent
Posté par Guillaume Knispel () le 29/06/2004 à 23:11. (lien). Évalué à 3.Bon pour fixer les idées je vais essayer de donner une définition de "memory leak"
Donc je dirais "une fuite de mémoire se produit lorsqu'un espace précédemment aloué qui n'est plus référencé est conservé en mémoire sans possibilité de libération future".
Si le programmeur Java garde une référence sur un objet, cela veut dire par définition même du langage qu'il souhaite utiliser l'objet dans le futur. Si il ne souhaite pas vraiment l'utiliser dans le futur mais qu'il garde quand même une ref, il est certes un bien mauvais programmeur mais on ne peut pas résonnablement qualifier ca de memory leak. Il ne faut quand meme pas s'attendre que la JVM fasse de la divination quand aux pensées du programmeur.-
[^]Re: Excellent
Posté par renoo () le 30/06/2004 à 07:22. (lien). Évalué à 2.Alors un pointeur perdu n'est pas une fuite mémoire car la zone est referencé à un niveau superieur celui du processus et sera récupérée plus tard. Ce niveau supérieur peut presque etre vu comme l'objet de durée de vie plus longue meme si le modèle est moins élegant.
-
-
-
-
-
-
-
[^]Re: Excellent
Posté par mdlh () le 29/06/2004 à 09:31. (lien). Évalué à 2.c'est bien sur multi plateforme.
Je remets pas en cause ton code. Mais le multi-platforme se limite aux plateformes ou l'on trouve une JVM.
Il existe bien des JVM "libres" et l'on n'a heureusement plus a attendre que SUN et autres daignent (quand ils le font) proposer une JVM pour l'archi que tu utilises.
Maintenant si je ne me trompent pas, tout n'est pas supporte par ces projets...
Donc la portabilite reste assez restreinte...-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 09:44. (lien). Évalué à 2.Bien entendu, il faut une JVM.. ca, c'est clair.
Ce que j'appelle multi plateforme :
Pouvoir développer un programme sur linux, windows ou OSX et que ce programme tourne sans aucun probleme sous linux, windows ou OSX.
C'est ce que j'appelle multi plateforme.-
[^]Re: Excellent
Posté par Pothin Alain (page perso, ) le 29/06/2004 à 17:13. (lien). Évalué à 0.Et pour avoir une jvm recente sous linux PPC (mac), tu fais comment si l'éditeur de la jvm n'a pas compilé pour ton architecture ?
La portabilité de java s'arrête là tant que qu'il n'y aura pas une véritable jvm (recente) open source.
En attendant tous les softs ecrit en C/C++/... open source compilent sans problemes sur mon mac PPC.
Linux existe sur toutes les plateformes. La portabilité aujoud'hui c'est peut-être linux?-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 20:19. (lien). Évalué à 2.TU prends une JVM libre...
Java est portable , pas la JVM. C'est évident que si tu n'as pas de JVM sur ta plateforme, un programme java ne tournera pas.
"En attendant tous les softs ecrit en C/C++/... open source compilent sans problemes sur mon mac PPC. "
Bien sur... C et C++ sont super portables :) pas de soucis.
"La portabilité aujoud'hui c'est peut-être linux?"
La portabilité, c'est pas ça pour moi, c'est etre capable de développer une application sur une plateforme et de l'utiliser sur n'importe quelle autre plateforme.
C'est pas développé sur une plateforme comme Linux et dire aux gens de migrer sous Linux.
-
-
-
-
-
-
[+] [^]Re: Excellent
Posté par Vivi (page perso, ) le 28/06/2004 à 19:58. (lien). Évalué à -2.Java n'est pas ni beaucoup plus rapide que C++, ni beaucoup moins rapide que C++.
Exact, c'est juste qu'il prend 4 fois plus de mémoire :)-
[+] [^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 28/06/2004 à 20:34. (lien). Évalué à -2.eheh commentaire gratuit sans justifications :)
-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 08:19. (lien). Évalué à 6.Peut être que la personne à laquelle tu réponds en a marre de justifier ce fait : Java bouffe une quantité de mémoire délirante. Les raisons sont connues :
1) tout objet contient un lock utilisé pour la gestion des synchronized. L'implémentation de Sun bouffe un mot (4 octets en 32 bits) par objet pour ce verrou (il existe des solutions alternatives, par exemple dans SableVM)
2) tout objet contient une référence vers sa classe pour que le typage dynamique fonctionne correctement (il s'agit du .class, en gros) => encore un mot
3) je n'ai pas lu les sources, mais je soupçonne la JVM de Sun de placer une référence vers la table des méthodes virtuelles dans chaque objet pour éviter la double indirection qu'on aurait si on passait par l'objet Class pour obtenir les adresses des méthodes en question => encore un mot
Sur une machine 32 bits, chaque objet contient donc 12 octets de gestion (au minimum), alors qu'en C++, on a en général seulement 4 octets de gestion (pour la table des méthodes virtuelles). Il y a en fait deux erreurs fondamentales de conception de la JVM :
- la gestion du parallèlisme au niveau de l'objet est loin d'être une panacée. Un système de verou externe ou un type spécial dont il faudrait hériter (dans l'esprit de Serializable) serait nettement plus adapté (cf à ce sujet les modifications qui seront intégrées dans la version 1.5, http://gee.cs.oswego.edu/dl/concurrency-interest/index.html(...))
- la manipulations des objets exclusivement par référence empêche de mettre en place des objets "lightweight" comme on en dispose en C++ (les objets sans méthodes virtuelles) et en C# (les structs). C'est d'ailleurs une source de plus de gaspillage de mémoire : si je veux un tableau de nombres complexes, j'obtiens en fait un tableau de références vers des nombres complexes, ce qui mange un mot de plus par objet, soit 16 octets sur une architecture 32 bits (contre 16 octets pour le contenu du nombre complexe !).
Bref, dire que ça consomme 4 fois plus est clairement exagéré, mais dire que ça consomme beaucoup plus est une réalité bien gênante pour Java (qui n'en reste pas moins un excellent langage).-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 08:23. (lien). Évalué à 4.Peut être que la personne à laquelle tu réponds en a marre de justifier ce fait
Quelqu'un qui balance comme ça que Java consomme 4 fois plus de mémoire aurait besoin de se justifier non ????
C'est la définition du FUD
Le fait que java consomme un peu plus de mémoire n'est certainement pas faux... D'un autre coté, je ne vois pas vraiment cela comme un problème.
Si à notre époque, cela était vraiment un problème, je développerai en Assembleur et je dirais sur toutes les news PHP, Java, C++, C, Ruby, ASP, VB... que c'est nul car ca consomme beaucoup de mémoire.-
[+] [^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 08:53. (lien). Évalué à -1.Le fait que java consomme un peu plus de mémoire n'est certainement pas faux... D'un autre coté, je ne vois pas vraiment cela comme un problème.
Si à notre époque, cela était vraiment un problème, je développerai en Assembleur et je dirais sur toutes les news PHP, Java, C++, C, Ruby, ASP, VB... que c'est nul car ca consomme beaucoup de mémoire.
Ne te fais pas plus bête que tu l'es. Je viens de te démontrer que Java consomme beaucoup plus de mémoire en gâchant des ressources (par exemple le verou qui est inutile pour de très nombreux objets). Le C++ n'a pas ce défaut, il permet une utilisation beaucoup plus raisonnée de la consommation mémoire. En Java, tu ne peux pas faire propre et efficace en mémoire dans certaines situations. Un exemple simple, une matrice de nombres complexes : en Java ça utilise 2 fois plus de mémoire qu'en C++ sans aucune raison valable.-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 09:37. (lien). Évalué à 3.Ne te fais pas plus bête que tu l'es
Ce genre de phrase ne sert à rien dans le débat, merci de les garder pour toi.
Je ne sais pas quel genre d'applis tu développes mais honnêtement, tes exemples ne me font meme pas poser la question de savoir si C++ est mieux...
une matrice de nombres complexes
Très bon exemple...
Au fait, tu préviendras les chercheurs du CERN ( Cenrte européen Recherche sur le nucléaire ) qui ont besoin de nombreux calculs, de puissance et de mémoire qu'ils se sont plantés :
http://hoschek.home.cern.ch/hoschek/colt/(...)
et ils en ont un paquet de projets comme ça, nottament leur data grid.-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 10:04. (lien). Évalué à 3.
Ce genre de phrase ne sert à rien dans le débat, merci de les garder pour toi.
Ouai, ouai. Tu crois que tu fais avancer le débat quand tu caricatures le propos de tes contradicteurs ?
Je ne sais pas quel genre d'applis tu développes mais honnêtement, tes exemples ne me font meme pas poser la question de savoir si C++ est mieux...
Je ne comprends pas. Je fais du calcul numérique pour des applications d'IA, et je me pose la question pour tous mes nouveaux développement: C, C++, C# ou Java ?
Très bon exemple...
Quel est le problème ? C'est très utile une matrice de nombres complexes. Tu préfères un exemple issus des jeux vidéos, genre le terrain d'un STR ?
Au fait, tu préviendras les chercheurs du CERN ( Cenrte européen Recherche sur le nucléaire ) qui ont besoin de nombreux calculs, de puissance et de mémoire qu'ils se sont plantés :
http://hoschek.home.cern.ch/hoschek/colt/(...(...))
et ils en ont un paquet de projets comme ça, nottament leur data grid.
Très joli argument d'autorité. Alors d'abord, je suis chercheur à l'INRIA (et oui), donc j'ai raison, n'est ce pas ? D'autre part, les chercheurs en physique ne savent pas programmer (c'est normal, ce n'est pas leur métier) et ont défendu pendant des années (ils le font encore) le fortran comme super solution pour le calcul numérique, alors que les compilateurs C modernes produisent du code au moins aussi performant que celui des compilateurs fortran. Enfin, je connais COLT, c'est une superbe bibliothèque, incroyablement performante pour un truc en 100 % java. Mais c'est 2 à 4 fois plus lent qu'Atlas (http://math-atlas.sourceforge.net/(...)), alors bon, franchement, ce n'est pas un très bon exemple.-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 10:11. (lien). Évalué à 2.je comprends mieux :) on bosse pas sur les mêmes applications et donc, on ne parle pas de la même chose :)
Quel est le problème ? C'est très utile une matrice de nombres complexes. Tu préfères un exemple issus des jeux vidéos, genre le terrain d'un STR ?
Non, une appli de gestion, un site web, un outil de reporting, une compta, un distributeur de billet, une CRM, une place de marché....
qui sont aussi des applications très utile.
Très joli argument d'autorité. Alors d'abord, je suis chercheur à l'INRIA (et oui), donc j'ai raison, n'est ce pas ?
Disons que je ne vais pas admettre que tu as raison à cause de cela :)
Je bosse justement avec des gens de l'INRIA sur jonas ( http://jonas.objectweb.org/(...) ), on aurait donc tort de faire des trucs en Java ???
http://jonas.objectweb.org/team.html(...) <- Tu verras les gens de l'INRIA sur cette page...
On a beaucoup de débats, mais aucun d'entre eux le débat sur le langage est déja passé de mode ;)-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 10:27. (lien). Évalué à 2.Non, une appli de gestion, un site web, un outil de reporting, une compta, un distributeur de billet, une CRM, une place de marché....
qui sont aussi des applications très utile.
Je n'ai aucun doute sur l'utilité, de même que je n'ai aucun doute sur le fait que Java pour ces outils gaspille de la mémoire, qui est effectivement une ressource peu coûteuse sur un serveur.
on aurait donc tort de faire des trucs en Java ???
Si tu relis bien mes commentaires, tu verras que je ne critique pas le choix de Java. J'ai enseigné Java pendant de longues années (depuis 1997) et je suis convaincu que c'est un des meilleurs langages disponibles actuellement. Mais ça ne m'empêche pas de constater qu'il a de gros défauts. Et je suis vert d'être obligé d'admettre que C# corrige un bon nombre de ces défauts...-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 10:30. (lien). Évalué à 3.Ok :) on tombe finalement d'accord. Je crois que notre plus gros désaccord provenait du fait qu'on ne parlait pas des mêmes choses en fait.
Je m'excuse pour avoir été un peu rude.-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 11:40. (lien). Évalué à 2.Je m'excuse pour avoir été un peu rude.
Tout pareil.
-
-
[^]Re: Excellent
Posté par Sylvestre Ledru (Jabber id, page perso, ) le 29/06/2004 à 10:39. (lien). Évalué à 2.Et je suis vert d'être obligé d'admettre que C# corrige un bon nombre de ces défauts...
Tu pense a quoi en particulier ?-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 11:40. (lien). Évalué à 2.Je pense aux structs qui permettent de faire des objets légers sans l'overhead mémoire dont je parle au dessus pour Java. Je pense aussi au modèle retenu pour les templates qui demande une nouvelle version de leur VM mais qui est beaucoup plus efficace au final que le truc un peu batard retenu pour Java 1.5. Je pense enfin au passage par référence qui évite de créer des petits objets idiots quand on veut renvoyer deux valeurs depuis une fonction. Je suis sûr que j'en oublie...
-
[^]Re: Excellent
Posté par Cook Captain () le 29/06/2004 à 23:10. (lien). Évalué à 2.Je pense aux structs qui permettent de faire des objets légers
Comme le struct (de c#) est un objet de type valeur, il est également possible de faire de grosses bétises trés facilement et de dégrader à l'insu de son plein gré ;-) les performances de son appli. (ie. assigner un struct à un autre struct, ce qui revient alors à dupliquer entièrement le struct). D'autre part, parler d'objet lighweight, pour le struct me semble un peut exagéré : pas de polymorphisme, pas d'héritage, etc. Leur utilisation sera alors généralement limité (hors appli spécifique) et le gain à attendre faible aussi bien en terme de conso mêmoire que de perfs. Bref, le struct présente des avantages mais également des inconvénients, et donc n'est malheureusement pas encore la panacée.
au modèle retenu pour les templates
Le modèle de template en c# est mieux foutu mais exige un changement de VM. C'est un choix... plutôt judiceux lorsque la base installée est faible... Mais en définitive, les limitations des templates Java impacte peu le développeur (uniquement dans la cas de la réflexion).
Je pense enfin au passage par référence qui évite de créer des petits objets idiots quand on veut renvoyer deux valeurs depuis une fonction
??-
[^]Re: Excellent
Posté par boubou (page perso, ) le 30/06/2004 à 06:24. (lien). Évalué à 2.Bref, le struct présente des avantages mais également des inconvénients, et donc n'est malheureusement pas encore la panacée.
Je ne dis pas le contraire, je déplore simplement l'impossibilité d'avoir ce genre d'objets (je revendique le lightweight qui correspond justement à l'absence d'héritage et de polymorphisme) en Java. Les exemples concrets ne manquent pas : comment représenter efficacement des nombres complexes en Java ? Comment représenter le terrain de jeu de stratégie temps réel ?
plutôt judiceux lorsque la base installée est faible... Mais en définitive, les limitations des templates Java impacte peu le développeur (uniquement dans la cas de la réflexion).
Ouai. Ca fait quand même des années que tout le monde demande des templates en Java et le JSR concerné était un des premiers (le 014 pour être précis). Donc l'histoire de la base installée ne tient pas trop la route. Sun ne semble toujours pas avoir compris que la JVM contient quelques erreurs de conception (ce qui est normal) et qu'il serait temps de faire des modifications incompatibles. De plus, si tu lis l'article qui présente la conception des génériques en C# (cf http://research.microsoft.com/projects/clrgen/(...)) tu verras qu'ils sont bien supérieurs à ceux de Java, en particulier en terme d'efficacité du code. Les problèmes d'instanciation vers les types natifs en Java font qu'utiliser une List pour contenir des doubles sera toujours totalement pourri, tant en terme d'occupation mémoire que de performance, à cause du (un)boxing.
Je pense enfin au passage par référence qui évite de créer des petits objets idiots quand on veut renvoyer deux valeurs depuis une fonction
??
Si tu écris une méthode qui renvoie par exemple la moyenne et l'écart type des valeurs d'un tableau, tu dois créer un petit objet débile pour contenir ces deux valeurs. En C# tu peux avoir des paramètres out (passés par référence donc) de type double pour contenir le résultat.-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 30/06/2004 à 06:37. (lien). Évalué à 3.Je pense aussi que Sun devrait modifier quelques unes des erreurs de conceptions de la JVM quitte a casser la compatibilite.
--
Vache qui rit, à moitié dans son lit
-
[^]Re: Excellent
Posté par xsnipe () le 30/06/2004 à 12:52. (lien). Évalué à 1.Et la surcharge des opérateurs, est-ce prévu ?? Ou conceptuellement, c'est incompatible avec Java (mais présent efficacement dans C# grr décidément...)
Désolé si je dis une connerie, mais je voulais savoir...--
Debian ... gentoo moi ça et vite :)-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 30/06/2004 à 12:58. (lien). Évalué à 3.Je n'en sait rien et honnetement je n'espere pas ...
Qu'y a-t-il de si formidable dans la surcharge des operateurs ? Je trouve que ca embrouille plus qu'autre chose ...
A part l'avantage d'ecrire
StringBuffer sb = new StringBuffer();
sb += "string1" + 1000L + false;
au lieu de
StringBuffer sb = new StringBuffer();
sb.append("string1").append(1000L).append(false);
ca apporte quoi ?--
Vache qui rit, à moitié dans son lit-
[^]Re: Excellent
Posté par boubou (page perso, ) le 30/06/2004 à 14:21. (lien). Évalué à 3.Ca apporte du code numérique lisible, du genre x=A*y+b où A est une matrice, x, y et b sont des vecteurs. C'est un gadget, mais un bon gadget. Et ce n'est pas prévu en Java, alors que ça existe en C#. Quelle misère.
-
[^]Re: Excellent
Posté par xsnipe () le 30/06/2004 à 14:22. (lien). Évalué à 1.Dans ce cas là je suis d'accord peut-être mais dans le cas d'un objet fait par nos petits soins ??
--
Debian ... gentoo moi ça et vite :)-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 30/06/2004 à 15:02. (lien). Évalué à 2.A part certains cas particuliers, je trouve que c'est une source d'erreurs.
Imagine, tu as une classe Compagnie et une classe Employe,
Ok tu pourrais faire
Compagnie c = new Compagnie();
c += new Employe();
ou
Compagnie c = new Compagnie();
c.add(new Employe());
Je trouve le second plus clair, au moins on est sur de ce que ca fait.
Bon a cote, forcément il y a des cas ou c'est plus joli (des lists ou des nombres par exemple), mais je trouve très peu de cas concrets ou la surcharge des opérateurs se justifie ...--
Vache qui rit, à moitié dans son lit-
[^]Re: Excellent
-
[^]Re: Excellent
Posté par xsnipe () le 30/06/2004 à 15:47. (lien). Évalué à 1.Hmmm ok... C'est vrai qu'à part l'exemple de Boubou, c'est pas si nécessaire mais bon au moins j'aurai aimé avoir le choix ;)...
Ah oui, au fait il manque aussi les pointeurs (en fait tout ce qui est unsafe est permis dans C#), là par contre je ne suis vraiment pas calé pour savoir si c'est une bonne chose à part p-e pour des pb de performances (par exemple pour un tri sur un tableau...)...--
Debian ... gentoo moi ça et vite :)-
[^]Re: Excellent
Posté par boubou (page perso, ) le 01/07/2004 à 06:31. (lien). Évalué à 3.Je ne suis pas certain que le unsafe serve à grand chose dans C# (je n'ai aucun doute sur le fait que les gens l'utilisent, mais c'est un autre problème). L'intérêt est l'interfaçage avec du code existant, mais bon, on peut faire autrement. Je doute que cela soit particulièrement important pour les performances.
-
-
-
-
-
-
[^]Re: Excellent
Posté par Cook Captain () le 30/06/2004 à 16:48. (lien). Évalué à 1.Comment représenter le terrain de jeu de stratégie temps réel ?
Ca a l'air d'être possible http://www.bytonic.de/html/jake2.html(...)
Les problèmes d'instanciation vers les types natifs en Java font qu'utiliser une List pour contenir des doubles sera toujours totalement pourri, tant en terme d'occupation mémoire que de performance, à cause du (un)boxing.
Je n'ai pas dis le contraire. En revanche je pense que le cas que tu cites (et qui est tjs cité) est finalement peu génant. Si tu veux faire des des listes de types primitifs, tu peux tjs utiliser des librairies ad-hoc si un vrai problème de perf ou d'occupation mêmoire se fait ressentir. (et ça ne m'est encore jamais arrivé et pourtant je code...)
Si tu écris une méthode qui renvoie par exemple la moyenne et l'écart type des valeurs d'un tableau, tu dois créer un petit objet débile pour contenir ces deux valeurs. En C# tu peux avoir des paramètres out (passés par référence donc) de type double pour contenir le résultat
Un peu comme les structs, c'est bien mais c'est casse-geule. Pour moi c'est le genre d'optimisation empoyé à mauvais escient qui complique nettement la compréhension du code sans apportart quoique ce soit dans la majorité des cas.-
[^]Re: Excellent
Posté par boubou (page perso, ) le 01/07/2004 à 06:47. (lien). Évalué à 4.Ton exemple est intéressant, mais c'est un FPS, par un STR. En pratique, si tu veux gérer un terrain de jeu de taille nxn, tu va bien entendu utiliser kxnxn octets, où k designe le nombre d'octets nécessaires au stockage des informations nécessaires dans chaque case du tableau. Le problème est Java est que tu te tapes :
1) un overhead d'au moins 12 octets par objet
2) une référence bouffant 4 octets par objet
3) une non localité en mémoire et donc une indirection pour chaque accès à une case du tableau
Exemple concret, j'ai une carte warcraft III de taille 128x128. Si je veux stocker une information par case en Java, je consomme 256 ko d'overhead. Bien entendu, ce n'est pas grand chose, mais c'est symptomatique des problèmes de Java. La même chose en C# ne consomme aucun overhead, n'a pas de problème de localité en mémoire et ne nécessite pas d'indirection, donc c'est strictement mieux.
Concernant les templates, le problème va beaucoup plus loin que les simples types fondamentaux. En Java, les templates sont gérés par effacement du type, ce qui pose plein de problèmes sémantiques (en particulier de sombres histoires avec les tableaux). Des choses logiques sont impossibles, ce qui gêne l'apprentissage. De plus, aucune optimisation du code des templates n'est possible car il est commun à toutes les instanciations. En C#, la machine virtuelle peut décider de spécialiser un code pour profiter de divers éléments, par exemple le fait que certaines méthodes ne sont pas virtuelles ce qui permet des inlining. De plus, j'ai des exemples concrets en C++ en calcul numérique de codes entièrement templates sur le type réel. En pratique, T=double pour les applications classiques, mais on peut écrire T=Complex dans certaines situations, voire T=Interval quand on souhaite utiliser l'analyse par intervalle pour mesurer la stabilité de l'algorithme.
Ta dernière remarque me fait penser à un point important : ça fait des années que certaines possiblités qui sont absentes en Java (les énumérés, les templates, les structs, le passage par référence, etc.) existent dans des langages très utilisés (comme C++) ou réputés pour leur qualité en terme de génie logiciel (comme Eiffel ou Ada). Ta remarque donne l'impression qu'utiliser ces possibilités est dangeureux, alors qu'on maîtrise parfaitement ces choses. Avoir deux paramètres de sortie pour une fonction est plus qu'élémentaire, n'a rien de casse-gueule et fait partie du bagage de l'informaticien classique. Ce n'est pas parce que Java a privilégié une certaine simplicité à ses débuts (bien loin de nous avec les versions récentes), qu'il faut oublier les fondamentaux !-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 01/07/2004 à 07:55. (lien). Évalué à 2.Est-ce qu'il existe des RFE pour
- le probleme d'overhead dont tu parles
- le probleme avec la maniere dont les generics sont implementes
- les lightweight objects
Si oui, je veux bien que tu me donnes les numeros histoires que je les inclues dans mes votes.--
Vache qui rit, à moitié dans son lit-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 01/07/2004 à 08:05. (lien). Évalué à 2.J'ai trouve ca et ca :
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4820062(...)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4617197(...)
Peux-tu me dire si ca correspond a ce dont tu parles ?--
Vache qui rit, à moitié dans son lit-
[^]Re: Excellent
Posté par boubou (page perso, ) le 01/07/2004 à 12:56. (lien). Évalué à 2.Oui c'est en gros ça, sauf que les solutions proposées sont dans l'esprit "on ne touche pas à la sacro sainte JVM". Le problème, c'est qu'il faudra un jour y toucher à cette JVM, sinon C# restera meilleur...
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: Excellent
Posté par mdlh () le 29/06/2004 à 10:12. (lien). Évalué à 2.Comme tu le disais plus tot, et c'est a mon sens le grand avantage de Java comme d'autres sur C/C++, l'avantage se situe dans la portabilite du "binaire". Le CERN pour ses applications a plutot tendance a utiliser des clusters pour ces calculs, et voir meme ce qu'ils appellent le grid computing.
Quand tu balances un job et que tu sais pas encore trop a l'avance sur quelle architecture ca va etre executer, la le JAVA devient reellement interessant. Pas be soin de le recompiler pour toutes les architectures. C'est fait une fois pour toute.
-
-
-
-
[^]Re: Excellent
Posté par ndesmoul () le 29/06/2004 à 08:39. (lien). Évalué à 1.Sans compter que avec la recompilation native à la volée, le binaire de l'application se retrouve en double en mémoire: la version bytecode java et la version native.
Donc Java consomme au moins deux fois plus de mémoire que le C++.
Cette consommation mémoire est à mon avis le seul vrai point faible de Java comparé au C++.-
[^]Re: Excellent
Posté par Cook Captain () le 29/06/2004 à 23:14. (lien). Évalué à 1.Sans compter que avec la recompilation native à la volée, le binaire de l'application se retrouve en double en mémoire: la version bytecode java et la version native
Pas nécessairement... A partir du moment ou le code natif est généré plus besoin du bytecode (et au pire si c'était le cas on peut toujours recharger la classe).
-
-
[^]Re: Excellent
Posté par renoo () le 29/06/2004 à 09:46. (lien). Évalué à 2.Sans compter l'absence des templates qui permettent pourtant de faire des trucs assez forts (inlining et expression template) et dont ne disposent ni java, ni c#.
ex:
- ecrire une classe de vecteur de taille fixe qui permette de générer du code efficace (sans allocation de temporaires) pour e = u + v + w. remarque en java, on voit le surcout tout de suite vu qu'on ne peut pas surcharger les operateurs.
- petite comparaison simble... comparer le tri d'un tableau de nombres complexes de facon parametrable (fonction de comparaison) entre c#, java et c++.-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 29/06/2004 à 09:51. (lien). Évalué à 2.Je n'ai rien compris a ton commentaire. Peux-tu donner plus de details ?
C'est comme je ne vois pas ce que la surcharge des operateurs vient faire la dedans ...--
Vache qui rit, à moitié dans son lit-
[^]Re: Excellent
Posté par renoo () le 29/06/2004 à 15:02. (lien). Évalué à 2.Si tu ecris une classe vecteur avec des operateurs + ou x.add(y), tu ne peux pas aditionner plusieurs vecteurs rapidement.
ex:
e.add(u);
e.add(v);
e.add(w);
Va faire plusieurs parcours de la mémoire et en c++
e = u + v + w va allouer des temporaires pour calculer (u + v), bref dans tous les cas le code est moins efficace que le code c/fortran.
for (i = 1; ...) e[i] = u[i] + v[i] + w[i];
Les expressions templates sont un moyen de marier abstraction de haut niveau et performance. C'est par contre assez technique.
http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.ht(...)
-
-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 10:10. (lien). Évalué à 1.Oui mais non. Les templates sont dans la version 1.5 de java, disponible en version beta (soit, ça ne permet pas de faire des expression templates). Pour C#, ils seront aussi dispo pour la version 2. Avec les templates du C#, on aura des performances excellentes, comparable à ce qu'on obtient en C++ pour les histoires de comparaison que tu donnes en exemple.
D'autre part, je ne suis pas super convaincu par e=u+v+w. Soit, les expressions templates permettent de faire ça de façon relativement optimale, mais j'avoue qu'utiliser BLAS me semble beaucoup plus adapté. Oui, BLAS (et Atlas) est beaucoup plus lourd à lire et à maintenir, mais mon expérience du code numérique est qu'on l'écrit une fois pour toute, ce qui est important c'est ce qui existe autour de ce code. Donc, autant écrire un noyau numérique super rapide et testé de façon très complète (de toute manière, on est obligé) avec une bibliothèque de bas niveau comme Blas (ou la GSL pour un niveau plus élevé) et l'attaquer avec un langage de haut niveau (Java, Python, etc.).-
[^]Re: Excellent
Posté par renoo () le 29/06/2004 à 14:54. (lien). Évalué à 2.Non il n'y a pas de possibilité de faire d'expression template avec les generiques de C#. Si je ne me trompe pas c'est comme la généricité d'ada avec instanciation explicite (vs l'instanciation implicite des templates c++). Pour java, je ne connais pas.
Pour l'interet des expressions templates, tu peux regarder blitz++ http://www.oonumerics.org/blitz/(...) , toujours est il que ca permet de faire des abstractions de haut niveau sans etre pénalisé.
Un exemple très simple : comment ajouter 5 vecteurs efficacement avec les blas ?-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 19:41. (lien). Évalué à 2.Ok pour C#, je te fais confiance. Pour Java, les templates étant beaucoup moins puissants que ceux de C#, le problème est réglé.
Sinon, oui, je connais Blitz++, c'est très impressionnant. Concernant ta question pour blas, je te l'accorde, le code engendré par une expression template est a priori plus efficace (j'insiste sur le a priori). Le problème c'est que quant tu regardes une implementation efficace de Blas (par exemple Atlas), tu t'apperçois que c'est du délire. Le résultat est totalement contre-intuitif. Il me semble que les benchs que j'avais regardé de Blitz++ et autres expressions templates ne comparaient ces techniques qu'à du code certe correct mais naïf, c'est à dire par exemple à celui que tu donnes en exemple au dessus. Le problème est que pour obtenir une implementation efficace du calcul matriciel et vectoriel, il faut faire beaucoup plus. Je doute que Blitz++ tienne la route face à Atlas (Atlas est tellement efficace que la plupart des logiciels propriétaires ont abandonné leur code maison pour se baser sur Atlas, comme par exemple Matlab).
Ceci dit, Blas est difficile à relire, donc...
-
-
-
-
-
-
-
[^]Re: Excellent
Posté par Tristan RENAUD (page perso, ) le 29/06/2004 à 08:31. (lien). Évalué à 2.je pense que le problème de performance est un peu "débile".
Je ne pense pas qu'il soit aussi débile que cela.
Pour certaines tâches, java n'est tout simplement pas à la hauteur d'autres langages, effectivement à cause des ressources (cycles CPU & quantité mémoire) qu'il requiert.
Si Java affichait les mêmes performances qu'un C ou C++, alors Javalayer (le player mp3 full java) serait utilisable sur mon AMD K6-2 3D 500Mhz et consommerai la même quantité de mémoire et le même temps CPU que XMMS, or ce n'est pas le cas.
Par contre, là ou réside la force de java, c'est certainement dans son haut niveau d'abstraction quant à l'architecture matériel, ce qui lui permet d'être relativement plus portable que d'autres langages.
Donc deux des points importants (il y en a bien sur d'autres) à prendre en compte lors du choix d'un langage de programmation pour le développement d'une application sont : la performance du langage, son niveau d'abstraction du matériel. Malheureusement pour Java, ces deux points s'opposent.
Mes 2 centimes d'euros.-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 08:48. (lien). Évalué à 5.Si Java affichait les mêmes performances qu'un C ou C++, alors Javalayer (le player mp3 full java) serait utilisable sur mon AMD K6-2 3D 500Mhz et consommerai la même quantité de mémoire et le même temps CPU que XMMS, or ce n'est pas le cas.
Enfin, faut aussi comparer ce qui est comparable... si on compare des softs avec des fonctionnalités différentes écrites par des personnes diférentes dans des langages différents, est ce que les différences de performances sont imputables au langage ????
Si XMMS tourne moins vite que Winamp, vas tu me dire que Delphi est un meilleur langage que C ou C++ ?
Par contre, là ou réside la force de java, c'est certainement dans son haut niveau d'abstraction quant à l'architecture matériel, ce qui lui permet d'être relativement plus portable que d'autres langages.
C'est clair, sauf que c'est pas "relativement" portable, c'est portable.. je développe des applis J2EE, SWING et WEB sous fedora et je déploy sous windows sans même faire de tests... c'est portable :)
A mon avis, les critères de choix d'un langage de programmation sont :
- Rapiditié de développement.
- Fonctionnalités offertes par l'API du langage.
- Support.
- Soutien de grands groupes privés et de grandes organisations libres au langage.
- Projets libres ( Tomcat, Junit, Ant... )
- Portabilité.
et après peut etre je mettrais les performances
-
-
-
-
-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 28/06/2004 à 20:35. (lien). Évalué à 3.Pkoi pas ?
Java sert dans de nombreuses application généralistes..
-
[^]Re: Excellent
Posté par RuleZ () le 28/06/2004 à 23:23. (lien). Évalué à 5.Mieux vaut une lenteur bien utilisée qu'une vitesse gaspillé.
Les jeux 3D (et c'est bien de cela que nous parlons, non ? Quel autre application si courante nécessiterait un rendu 3D en temps si réel ?) se vautrent dans le luxe de l'accélération matériel, au détriment de toute créativité. Qu'il est loin ce temps ou les contraintes matériels incitaient les créateurs à se creuser les méninges pour compenser les faiblesses du rendu par un intérêt de jeu accrut !
Java arrive avec sa lenteur certes, mais pour moi elle refléte plutot d'un avantage qu'un inconvénient, pour peu qu'elle tombe entre les mains d'un créateur qui sache réfléchir à deux fois pour mieux profiter d'une contrainte.-
[^]Re: Excellent
Posté par nardzir () le 29/06/2004 à 07:56. (lien). Évalué à 4.Java3D se prete tres mal a la creation de jeux car il s'agit en fait d'un arbre de scene, c'est a dire que les elements de la scene (camera, texture, transformation, trianlge, lumiere, ...) sont reliés les uns aux autres par l'intermediaire d'un graphe. Le rendu est effectué en parcourant ce graphe. Une modification de la scene necessite une modification du graphe. C'est tres facile a programmer, tres simple a manipuler, mais pas tres performant. Pour plus d'infos par exemple : http://rvirtual.free.fr/programmation/java3d/chap1/chap1.html(...)
Java3D est plus destiné aux applications de visualisation en 3D (modeleurs par exemple). Il trouve sa place dans les laboratoires et centre de recherche qui ont par exemple besoin de developper tres rapidement de petits outils de visualisation portables (car il y a souvent cohabitation entre des stations unix et des PC).
De plus, Java3D n'est pas le seul a se positionner sur ce marché : il existe une bibliotheque C++, plus complete, plus performante et surtout libre : www.coin3D.org qui propose en plus des bindings java ...-
[^]Re: Excellent
Posté par ndesmoul () le 29/06/2004 à 08:28. (lien). Évalué à 3.J'ignore si le parcours d'un graphe a réellement un tel impact sur les performances. Par contre c'est vrai que c'est plus simple à programmer que de l'OpenGL. Le peu que j'ai développé en Java3D et OpenGL me l'a confirmé.
Sinon il est tout à fait possible de faire de l'OpenGL en Java. C'est pas ce qui manque:
http://www.jausoft.com/gl4java.html(...) (date un peu), JOGL (https://jogl.dev.java.net/(...)), jGL (http://www.cmlab.csie.ntu.edu.tw/%7Erobin/JavaGL/index.html(...))
Y a aussi LWJGL (http://java-game-lib.sourceforge.net/(...)) qui est plus haut niveau.
Bref faire de la 3D en Java c'est tout à fait possible, que ce soit directement en OpenGL, Java3D ou autre. Et avec une bonne carte graphique, les performances ne doivent être très éloignées d'un jeux en C/C++.
Personnelement je trouverais ça très intéressant que plus de jeux soient en Java. Particulièrement pour l'indépendance de la plateforme. Plus besoin de râler parce qu'un jeu ne tourne que sous Windows . Ca serait pas mal. Et puis il ya aurait certainement moins de bugs (un jeu qui plante en plein milieu d'une partie difficile, c'est assez agaçant).-
[^]Re: Excellent
Posté par nardzir () le 29/06/2004 à 08:39. (lien). Évalué à 4.J'ignore si le parcours d'un graphe a réellement un tel impact sur les performances
Nan le parcours en lui meme est ce qu'il y a de plus efficace. Le probleme des graphe de scenes de ce type est la place memoire occupee d'une part et surtout la modification de l'arbre qui peut etre catastrophique en terme de performance. Si le developpeur sait ce qu'il fait (encore une fois ;) il saura eviter les manipulations de l'arbre tres couteuse a l'inverse du debutant fonctionnant par copier/coller.
Encore une fois ce type d'abstraction de haut niveau parait etre tres simple d'utilisation et tres accessible au debutant, mais sans une connaissance exacte de la mecanique interne on fait tres vite n'importe quoi.
-
-
-
-
-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 08:05. (lien). Évalué à 3.D'autant plus que Java3D est tres interessant car d'un niveau beaucoup plus haut qu'un simple bindings OpenGL.
Et c'est justement pour ça que ça rame. Java3D est sympathique, mais ne joue pas dans la même catégorie que OpenGL (et donc que Jogl, cf https://jogl.dev.java.net/(...)). En pratique, faire un moteur 3D performant, ça nécessite encore de l'assembleur ou une sorte de C (la programmation des shaders directement en assembleur ou en Cg ou un truc du genre), même avec OpenGL ou Direct3D qui sont des API pensées presque exclusivement pour les performances brutes. Si on veut faire du rapide en Java, il faut donc utiliser Jogl plutôt que Java3D.-
[^]Re: Excellent
Posté par nardzir () le 29/06/2004 à 08:23. (lien). Évalué à 4.https://jogl.dev.java.net/(...(...))
Coool je connaissais pas, par contre je trouve cette lib redondante avec java3d-core (j'ai pas trop regarder dans les details, mais a priori il s'agit dans les deux cas de bindings OpenGL)
même avec OpenGL ou Direct3D qui sont des API pensées presque exclusivement pour les performances brutes
OpenGL/Direct3D ne sont pas comparables a Java3D. OGL et D3D ne sont qu'une interface standard entre les routines de ta carte 3D et ton application. Ecrire un jeux directement sur OGL ou D3D est non seulement tres complexe mais aussi tres lent (car tu enverras a la carte 3D plus de polygonne que necessaire). Il te faut un intermediaire capable de t'afficher des objets plus complexes, des ombres, ... et surtout qui optimise le nombre de polygonnes envoyés. Java3D fait partie de cette categorie mais la structure de données utilisée privilegie la simplicité aux performances. Crystalspace et consort font eux aussi parties de cette categorie mais privilegie la rapidité en proposant une strucure de la scene plus performante et plus legere mais moins simple a utiliser.
Utiliser JOGL n'est dont pas suffisant pour faire un jeux, c'est faisable mais tres vite le developpeur se rendra compte qu'il passera plus de temps a tweaker son code pour avoir l'effet desire et surtout qu'il obtiendra un gros plat de nouille melangeant la visu et son modele de scene. Pas tres maintenable tout ca.-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 09:01. (lien). Évalué à 1.Ecrire un jeux directement sur OGL ou D3D est non seulement tres complexe mais aussi tres lent (car tu enverras a la carte 3D plus de polygonne que necessaire).
C'est une blague, je suppose ? Pourquoi tous les jeux state of the art sont écrits en OpenGL ou en Direct3D ? Les développeurs de jeu n'ont pas attendu Java3D pour écrire leurs moteurs et le résultat est bien plus performant que celui obtenu en Java3D. L'intérêt de jogl par rapport à Java3D est de permettre de faire de la 3D en Java en utilisant toutes les subtilités des cartes graphiques modernes (même le Cg !) et donc de coder un moteur de jeu (par exemple) efficace. Java3D répond peut être à certains besoins, mais jogl est beaucoup plus utile de façon générale.-
[^]Re: Excellent
Posté par ndesmoul () le 29/06/2004 à 09:13. (lien). Évalué à 2.D'une part OpenGL est plus ancien que Java3D. (Bon en même temps je penses pas que Java3D va supplanter OpenGL.)
D'autre part, les jeux state of the art en question utilisent certes OpenGL ou Direct3D, mais à moins que les développeurs soient très masochistes, je pense (j'espère pour eux) qu'ils utilisent des bibliothèques plus haut niveau, éventuellement développées en interne.
-
[^]Re: Excellent
Posté par nardzir () le 29/06/2004 à 09:18. (lien). Évalué à 2.Oui tout a fait d'accord, mais j'ai du mal m'expliquer, avec un dessin ca va etre plus clair :
Application
^
|
Moteur
^
|
OGL
Tu compares Java3D a OpenGL c'est comme si tu comparais l'assembleur au C++ (pas top comme exemple mais ca illustre bien ce que je veux dire).
les jeux state of the art sont écrits en OpenGL
Les jeux state of the art ne sont pas ecrits en OGL, c'est le moteur utilisé par ces jeux qui exploite OGL, le jeux en lui meme "ne connait pas" OGL.
OGL et D3D ne connaissent qu'une primitive : le triangle. Si tu programmes un cube directement sur OGL, tu devras explicitement decrire l'ensemble des triangles composant ton cube. Le but du moteur est justement d'eviter cela et de te fournir des routines de plus haut niveau pour demander directement un cube en une seule ligne (a peu pres).
Tu veux modifier ton cube : en OGL tu devras modifier a la main l'ensemble des triangles, avec le moteur uniquement la largeur du cube.
Donc le developpeur a le choix entre :
- utiliser Java3D ;
- reecrire un moteur complet au dessus de Jogl en sachant qu'aujourd'hui cette tache n'est envisageable que pour une equipe d'expert tres motivé (il suffit de regarder l'etat d'avancement des projets de moteurs 3D libres ...)
Vu que Java3D n'est pas une solution viable pour un jeux, les developpeurs se tournent naturellement vers d'autres moteurs libres plus complet (CS, Ogre, ...)-
[^]Re: Excellent
Posté par vrm (page perso, ) le 29/06/2004 à 12:12. (lien). Évalué à 1.franchement tu as déja programmé avec opengl ? c'est plutot facile d'utilisation, pas besoin d'être un expert, il y a plein de doc sur le Web Sinon un binding bien meilleur que JOGL (codé avec les pied par Sun) http://www.lwjgl.org(...) Quelques jeu commerciaux commence a être basé dessus : http://tribaltrouble.com(...) http://puppygames.com(...) Deux moteur plus haut niveau basé dessus : http://mojomonkeycoding.com/(...) http://www.xith3d.org(...) (un clone de java3d mais programmé correctement et suffisament performant pour faire un jeu)
-
[^]Re: Excellent
Pos
-
-
-
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.