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. Java3D est divisé en 4 sous-projets :
- 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.
Aller plus loin
- Java3D sur java.net (53 clics)
- Le message sur la liste (12 clics)
- Looking Glass (7 clics)
- Les screenshots (17 clics)
# Excellent
Posté par Ramso . Évalué à 5.
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 ?
[^] # Re: Excellent
Posté par Anonyme . Évalué à 10.
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 (site web personnel) . Évalué à 8.
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.
[^] # Re: Excellent
Posté par Anonyme . Évalué à 3.
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 dinomasque . Évalué à 4.
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 20 ans !
[^] # Re: Excellent
Posté par ndesmoul . Évalué à 4.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 0.
et un jour j'ai testé un jeu java sous mac os 9 (ui bon c pas x mais bon voila quoi)
et la fluidité!!!
j'aurais dis que c'etait du java!! apres c'etait quelle VM je sais pas trop :(
mais bon c'est juste pour dire que c'est pas java qui est lent mais les vm :)
(c'est un imac 450mhz pour info)
[^] # Re: Excellent
Posté par Bière Drabo . Évalué à 1.
[^] # Re: Excellent
Posté par Jean-Marc Spaggiari . Évalué à -4.
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 . Évalué à 1.
[^] # Re: Excellent
Posté par Stéphane Traumat (site web personnel) . Évalué à 7.
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
http://about.me/straumat
[^] # Re: Excellent
Posté par Fabimaru (site web personnel) . Évalué à 5.
mais coûte moins cher que 10000 barettes de RAM.
[^] # Re: Excellent
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
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.
http://about.me/straumat
[^] # Re: Excellent
Posté par Brice Carpentier . Évalué à 5.
[^] # Re: Excellent
Posté par duf . Évalué à 6.
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 . Évalué à 3.
[^] # Re: Excellent
Posté par snt . Évalué à 7.
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 (site web personnel) . Évalué à 5.
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 (site web personnel) . Évalué à 1.
et je ne pense pas qu'il faile mettre à null une reference quand tu ne l'utilises plus...
http://about.me/straumat
[^] # Re: Excellent
Posté par Nelis (site web personnel) . Évalué à 6.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 2.
> 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 . Évalué à 6.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 2.
cf mon post plus bas ...
[^] # Re: Excellent
Posté par reno . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 1.
[^] # Re: Excellent
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Excellent
Posté par renoo . Évalué à 5.
[^] # Re: Excellent
Posté par Vivi (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
[^] # Re: Excellent
Posté par reno . Évalué à 1.
[^] # Re: Excellent
Posté par Guillaume Knispel . Évalué à 3.
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 . Évalué à 2.
[^] # Re: Excellent
Posté par mdlh . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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.
http://about.me/straumat
[^] # Re: Excellent
Posté par Pothin Alain (site web personnel) . Évalué à 0.
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 (site web personnel) . Évalué à 2.
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.
http://about.me/straumat
[^] # Re: Excellent
Posté par Vivi (site web personnel) . Évalué à -2.
Exact, c'est juste qu'il prend 4 fois plus de mémoire :)
[^] # Re: Excellent
Posté par Stéphane Traumat (site web personnel) . Évalué à -2.
http://about.me/straumat
[^] # Re: Excellent
Posté par boubou (site web personnel) . Évalué à 6.
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 (site web personnel) . Évalué à 4.
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.
http://about.me/straumat
[^] # Re: Excellent
Posté par boubou (site web personnel) . Évalué à -1.
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 (site web personnel) . Évalué à 3.
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.
http://about.me/straumat
[^] # Re: Excellent
Posté par boubou (site web personnel) . É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 (site web personnel) . Évalué à 2.
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 ;)
http://about.me/straumat
[^] # Re: Excellent
Posté par boubou (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 3.
Je m'excuse pour avoir été un peu rude.
http://about.me/straumat
[^] # Re: Excellent
Posté par boubou (site web personnel) . Évalué à 2.
Tout pareil.
[^] # Re: Excellent
Posté par Sylvestre Ledru (site web personnel) . Évalué à 2.
Tu pense a quoi en particulier ?
[^] # Re: Excellent
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: Excellent
Posté par Cook Captain . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 3.
[^] # Re: Excellent
Posté par xsnipe . Évalué à 1.
Désolé si je dis une connerie, mais je voulais savoir...
[^] # Re: Excellent
Posté par Nelis (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 3.
[^] # Re: Excellent
Posté par xsnipe . Évalué à 1.
[^] # Re: Excellent
Posté par Nelis (site web personnel) . Évalué à 2.
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
Posté par renoo . Évalué à 3.
while (it != end) count += *it++;
où it est iterateur sur n'importe quel conteneur de la stl contenant des choses ajoutables.
[^] # Re: Excellent
Posté par xsnipe . Évalué à 1.
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...)...
[^] # Re: Excellent
Posté par boubou (site web personnel) . Évalué à 3.
[^] # Re: Excellent
Posté par Cook Captain . Évalué à 1.
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 (site web personnel) . Évalué à 4.
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 (site web personnel) . Évalué à 2.
- 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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
[^] # Re: Excellent
Posté par mdlh . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 2.
C'est comme je ne vois pas ce que la surcharge des operateurs vient faire la dedans ...
[^] # Re: Excellent
Posté par renoo . Évalué à 2.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 5.
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
http://about.me/straumat
[^] # Re: Excellent
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Java sert dans de nombreuses application généralistes..
http://about.me/straumat
[^] # Re: Excellent
Posté par RuleZ . Évalué à 5.
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 Anonyme . Évalué à 4.
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 . Évalué à 3.
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 Anonyme . Évalué à 4.
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 (site web personnel) . Évalué à 3.
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 Anonyme . Évalué à 4.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 2.
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 Anonyme . Évalué à 2.
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 (site web personnel) . Évalué à 1.
[^] # Re: Excellent
Posté par Anonyme . Évalué à 2.
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 . Évalué à -3.
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 (site web personnel) . Évalué à 2.
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" !!!!!
http://about.me/straumat
[^] # Re: Excellent
Posté par 007 . Évalué à -1.
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 (site web personnel) . Évalué à 2.
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
http://about.me/straumat
[^] # Re: Excellent
Posté par 007 . Évalué à -1.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 0.
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 (site web personnel) . Évalué à 3.
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 . Évalué à -2.
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 (site web personnel) . Évalué à 2.
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 . Évalué à -1.
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 . Évalué à 3.
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 . Évalué à -1.
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 (site web personnel) . Évalué à 2.
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 . Évalué à -2.
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 (site web personnel) . Évalué à 5.
[^] # Re: Excellent
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
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 :)
http://about.me/straumat
[^] # Re: Excellent
Posté par 007 . Évalué à -2.
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 Anonyme . Évalué à 2.
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 . Évalué à 0.
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 . Évalué à 3.
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
Posté par Anonyme . Évalué à 2.
Comme d'hab quoi ;)
[^] # Re: Excellent
Posté par Anonyme . Évalué à 2.
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 . Évalué à 0.
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 Anonyme . Évalué à 3.
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 . Évalué à -1.
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 (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Excellent
Posté par 007 . Évalué à 0.
Les tests sont indispensables et c'est un "art". Les mailings de developpement sont pleins d'exemples de la difficulter de faire des bons tests pour tracker un bug obscur.
[^] # Re: Excellent
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
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 . Évalué à 0.
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 Anonyme . Évalué à 2.
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 . Évalué à 0.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 0.
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 . Évalué à 2.
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 . Évalué à 0.
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 0.
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 (site web personnel) . Évalué à 1.
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.
[^] # Re: Excellent
Posté par 007 . Évalué à 0.
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 . Évalué à 3.
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 . Évalué à 0.
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 Anonyme . Évalué à 2.
Parce qu'il faudrait une machine virtuelle pour faire fonctionner cette machine viruelle ecrite en Java.
[^] # Re: Excellent
Posté par 007 . Évalué à 0.
[^] # Re: Excellent
Posté par allcolor (site web personnel) . Évalué à 1.
Une jvm en java qui se bootstrap sans jvm additionnel : http://www-124.ibm.com/developerworks/oss/jikesrvm/(...)
[^] # Re: Excellent
Posté par Anonyme . Évalué à 2.
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 . Évalué à -1.
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 . Évalué à 0.
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 . Évalué à 0.
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 . Évalué à 3.
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 . Évalué à -3.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 0.
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 (site web personnel) . Évalué à 0.
Quel est le véritable avantage?
[^] # Re: Excellent
Posté par Guillaume Knispel . Évalué à 3.
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 . Évalué à 0.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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. ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.