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 (1104 hits)
- Le message sur la liste (258 hits)
- Looking Glass (823 hits)
- Les screenshots (1159 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 (1104 hits)-
Le message sur la liste (258 hits)
-
Looking Glass (823 hits)
-
Les screenshots (1159 hits)
> Lire la suite (154 commentaires, moyenne: 1,9). [dépêche : 526 caractères]
- 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.--
BeOS le faisait il y a 10 ans.-
[^]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 ;-)
-
-
[^]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 (Jabber id, ) 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)--
Ce messages est crypté par le système 42-rot13 pour plus de sécurité.
-
-
-
-
[^]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 Fabimaru! (Jabber id, 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.-
[^]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.-
[^]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)
-
-
[^]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.
-
-
-
[^]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.
-
[^]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 ?-
[^]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 ...-
[^]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.-
[^]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 ?-
[^]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 ...-
[^]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
Posté par nardzir () le 29/06/2004 à 12:28. (lien). Évalué à 2.Je n'est pas dit qu'OpenGL etait difficile d'utilisation. Les mecanismes d'OpenGL sont relativement simples a comprendre et on peut faire tres facilement en quelques lignes un cube qui tourne par exemple.
Mais OpenGL n'est pas fait pour etre utilisé directement dans un jeux. Les routines proposées sont de bas niveaux (au sens 3D) et tu devras coder la plupart des algorithmes de reduction du nombre de polygones, d'eclairage, d'ombres, d'effets speciaux ... en gros ecrire un moteur. Et crois moi cette tache n'est pas a la portée de tout le monde.
J'essayais juste d'expliquer pourquoi Java3D n'as pas vraiment eu de succes. La discussion a tournée sur la comparaison entre des binddings OpenGL et Java3D ce qui n'a aucun sens a mon avis. J'ai expliqué en quoi cette comparaison n'avait pas de sens et qu'il etait plus simple et plus facile (voir meme plus efficace) d'utiliser Java3D pour faire un jeux que de se baser sur des binddings OpenGL meme si ceux-ci exploitent les dernieres fonctionnalités des spec.
-
-
-
-
-
-
[+] [^]Re: Excellent
Posté par 007 () le 29/06/2004 à 12:28. (lien). Évalué à -3.> http://www.osnews.com/story.php?news_id=7372(...)
J'ai pas lu le détail mais ça me fait toujours rire ce genre de trucs.
Java est fourni avec des librairies CODÉES EN C/ASSEMBLEUR (java utilise aussi la libc (pourquoi il ne font pas un équivalent de la libc mais en java seulement ?)) mais on en profite pour dire que Java est plus rapide que le C.
C'est comme si je fesais un GUI en python pour libxine et après je disais :
- python c'est super rapide ça affiche les videos aussi vite que mplayer écrit en C.
N'importe quoi.
Une langage interprété (même si c'est du bytecode) est et restera pour toujours plus lent que du compilé spécifiquement pour le CPU. Peut-être qu'un jour gcj sera aussi rapide que du C mais java interprété, JAMAIS (ou alors l'équivalent C a été écrit par un porc).
Si Java roxe à ce point, pourquoi Sun n'écrit pas le noyau de Solaris en Java ?-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 12:45. (lien). Évalué à 2.Je crois que tu comprends pas...
il y a deux faces à Java :
- Ce qui se passe au dessous de la machine virtuelle.
- Ce qui se passe au dessus de la machine virtuelle.
Le Java n'a JAMAIS été écrit pour que ce qui se passe en dessous de la machine virtuelle soit écrit en Java !!
Java d'ailleurs n'accède pas aux ressources matérielles ( a part JINI )
Le but de Java est que ce qui soit construit au dessus de la JVM soit multi plateforme ( Tomcat, JOnAS, ant... ) ce qu'ils ont parfaitement réussi !!!
Que la machine virtuelle fasse des appels en C ou en assembleur, ce n'est pas le problème des développeurs Java. On ne développé plus pour un système ou quoi que ce soit.. On développé pour l'API.
On développé pour un middleware... pas pour un OS.
Si tu pousses ton raisonnement, "les compilateurs C++, c'est nul car en fait, ca transforme tout en assembleur" !!!!!-
[+] [^]Re: Excellent
Posté par 007 () le 29/06/2004 à 13:25. (lien). Évalué à -1.> Java d'ailleurs n'accède pas aux ressources matérielles
Il n'y a que le noyau qui accède au matérielle. Mais hors noyau, il n'y a rien qui empêche de faire tout le reste en java (dont un équivalent de la libc). Si java est si rapide (même plus rapide de C selon "certains" benchs) alors pourquoi ne pas faire d'équivalent de la libc en java ?
La réponse est simple => trop lent trop gros. C'est valable pour tous les langages interprétés.
Puis notes que dans un noyau il n'y a qu'une petite partie qui est dépendante du matériel. La vm, les FS, le réseau, etc... sont généralement faites pour être indépendantes du matériel (heureusement).
> Si tu pousses ton raisonnement, "les compilateurs C++, c'est nul car en fait, ca transforme tout en assembleur" !!!!!
Relis bien, je dis qu'un langage interprété est forcément plus lent que la version compilée en native.
D'ailleur il y a aussi du langage C interprété. Et il est fort logiciquement plus lent. L'interprétation (même si c'est du bytecode) bouffera toujours du temps. C'est un fait indiscutable. De plus tu ne peux pas aller très loin dans l'optimisation à la volée car ça bouffe aussi du temps. Il faut forcément faire un compromis.
Lorsqu'il y a un bench Java qui prétend que java est plus rapide que le C ou le C++ il faudrait toujours donner le temps passé dans des librairie écrite en C ou assembleur et optimisé au petit oignon.
Je peux utiliser mplayer pour lire des DVD. Fais l'équivalent de mplayer en java (c-à-d réécrit tout mplayer et n'utilise pas de librairies C fournis par mplayer) et tu auras des performances lamentables.
NB : Je trouve que Java est un bon langage et rapide. Je m'énerve sur les benchs à la con et/ou leurs conclusions.-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 13:36. (lien). Évalué à 2.Je ne suis pas spécialiste, mais quelle serait l'utilité de rédévelopper la libc ? ca voudrait dire qu'il faudrait aussi la réécrire pour Windows et pour Mac ?
Perso, je pense que les développeurs de JVM se débrouille avec ce qu'ils ont sur chaque plateforme et qu'ils pensent, comme tout bon développeur " Je vais pas réinventer la roue ".
Pour l'interprété, je ne suis pas sur mais je n'ai pas d'argument donc je m'écrase :)
Mon point de vue est que ce qu'il se passe dans la JVM n'est absolument pas du resort des dévelopeuurs Java-
[+] [^]Re: Excellent
Posté par 007 () le 29/06/2004 à 13:51. (lien). Évalué à -1.> Je ne suis pas spécialiste, mais quelle serait l'utilité de rédévelopper la libc ?
Pour moi aucune.
Mais si on prétend que Java est plus rapide que le C, il est logique de proposer la réécriture de la libc en java (au moins pour les programmes java) pour des raisons de performance. Or c'est bien pour des raisons de performance (et de portabilité) que la libc est écrite en C (comme le noyau) et ne sera jamais écrite en java.
> Mon point de vue est que ce qu'il se passe dans la JVM n'est absolument pas du resort des dévelopeuurs Java
Je ne parle pas de ça. Lors de l'exécution d'un programme en java, il y a aussi du C/assembleur qui est aussi utilisé. Or ça n'empêche pas des benchs démago de conclurent que java est plus rapide que le C.
Si on fait un bench qui compare le langage java au langage C, il faut vérifier qu'uniquement du java est utilisé pour java (par exemple pas de librairie écrite en C utilisée (ou uniquement la libc)).
Je parle dans ce thread, uniquement de vitesse ! Je ne parle pas de l'intérêt d'utiliser Java (portabilité, api de haut-niveau, etc...).
-
-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 29/06/2004 à 13:42. (lien). Évalué à 2.Euh ... le Java n'est pas interprete (pas en tant que tel)
Et puis c'est quoi ton trip avec la libc ?? Pourquoi la reecrire en Java ??
De plus, je te signale qu'une grosse partie des API Java est implemente en Java, seules les parties ou on ne peut pas faire autrement son ecrites avec JNI ...-
[^]Re: Excellent
Posté par 007 () le 29/06/2004 à 13:53. (lien). Évalué à 0.> Et puis c'est quoi ton trip avec la libc ?? Pourquoi la reecrire en Java ??
Tu sais lire ? SI java est plus rapide que le C, tu ne vois pas l'intérêt d'avoir une libjava.-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 29/06/2004 à 14:02. (lien). Évalué à 3.Ben il y a une libjava ... C'est les librairies J2SE de Java ...
Je ne comprends absolument pas ou tu veux en venir ...
Pourquoi veux-tu une librairie en Java pour developper en C ??-
[+] [^]Re: Excellent
Posté par 007 () le 29/06/2004 à 14:52. (lien). Évalué à -2.> Pourquoi veux-tu
Ben tu ne sais pas lire ou t'as un problème de cerveau ou je cause le chinois ou...
Mais t'as rien compris.
Bon, je vais faire plaisir à tout le monde :
- Java est plus rapide que le C++, le C, l'assembleur et le concorde.-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 29/06/2004 à 15:03. (lien). Évalué à 2.Je te prierais de rester poli, et je te serais gré de m'expliquer ce que la libc vient foutre dans le bordel ?
Tu sors des trucs qui n'ont aucuns sens et puis tu t'excites parce qu'on ne les comprends pas.-
[+] [^]Re: Excellent
Posté par 007 () le 29/06/2004 à 15:16. (lien). Évalué à -1.> Je te prierais de rester poli
J'ai dit "ou je cause le chinois"
> m'expliquer ce que la libc vient foutre dans le bordel ?
Relis depuis ici :
http://linuxfr.org/comments/439150.html#439150(...)
-
-
[^]Re: Excellent
Posté par ndesmoul () le 29/06/2004 à 15:19. (lien). Évalué à 3.Voilà t'as tout compris :)
Plus sérieusement, du code java s'exécute dans sa machine virtuelle cloisonnée. Pas évident pour accéder à du bas niveau. La vocation de Java n'a jamais été de faire ce genre de chose, peu importe la vitesse du langage.
Pour ce qui est des performances justement, du code recompilé nativement peut dans certains cas (très?) particuliers être effectivement plus performants que du C++ (et pas du C, la comparaison des perfs du C et du C++ c'est encore un autre troll).
Maintenant, Java est un langage plus haut niveau, qui fait plus de vérifications coûteuses sur le code qu'il exécute et se montre moins apte aux optimisations poussées propres à la plateforme. Au final les performances sont relativement proches du C++, et bien plus rapide qu'un langage de script.
D'autre part les perf dépendent beaucoup de la JVM utilisée. Celle d'IBM est bien plus performante que celle de SUN au passage (même en mode server). Quand à la compilation native avec GCJ ou autre, les tests que j'ai pu voir/faire montrent que c'est soit moins performants (GCJ) soit équivalent. On gagne surtout en mémoire et rapidité de lancement.-
[+] [^]Re: Excellent
Posté par 007 () le 29/06/2004 à 16:07. (lien). Évalué à -1.> Quand à la compilation native avec GCJ ou autre, les tests que j'ai pu voir/faire montrent que c'est soit moins performants (GCJ) soit équivalent.
Je pense que beaucoup d'optimisation peuvent encore être faite ici. Il doit y avoir encore beaucoup de marge (genre un rapport 2 ou 3 sans problème). L'optimisation de gcj n'a pas vraiment commencée. Puis ça permet des "fantaisies" comme ne plus contrôler les débordements si l'appli marche sans problème (comme lorsqu'on compile un programme avec ou sans dmalloc).
-
-
-
-
-
-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 14:46. (lien). Évalué à 2.qu'un langage interprété
Java n'est pas un langage interprété. Il est compilé au vol, comme le C# et sur une application qui ne tourne pas 5 secondes, cela permet de faire des optimisations qui ne sont pas possible à faire (ou très difficile à faire) statiquement, ce qui donne au final un code qui est parfois plus rapide. De plus, certaines contraintes sémantiques de Java (ou de C#) font que certaines optimisations sont possibles dans ces langages et pas en C/C++ (en particulier à cause des pointeurs). Par exemple, on peut déterminer si les bornes d'un tableau sont respectées dans une boucle avant de l'exécuter, ce qui permet de supprimer les tests de débordement au moment de la compilation effective en code machine.
D'autre part, je ne vois vraiment pas le problème d'avoir un mélange de C et de Java, du moment que je ne vois pas le C quand je programme en Java. En fait, cela permet de faire ce qui est critique en C (voir en assembleur) et le reste en Java. Les progrès des machines virtuelles font qu'on a de moins en moins besoin de passer en C. Il y a quelques années, un jeu était programmé en C et en assembleur. De nos jours, on a un mélange Python pour les scripts, C++ pour le moteur de haut niveau, C pour attaquer OpenGL et de l'assembleur spécifique pour les shaders. A chaque problème son outil !-
[+] [^]Re: Excellent
Posté par 007 () le 29/06/2004 à 15:01. (lien). Évalué à -2.> Java n'est pas un langage interprété.
Même si c'est du bytecode, le bytecode doit être interprété avant de donner quelque chose à manger au CPU. C'est un fait.
> Par exemple, on peut déterminer si les bornes d'un tableau sont respectées dans une boucle avant de l'exécuter, ce qui permet de supprimer les tests de débordement au moment de la compilation effective en code machine.
Et le développeur en C peut utiliser son cerveau et voir qu'il n'y a pas de débordement et ne jamais faire de teste.
> D'autre part, je ne vois vraiment pas le problème d'avoir un mélange de C et de Java
Relis le thread depuis ici :
http://linuxfr.org/comments/439150.html#439150(...)
J'ai aucun problème avec le mélange de C/pascal/basic/lisp/java. Je parle des conclusions de bench.
J'ai aussi aucun problème avec Java. Je répète encore une fois :
- Java c'est bien
J'arrête, les gens ne savent pas lire ici.-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 29/06/2004 à 15:06. (lien). Évalué à 5.Sans vouloir te blesser, si personne ne comprend ce que tu dis, ce n'est peut-être pas que les gens ne savent lire mais que tu as des difficultés pour t'exprimer ...
-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 15:08. (lien). Évalué à 2.Et le développeur en C peut utiliser son cerveau et voir qu'il n'y a pas de débordement et ne jamais faire de teste.
Alors ca, je trouve que c'est une très mauvaise idée !!!!
Je suppose que tu penses aussi que les tests unitaire automatisés, ca sert à rien ???
Je comprends ce que tu voulais dire dans tes précédents posts et je comprends que certains ne soit pas d'accord...
Je pense que de toute façon, comme toi, que les benchs, ca vaut rien du tout :)-
[+] [^]Re: Excellent
Posté par 007 () le 29/06/2004 à 15:28. (lien). Évalué à -2.> Alors ca, je trouve que c'est une très mauvaise idée !!!!
Je ne parle QUE de vitesse !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Je ne dis pas si c'est intelligent ou non d'utiliser un langage qui contrôle les débordements. C'est claire !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> Je pense que de toute façon, comme toi, que les benchs, ca vaut rien du tout :)
C'est la conclusion de CERTAINS benchs qui m'énerve.
Voir par exemple :
http://www.osnews.com/story.php?news_id=7372(...)
Here is a comparison of a C and Java speech librarywhere the Java version is 2-3 times faster, with server VM configuration. And here are some more C++ and java comparisons, with various algorithms. Elsewhere, Java 1.5 is 20% faster than C says JavaLobby. And some of our tests.
C'est du foutage gueule.
Pour les fines bouches :
http://www.kano.net/javabench/(...)
Si tu es développeur java, peux-tu honnètement dire que mplayer serait plus rapide s'il était écrit en java et non en C ?
-
-
[^]Re: Excellent
Posté par nardzir () le 29/06/2004 à 15:17. (lien). Évalué à 2.Même si c'est du bytecode, le bytecode doit être interprété
Mais non !!! puisqu'on te dis que quand la JVM le peut, le bytecode est compilé par anticipation !!!! donc plus d'interpretation pendant l'execution...
Et le développeur en C peut utiliser son cerveau et voir qu'il n'y a pas de débordement et ne jamais faire de teste.
Oulala la bonne idée ;)-
[^]Re: Excellent
Posté par 007 () le 29/06/2004 à 15:58. (lien). Évalué à 0.> Mais non !!! puisqu'on te dis que quand la JVM le peut
Et le JVM n'interprète pas le bytecode ? Elle envoie le bytecode au cpu sans rien faire ?
Mais oui....
> le bytecode est compilé par anticipation !!!!
D'ailleur la prochaine JVM donnera le résultat par anticipation. Avant même d'exécuter le code. Formidable !
Le marketing SUN a bien bossé.
> Oulala la bonne idée ;)
Tu fais tes tests avec dmalloc (c'est lent mais il contrôle les débordements comme java (ou presque)). Et quand ça marche tu vires dmalloc pour ne conserver que les contrôles nécessaires. C'est une pratique très courrante...-
[^]Re: Excellent
Posté par Roger Rabbit () le 29/06/2004 à 16:14. (lien). Évalué à 3.Franchement tu fais chier ...
Ce thread était globalement interessant, toi tu arrives et en 3 heures tu pourris le machin ...
Pour te répondre néanmoins, quand la jvm detecte qu'une partie du code est souvent employée, ca peut etre une méthode ou un enchainement de méthode, et bien elle la compile nativement.
Ensuite quand on redemande l'execution de ce bytecode, c'est la version native qui sera executé et non plus la version interpreté.-
[^]Re: Excellent
-
-
[^]Re: Excellent
Posté par nardzir () le 29/06/2004 à 16:16. (lien). Évalué à 2.Elle envoie le bytecode au cpu sans rien faire ?
Nan elle envoie le resultat de la compilation.
Et quand ça marche tu vires dmalloc pour ne conserver que les contrôles nécessaires. C'est une pratique très courrante...
Et qui te garantie que tu as prevu tous les cas d'utilisation... A mais c'est vrai tu es tres fort et tu as tout prevu meme les cas les plus tordus ... A t'endendre les bugs n'existeraient pas.-
[^]Re: Excellent
Posté par 007 () le 29/06/2004 à 16:41. (lien). Évalué à 0.> Et qui te garantie que tu as prevu tous les cas d'utilisation...
Pssss.
T'inquiète pas, je sais coder en C et des applis qui tournent 24/24h 7/7j 365j/an (appli résidante de suivi de production).
> A t'endendre les bugs n'existeraient pas.
A t'entendre les bugs c'est toujours des débordements...
Les débordements sont souvents les trucs les plus faciles à détecter (au moins avec dmalloc).
Et ne t'en déplaise, c'est une pratique très courrante en développement C.
De plus quand tu codes proprement, tu ne fais pas des tableaux (avec des hideux "#define MAX_ELTS") mais des listes chainées et tu utilises malloc. Les cas de débordement sont très rare et les problèmes sont dans 99 % cas ailleurs.-
[^]Re: Excellent
Posté par nardzir () le 29/06/2004 à 17:12. (lien). Évalué à 3.A t'entendre les bugs c'est toujours des débordements...
Bon ba je vais arreter la, t'es vraiment de mauvaise fois, tu fais deriver le debat sur autre chose. Mais bon a force je commence a te connaitre, c'est pas la premiere fois que tu relances le sujet sur des affirmations fausses afin de tuer le débat.-
[+] [^]Re: Excellent
Posté par 007 () le 29/06/2004 à 18:00. (lien). Évalué à -1.> des affirmations fausses
Tu codes beaucoup en C pour affirmer que mon affirmation est fausse ?
Si tu parles de déréférencement de pointeur après un free(), voire pas alloué du tout, ou de fuite de mémoire, je veux bien te croire que ça arrive souvent en C. Mais des débordements quand tu codes proprement (et sans forcer) c'est assez rare et souvent des erreurs de nouveaux (oublie d'ajouter '\0', manque un "+1" après un strlen(), utilisation d'un fonction qui n'est pas "safe", etc).
Pour avoir beaucoup codé en C, les erreurs sont très souvent ailleurs. Par contre au début ça arrive assez souvent.
J'espère que quelqu'un qui code beaucoup en C pourras te le confirmer.
-
-
[^]Re: Excellent
Posté par Stéphane TRAUMAT (page perso, ) le 29/06/2004 à 20:21. (lien). Évalué à 1.Sans tests unitaires, je sais pas comment tu fais.... ca me parait impossible.
-
[^]Re: Excellent
-
-
-
-
[^]Re: Excellent
Posté par Matthieu Moy (page perso, ) le 29/06/2004 à 16:22. (lien). Évalué à 2.> Et le JVM n'interprète pas le bytecode ?
Non.
Enfin, les vieilles le faisaient, mais une JVM digne de ce nom, au même titre que l'environnement .NET, compile le byte-code au moment ou elle le charge. Pour du C, si tu considères que
#!/bin/sh
gcc hello.c && ./a.out && rm ./a.out
interprête le code C, alors, la JVM interprête le byte-code. Si tu considères que le script ci-dessus compile puis execute en natif le code, alors la JVM aussi.
> Elle envoie le bytecode au cpu sans rien faire ? Mais oui....
Ben non, elle le compile avant !
> Tu fais tes tests avec dmalloc (c'est lent mais il contrôle les débordements comme java (ou presque)).
Tu fais bien d'ajouter le *ou presque*. Disons que ca n'a pas grand chose à voir. En C, avec un déboggeur mémoire (j'utilise valgrind. Je suppose que dmalloc fait à peu près la même chose), tu peux vérifier que sur une execution donnée, il n'y a pas eu de débordement de mémoire. En Java, les débordements de mémoire sont impossibles par construction du language. Aux bugs de la JVM près, il ne peut donc y avoir de débordement mémoire sur *aucune* execution possible.
Ca, c'est au niveau Java. Au niveau byte-code, il y a un vérificateur de byte-code qui vérifie que le byte-code est bien typé au chargement, ce qui te permet le même genre de propriété. Le résultat, c'est que tu peux par exemple charger un programme à toi et un programme a qui tu ne fais pas confience dans la même JVM (Dans des threads séparés). Tu as la garantie que l'autre application ne pourra pas écrire dans ta mémoire.-
[^]Re: Excellent
Posté par 007 () le 29/06/2004 à 16:55. (lien). Évalué à 0.> gcc hello.c && ./a.out && rm ./a.out
la phase "gcc hello.c" il faut que la jvm la fasse. C'est du boulot, ça bouffe de la mémoire. "gcc hello.c" n'est fait qu'une seul fois en C et rarement par l'utilisateur. C'est un fait.
Je répète pour la 20 000 ième fois. J'ai rien contre Java. Ce qui m'énerve c'est d'entendre que Java est plus rapide que le C ou le C++. C'est tout.
Si on me trouve un navigateur web écrit en java aussi complet que gecko et aussi rapide j'y réfléchirai un peu plus.
Mais il n'y a pas une seule applis une peu "lourde" qui tourne plus vite en java qu'en C ou C++. Mais si je me trompe n'hésitez pas à me donner des exemples.
> Tu as la garantie que l'autre application ne pourra pas écrire dans ta mémoire.
Je répète encore : je ne parle QUE de vitesse.
D'accord, la vitesse c'est pas tout dans un langage. Mais je ne parle que de vitesse.-
[^]Re: Excellent
Posté par nardzir () le 29/06/2004 à 17:09. (lien). Évalué à 2.la phase "gcc hello.c" il faut que la jvm la fasse
C'est du boulot oui, la premiere execution de la partie compilée sera plus lente la premiere fois mais pas apres.
Pour revenir sur les bench, il est juste dit que pour ces exemples Java est plus rapide que C++. Apres si ca t'enerve c'est ton probleme, mais pour ces algo c'est la realité.-
[^]Re: Excellent
Posté par 007 () le 29/06/2004 à 18:03. (lien). Évalué à 0.> Apres si ca t'enerve c'est ton probleme
Je peux pas non.
> mais pour ces algo c'est la realité.
Même pas. Lis les commentaires :
http://www.osnews.com/comment.php?news_id=7372&limit=no(...)
-
-
-
-
-
-
[^]Re: Excellent
Posté par boubou (page perso, ) le 29/06/2004 à 19:44. (lien). Évalué à 3.Même si c'est du bytecode, le bytecode doit être interprété avant de donner quelque chose à manger au CPU. C'est un fait.
Et bien non, le bytecode de Java et celui de C# sont compilés au vol. Renseigne toi, lit des docs et ensuite reviens discuter.
Et le développeur en C peut utiliser son cerveau et voir qu'il n'y a pas de débordement et ne jamais faire de teste.
Code dans les inombrables buffer overflow qui pourissent la sécurité des applications standards ?-
[^]Re: Excellent
Posté par 007 () le 29/06/2004 à 20:22. (lien). Évalué à 0.> Et bien non, le bytecode de Java et celui de C# sont compilés au vol.
Interprété, compilé, machiné, bidulé, trucmuchiné, le problème n'est pas là. Il y a une étape supplémentaire par rapport à du C lors de l'excution.
> Code dans les inombrables buffer overflow qui pourissent la sécurité des applications standards ?
Très bon exemple, merci. Les buffer overflow sont TRÈS RARES par rapport à tous les autres bugs d'une application en C. Puis amuses à compter les trous de sécurité par buffer overflow par rapport à l'ensemble des trous de sécurité des applis écrite en C et je ne serais pas étonné que ça fasse moins de 5 %. Par contre ils sont effectivement très génant lorsque ça permet d'attaquer un segment exécutable. Mais c'est en passe de s'arranger avec exec-shield ou NX.
Je recentre encore le "débat", je ne discute pas des divers avantages de java mais uniquement de la vitesse. Et plus particuliairement du "java est plus rapide que le C".-
[^]Re: Excellent
Posté par Cook Captain () le 29/06/2004 à 23:45. (lien). Évalué à 2.Interprété, compilé, machiné, bidulé, trucmuchiné, le problème n'est pas là. Il y a une étape supplémentaire par rapport à du C lors de l'excution.
Il y a exactement le même nombre d'étapes sauf qu'elles n'intervienent pas au même moment.
Je recentre encore le "débat", je ne discute pas des divers avantages de java mais uniquement de la vitesse. Et plus particuliairement du "java est plus rapide que le C".
Comme l'a trés bien expliqué boubou, il est tout à fait possible que dans *certains* cas un programme Java soit plus rapide que le même proramme en C/C++, et ce pour une raison bien simple : en Java il est possible de faire des optimisations dans la VM en cours d'exécution et donc de générer dynamiquement du code optimisé (tu peux imaginer une analogie simple avec les bases de données qui te permettent de faire des statistiques en cours de fonctionnement sur tes données pour en optimiser les chemins d'accès). En revanche, Java utilisera à coup sur tjs plus de mémoire que le même programme en C/C++.-
[^]Re: Excellent
Posté par 007 () le 30/06/2004 à 02:22. (lien). Évalué à 0.> en Java il est possible de faire des optimisations dans la VM en cours d'exécution et donc de générer dynamiquement du code optimisé
Pour donner le fond de ma pensée : c'est du pipo de marketeux !
Je veux de concrêt. Trouves mois un cas concrêt où c'est possible. C'est-à-dire que l'analyse ET l'optimisation supplémentaire ne coût pas plus cher qu'une optimisation "statique" aux petits oignons par le compilateur "statique" (il a le temps de faire l'optimisation lui...). Comme je l'ai dit ailleur je ne vois pas ce que peut apporter cette optimisation "dynamique". Si tu peux répondre à l'autre post sans pipo marketeux, c'est un plus.
btw, si l'optimisation est faite qu'une seule fois (comme souvent dit ici), je ne vois pas en quoi c'est dynamique !
> il est tout à fait possible que dans *certains* cas un programme Java soit plus rapide que le même proramme en C/C++
Si celà arrive, c'est seulement la preuve que le compilateur C n'est pas bon ou que le code C équivalent à la fonctionnalité java n'est pas top. Point barre.
Lis les commentaires de la news osnews :
http://www.osnews.com/comment.php?news_id=7372&limit=no#249529(...)
g++ lost fibo, hash2, methcall narrowly (scored between the 2 jvm's in all cases)
g++ won heapsort, objinst, sieve narrowly
g++ won hash, ackerman, strcat, matrix by 1.4 - 3x faster
g++ won nestedloop, random by 6x - 7x.
Et ça sur des tests qui sont sensés montrer la supériorité de java. Alors en usage général... Tiens donnes UN programme de la "vie réelle" ou java tourne plus vite.
Si g++ ne "gagne" pas pour les premiers tests, c'est de peu.
De plus, on ne connais pas les fonctions écritent en C qui sont utilisées par java et qui sont peut-être mieux foutu que le code C utilisé pour le bench de g++ (ya pas les source jdk). Et oui, java utilise des fonctions dans la VM qui sont écrites en C.
Ce que peut faire Java, le compilateur C peut le faire et à coût 0 lors de l'utilisation.
> tu peux imaginer une analogie simple avec les bases de données qui te permettent de faire des statistiques en cours de fonctionnement sur tes données pour en optimiser les chemins d'accès
C'est de l'analyse de données qui sont DYNAMIQUE !
Que je sache, je code java n'est pas dynamique. Où alors c'est un sacré bordel à programmer et forcément lent (il faut systématiquement optimiser à nouveau un code qui change).
> En revanche, Java utilisera à coup sur tjs plus de mémoire que le même programme en C/C++.
Et donc il passe du temps à "brasser" plus de données, le cache cpu est moins heureux, etc. Belle optimisation.
J'ai vu un test qui montrait que ne plus mettre certaines fonctions réseaux _inline_ dans le noyau permettait un gain significatif de performance simplement car le cache du cpu est moins stressé. Et pourtant _inline_ sur le papier c'est mignon.-
[^]Re: Excellent
Posté par Cook Captain () le 02/07/2004 à 23:45. (lien). Évalué à 1.C'est de l'analyse de données qui sont DYNAMIQUE !
Que je sache, je code java n'est pas dynamique. Où alors c'est un sacré bordel à programmer et forcément lent (il faut systématiquement optimiser à nouveau un code qui change).
Si le code généré par la JVM (au moins celle de Sun en mode -server) peut changer en fonction des données collectées. C'est particulièrement interessant pour les applis fortement orientés objets car cela permet en autre de dévirtualiser certaines méthodes.
-
-
-
-
-
-
[^]Re: Excellent
Posté par reno () le 29/06/2004 à 21:14. (lien). Évalué à 1.> Il est compilé au vol, comme le C# et sur une application qui ne tourne pas 5 secondes, cela permet de faire des optimisations qui ne sont pas possible à faire (ou très difficile à faire) statiquement, ce qui donne au final un code qui est parfois plus rapide.
Certes mais quand tu vois le temps que ça prend de compiler un programme avec toutes les optimisations en C ou en C++, le fait de compiler a la volée veut dire aussi qu'il y a des tas d'optimisation que tu ne peux pas faire car elle ralentirait trop l'execution du programme..
Pour ton exemple de bornes de tableau: un compilateur statique pourrait tres bien faire la meme chose! Il compile deux versions du code de la boucle et genere un test en entrée: si le test d'entree indique que la borne du tableau n'est jamais dépassé, il entre dans le code sans tests dans la boucle sinon il va dans le code "normal".
Bien entendu, un compilateur a la volée a le maximum d'information sur l'état courrant réel, mais un compilateur statique qui optimise d'apres un profil d'execution, cela peut faire des trucs sympa aussi: il a le temps lui.. Mais bien sur le profil de test peut être partiellement different de l'usage réel.-
[^]Re: Excellent
Posté par 007 () le 29/06/2004 à 21:43. (lien). Évalué à 0.> Mais bien sur le profil de test peut être partiellement different de l'usage réel.
Je ne suis pas un spécialiste en compilateur ni en java. Mais j'ai un sérieux doute sur le fait d'avoir une meilleur optimisation si c'est fait à la volée.
Lorsque que tu optimises un bloque tu vas brosser plusieurs scénarios en fonction des variables dans ce bloque. Cette analyse est aussi pertinente lors d'une compilation à la volée qu'en "statique". Si 'a' est une variable à l'entrée du bloque elle le sera toujours que la compilation soit faite à la volée ou en statique. Le compilateur a la volé ne peut pas suposer que 'a' sera toujours à 0 à l'entrée du bloque et adapté l'optimisation. Idem pour le compilateur "statique".
Exemple naïf :
f(a) {
while (a) {
a-- ;
[...]
}
Si 'a' est à 0 la fonction ne fait rien. Comment peut faire le compilateur à la volée pour savoir que 'a' sera toujours à 0 à l'entrée de la fonction ? Même problème pour le compilateur "statique".
Le deux type de compilation ne peuvent pas le savoir à moins que ce soit des cas très simple genre il n'y a que des appels à f(0). Mais même ce cas est très difficile a détecter avec les pointeurs de fonction par exemple ou les plug-ins chargés à la demande et qui appèlent f() . N'envisagons pas le cas où la valeur de 'a' est fixé par un autre thread ou processus ou une entrée/sortie. Même en rêve c'est impossible.-
[^]Re: Excellent
Posté par allcolor (Jabber id, page perso, ) le 30/06/2004 à 06:20. (lien). Évalué à 1.Comment peut faire le compilateur à la volée pour savoir que 'a' sera toujours à 0 à l'entrée de la fonction ?
Parce que c'est déjà "précompilé" en bytecode, et sais tu que pour cette transformation de ton code source en bytecode, on utilise ce qu'on appelle un compilateur, et chose étonnante, ce compilateur optimise le code, bizarre hein.--
All those moments will be lost in time, like tears in rain.-
[^]Re: Excellent
Posté par 007 () le 30/06/2004 à 06:57. (lien). Évalué à 0.> Parce que c'est déjà "précompilé" en bytecode
Ben en langage C c'est "compilé" en bytecode natif.
T'as rien compris.
Le problème est de savoir comment fait l'optimiseur pour détecter si 'a' (dans f()) sera toujours à 0 ou non et ainsi appliquer une optimisation. C'est un exemple simpliste.
Exemple :
f(int a) {
while (a) { a-- ; [...] }
}
const int a = 0 ;
f(a) ;
f(a) ;
f(0) ;
Là le compilateur peux remarquer assez facilement que l'appel à f() ne fait rien et peu supprimer les appels à f().
Un autre exemple et là j'attends tes "lumières" :
f(int a) {
while (a) { a-- ; [...] }
}
h(int a) {
while (!a) { a++ ; [...] }
}
int a = 0 ;
g = f ;
p(&a) ;
g(a) ; // a : n'est pas connu à la compilation
a = read(stdin) ; // a : n'est pas connu à la compilation
conpute_it_with(chose_randomly(g,h)) ; // a : n'est pas connu à la compilation et f() n'est peut-être pas appelé...
Là pour savoir si f() est toujours appelé avec en paramètre 0, c'est impossible.
Et si c'est possible avec une compilation "dynamique" j'aimerai que tu m'expliques.
Et quelque chose de plus consistant que "parce que c'est déjà "précompilé" en bytecode"
-
-
-
-
-
-
-
[^]Re: Excellent
Posté par Roger Rabbit () le 29/06/2004 à 12:59. (lien). Évalué à 3.Justement non ...
A l'execution, java est compilé partiellement à l'aide d'un programme
en C pour produire des instructions machines.
Le code natif résultant n'est *pas* du C. Le C sert juste à compiler
le bytecode en natif. Le compilateur pourrait etre en delphi ca serait
pareil.
.....-
[^]Re: Excellent
Posté par 007 () le 29/06/2004 à 13:36. (lien). Évalué à 0.> Le compilateur pourrait etre en delphi ca serait pareil.
J'en rigole encore.
Et pourquoi ils le font pas en Java alors ? Absolument rien n'empêche de faire un compilateur en java (Il n'y a aucun accès matériel).-
[^]Re: Excellent
Posté par nardzir () le 29/06/2004 à 13:51. (lien). Évalué à 2.Et pourquoi ils le font pas en Java alors ?
Parce qu'il faudrait une machine virtuelle pour faire fonctionner cette machine viruelle ecrite en Java.-
[^]Re: Excellent
-
[^]Re: Excellent
Posté par allcolor (Jabber id, page perso, ) le 29/06/2004 à 15:32. (lien). Évalué à 1.Un os en java : http://jnode.sourceforge.net/portal/(...)
Une jvm en java qui se bootstrap sans jvm additionnel : http://www-124.ibm.com/developerworks/oss/jikesrvm/(...)--
All those moments will be lost in time, like tears in rain.-
[^]Re: Excellent
Posté par nardzir () le 29/06/2004 à 15:37. (lien). Évalué à 2.Une jvm en java qui se bootstrap sans jvm additionnel
C'est assez fort comme truc effectivement, mais a mon avis ils utilisent tout de meme une mini JVM pour initier le noyau de Jikes. Une fois cette base en memoire, le reste de la JVM peut s'executer. Ou alors ils ont resolu le probleme de l'oeuf et de la poule...
-
[+] [^]Re: Excellent
Posté par 007 () le 29/06/2004 à 16:06. (lien). Évalué à -1.> Un os en java : http://jnode.sourceforge.net/portal/(...)
Et il faut voir les performances :
http://jnode.sourceforge.net/portal/node/view/51(...)
La comparaison n'est pas par rapport à un Linux/libc mais par rapport à Sun J2SDK (une machine virtuelle qui tourne sur un OS bien réel) et c'est plus lent...
Donc java plus rapide que le langage C : dans 400 ans et c'est vraiment pas sûre.-
[^]Re: Excellent
Posté par Pipo2 () le 29/06/2004 à 19:31. (lien). Évalué à 0.J'ai lu tout le fil de discussion et je suis globalement d'accord avec toi sur le fond.
Il est clair que poser du byte code par dessus une machine virtuelle elle-même exécutée par un OS, en toute logique, ne peut pas constituer une méthode plus performante ou même plus satisfaisante en terme d'utilisation des ressources qu'une conception fondée sur un programme directement exécuté par l'OS. Et quels que soient les artifices utilisés (appel de bibliothèques binaires externes, réutilisation du code déjà compilé just in time, ...).
Il est certain aussi que dans ce genre de débat avec les tenants de la chose, tu n'aura jamais le dernier mot, mais essaye de discuter de sécurité avec des militants Microsoft et tu auras les mêmes sensations.
Cependant, si les performance et l'utilisation des ressources ne sont pas optimals avec ce type d'architecture, si la portabilité est une légende dans la mesure où on compile du C/C++ sur beaucoup plus de plateformes différentes qu'il n'existe de JVM, Java en tant que technologie présente des avantages sympas :
- La compilation JIT offre des possibilités dynamiques qu'on peut difficilement imiter en C++ (ex: instanciation d'un objet à partir d'une classe désignée par une chaîne de caractères)
- L'abstraction poussée permet généralement un développement plus rapide pour, notamment lorsque l'application finale nécessite des performance, une maquette
- Lorsqu'on distribue un produit multi-plateformes, il est très agréable de n'en maintenir qu'une version et de laisser tes clients se démerder pour trouver la JVM adaptée à leur environnement
Java présente certainement bien d'autres aspects intéressants mais je ne suis pas assez versé dans ce truc pour les connaître.
Pour finir, au fait, un truc que je ne comprend pas, mais pourquoi, si Java est une technologie plus performante que le compilé, la libc n'est-elle pas développé en Java ? (j'ai vu la question mais pas de réponse)-
[^]Re: Excellent
Posté par 007 () le 29/06/2004 à 20:21. (lien). Évalué à 0.> J'ai lu tout le fil de discussion
Je te béni pour ta démarche.
> Java en tant que technologie présente des avantages sympas
Je ne reproche rien à Java et je ne dis pas qu'il est lent compte-tenu de ces avantages. Mais j'en ai marre de lire tous les mois un bench donc la conclusion est "java est plus rapide que le C et le C++". Ceci est techniquement impossible. Ou alors le compilateur C est loin d'être au point.
J'utilise aussi des langages interprétés avec beaucoup de bonheur (python, php). Mon propos n'est pas de dissuader les gens d'utiliser java (sauf pour l'aspect un petit peu proprio de java).-
[^]Re: Excellent
Posté par Cook Captain () le 29/06/2004 à 23:55. (lien). Évalué à 3.Ceci est techniquement impossible
Ce n'est pas parce que tu le penses que ce n'est pas le cas.
C'est techniquement possible et c'est déja le cas. Et ce n'est pas parce que c'est le cas sur certains benchs que c'est tjs le cas (loin de là).-
[+] [^]Re: Excellent
Posté par 007 () le 30/06/2004 à 02:43. (lien). Évalué à -3.> Ce n'est pas parce que tu le penses que ce n'est pas le cas.
Ben montres moi un bench avec java qui n'utilise pas les fonctions de haut-niveau de la VM.
Par exemple un bench avec un tri bulle écrit en java (c'est à dire sans utiliser de fonctions C de la VM qui font le tri).
Tu peux aussi choisir la manipulation de chaine de caratère, la recherche dans une liste, etc... T'es libre. Mais que du java et pas du java qui utilise une librairie écrite en C (généralement dans la VM).
Bonne chance...
-
-
-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 30/06/2004 à 06:33. (lien). Évalué à 2.C'est desesperant ... Un vrai dialogue de sourds ...
Personne ne dit que Java est plus rapide que le C. Bien entendu dans 99% des cas une application en C sera plus rapide et consomera moins de memoire qu'une application Java.
Par contre il y a quelquechose qu'on ne peut nier : avec le temps les JVM et les compilateurs JIT s'ameliorent enormement, les performances de Java augmentent de plus en plus, et _dans certains cas tres precis_ les optimisations effectuees par le compilateur JIT peuvent donner des performances excellentes (superieures a certaines implementations en C).
Mais globalement, le C reste plus rapide que Java.
Tout le monde est d'accord la ?-
[^]Re: Excellent
Posté par 007 () le 30/06/2004 à 07:11. (lien). Évalué à 0.> superieures a certaines implementations en C
Je suis d'accord avec ta formulation. Le "certaines implementations" est très important.
On est loin des articles/benchs à l'origine de ce long thread :
http://www.osnews.com/story.php?news_id=7372(...)
Here is a comparison of a C and Java speech librarywhere the Java version is 2-3 times faster, with server VM configuration. And here are some more C++ and java comparisons, with various algorithms. Elsewhere, Java 1.5 is 20% faster than C says JavaLobby.
Lire les commentaires osnews avant de faire "amen".
-
-
-
-
-
-
-
-
-
[^]Re: Excellent
Posté par nakan (page perso, ) le 29/06/2004 à 14:09. (lien). Évalué à 0.Personnellement, je ne comprend pas bien l'utilité d'un librairie libre dans le langage Java pseudo propriétaire d'aujourd'hui.
Quel est le véritable avantage?--
Au pays des pingouins, les manchots sont empereurs.
-
[^]Re: Excellent
Posté par Guillaume Knispel () le 29/06/2004 à 23:03. (lien). Évalué à 3.C'est sur qu'en montrant uniquement les bench ou Java est plus rapide les gens vont se mettrent à croire que c'est un mythe de dire que Java rame. J'invite tout le monde à coder une implémentation d'algorithme de hashage (MD5, SHA, à mon avis ils se valent à peu près tous) sous java et d'admirer la vitesse d'execution (en estimant à l'arrache je peux faire 5* plus rapide en utilisant 10* moins de ram en C, et 15* plus rapide en ASM). ATTENTION : je ne dis pas que Java rame tout le temps, simplement ca m'enerve les benchs à 2 balles brandis à tour de bras qui montrent plein de cas favorable à Java, alors que je peux en écrire au moins autant montrant que Java rame énormement. Bref un bench n'est en rien une démonstration, et pire, dire que Java rame ne veut RIEN dire, puisque dans certain cas il se montre étonnement rapide, dans d'autres impitoyablement lent.
D'après mon expérience j'aurais tendance à m'en servir pour coder des serveurs, pas pour faire des calculs.-
[^]Re: Excellent
Posté par 007 () le 30/06/2004 à 02:36. (lien). Évalué à 0.> J'invite tout le monde à coder une implémentation d'algorithme de hashage
Les fonctions de hashage utilisées lors des benchs java sont celle de la VM et elles sont écrites en .... devines .... en C :-)
Si t'as beaucoup de donnée et utilise des fonctions de haut niveau (comme changer lors de tri, fusionner des grosses listes, etc), tu te retrouves à comparer des fonctions de hashage, tri, etc écritent en C. Pas de quoi conclure sur java mais seulement sur la différence d'implémentation des fonctions en C.
Par contre un comparatif java/C avec les fonctions de hackage, tri, etc écritent en java pour java et en C pour C, comme par hazard on en entend pas parler...
Bref, on ne compare pas deux languages mais des implémentations différentes de fonctions écritent en C.
> ATTENTION : je ne dis pas que Java rame
Moi non plus. Chaques technos a ces avantages et défauts.-
[^]Re: Excellent
Posté par ndesmoul () le 30/06/2004 à 09:29. (lien). Évalué à 2.Bah si vous voulez comparer les performances d'une fonction de hachage, comparez une implémentation de SHA-1 (fonction de hachage très utilisée en cryptographie). C'est pas les implémentations qui manquent en Java: Sun en fournit une en standard. Si tu veux une implémentation libre, il y a BouncyCastle qui en fournie dans son provider JCE.
En C/C++, je sais pas trop mais ça doit pas être difficile à trouver.
Je ne présume rien du résultat.
Puisqu'on parle de crypto justement, j'avais comparé les performances de l'exponentielle modulaire (opération très utilisée avec RSA et les schémas basés sur le logarithme discret) entre la bibliothèque mathématique GMP et la classe BigInteger (modPow) de Java (cette classe est sur les JVM récentes entièrement en Java). ... suspens.... Bon pas de miracle, GMP était 3 à 4 fois plus rapide que BigInteger. Faut dire que GMP est en C optimisé avec des morceaux d'assembleur. Tandis que BigInteger est une classe haut niveau qui doit nécessiter pas mal de création d'objets. A mon avis il est possible de faire mieux (mais moins facile d'utilisation).
La comparaison n'est pas tout à fait égale. Il vaudrait mieux comparer avec une bibliothèque 100% en C++. D'autre part sur ce genre d'opération les performances dépendent également énormément de l'algo choisi.
-
-
-
-
[^]Re: Excellent
Posté par Nelis (page perso, ) le 29/06/2004 à 06:21. (lien). Évalué à 2.Pour repondre a ta question :
http://www.roboforge.net(...)
Et si tu vas voir dans la FAQ ( http://www.roboforge.net/info/faq.htm(...) ) tu verras qu'il est bien ecrit en Java3D. ;-)
Cette page a été générée par Templeet en 0.473s (dont 0.0347 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
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.