Le code de Java3D est disponible

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
28
juin
2004
Java
Dans un message sur la liste de diffusion de Java3D, Sun a annoncé la disponibilité du code source de Java3D sur son site communautaire java.net. Ce n'est certes pas encore le passage de Java dans le monde du libre mais c'est un pas de plus dans le bon sens.

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

  • # Excellent

    Posté par  . Évalué à 5.

    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 ?
    • [^] # Re: Excellent

      Posté par  . Évalué à 10.

      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  (site web personnel) . É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.
        • [^] # Re: Excellent

          Posté par  . É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  . É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 20 ans !

            • [^] # Re: Excellent

              Posté par  . É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.
            • [^] # Pour information...

              Posté par  . É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  . É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  (site web personnel) . Évalué à 0.

              J'pensais ça comme tout le monde (et je le penses encore un peu)
              et un jour j'ai testé un jeu java sous mac os 9 (ui bon c pas x mais bon voila quoi)
              et la fluidité!!!
              j'aurais dis que c'etait du java!! apres c'etait quelle VM je sais pas trop :(
              mais bon c'est juste pour dire que c'est pas java qui est lent mais les vm :)
              (c'est un imac 450mhz pour info)
      • [^] # Re: Excellent

        Posté par  . É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  . É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  . É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  (site web personnel) . É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

              http://about.me/straumat

              • [^] # Re: Excellent

                Posté par  (site web personnel) . É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.
                • [^] # Re: Excellent

                  Posté par  (site web personnel) . É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.

                  http://about.me/straumat

                  • [^] # Re: Excellent

                    Posté par  . É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 :)
                  • [^] # Re: Excellent

                    Posté par  . É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  . É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  . É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  (site web personnel) . É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  (site web personnel) . É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...

                            http://about.me/straumat

                            • [^] # Re: Excellent

                              Posté par  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  . É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  . Évalué à 2.

                              non c'est faux pour le coup d'assigner des null,

                              cf mon post plus bas ...
                            • [^] # Re: Excellent

                              Posté par  . É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  (site web personnel) . É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  . É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...
                        • [^] # Re: Excellent

                          Posté par  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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.

                      http://about.me/straumat

                      • [^] # Re: Excellent

                        Posté par  (site web personnel) . É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  (site web personnel) . É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.

                          http://about.me/straumat

              • [^] # Re: Excellent

                Posté par  (site web personnel) . É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  (site web personnel) . Évalué à -2.

                  eheh commentaire gratuit sans justifications :)

                  http://about.me/straumat

                  • [^] # Re: Excellent

                    Posté par  (site web personnel) . É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  (site web personnel) . É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.

                      http://about.me/straumat

                      • [^] # Re: Excellent

                        Posté par  (site web personnel) . É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  (site web personnel) . É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.

                          http://about.me/straumat

                          • [^] # Re: Excellent

                            Posté par  (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  (site web personnel) . É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 ;)

                              http://about.me/straumat

                              • [^] # Re: Excellent

                                Posté par  (site web personnel) . É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  (site web personnel) . É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.

                                  http://about.me/straumat

                                • [^] # Re: Excellent

                                  Posté par  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  . É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...
                                          • [^] # Re: Excellent

                                            Posté par  (site web personnel) . É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  (site web personnel) . É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  . Évalué à 1.

                                              Dans ce cas là je suis d'accord peut-être mais dans le cas d'un objet fait par nos petits soins ??
                                              • [^] # Re: Excellent

                                                Posté par  (site web personnel) . É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

                                                  Posté par  . Évalué à 3.

                                                  Avec les iterateurs en c++, ca permet de faire des trucs style au look "C" (concis mais par forcement lisible).

                                                  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  . É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...)...
                                                  • [^] # Re: Excellent

                                                    Posté par  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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

                  http://about.me/straumat

        • [^] # Re: Excellent

          Posté par  (site web personnel) . Évalué à 3.

          Pkoi pas ?

          Java sert dans de nombreuses application généralistes..

          http://about.me/straumat

        • [^] # Re: Excellent

          Posté par  . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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" !!!!!

          http://about.me/straumat

          • [^] # Re: Excellent

            Posté par  . É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  (site web personnel) . É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

              http://about.me/straumat

              • [^] # Re: Excellent

                Posté par  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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 :)

                  http://about.me/straumat

                  • [^] # Re: Excellent

                    Posté par  . É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  . É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  . É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  . É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

                        Posté par  . Évalué à 2.

                        Ce thread était globalement interessant, toi tu arrives et en 3 heures tu pourris le machin ...
                        Comme d'hab quoi ;)
                    • [^] # Re: Excellent

                      Posté par  . É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  . É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  . É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  . É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  (site web personnel) . Évalué à 1.

                          Sans tests unitaires, je sais pas comment tu fais.... ca me parait impossible.

                          http://about.me/straumat

                          • [^] # Re: Excellent

                            Posté par  . Évalué à 0.

                            Je fais des tests unitaires. Faut pas rêver.
                            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  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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.
                    • [^] # Re: Excellent

                      Posté par  . É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  . É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  . É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  . É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

                Posté par  . Évalué à 0.

                Tu as raison, j'ai mal lu :-(
              • [^] # Re: Excellent

                Posté par  (site web personnel) . É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/(...)
                • [^] # Re: Excellent

                  Posté par  . É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  . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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?
      • [^] # Re: Excellent

        Posté par  . É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  . É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  . É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  (site web personnel) . É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. ;-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.