Journal Java et C++

Posté par  .
Étiquettes : aucune
0
16
juin
2004
Les benchs du "Great Computer Language Shootout"
remis à jour avec les implémentations récentes du Jdk.

Notez bien qu'il s'agit de micro benchmarks, qui en soi
ne permettent pas de dire que X est plus rapide que Y,
la performance d'un programme est globale ...

Néanmoins je vous soumet ce lien car moi aussi j'en
ai marre d'entendre répeter encore et encore que java est lent ...

L'article
http://www.sys-con.com/story/?storyid=45250(...)

La news originelle sur /.
http://developers.slashdot.org/developers/04/06/15/217239.shtml?tid(...)


[i][ Ndm: il serait souhaitable de ne pas partir en gros troll velu java c'est pas libre ca sux ][/i]
  • # mouaich.

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

    Me fait bien rire ton journal, tu dis de ne pas partir en troll sur javacapucpaslibre (de toute façon c'est pas un troll c'est un fait) et tu nous propose un troll encore plus velu : "Java c'est rapide comparé à C++" avec un autre troll derrière : "les benchs me servent d'arguments" alors que tu le dis toi même celà ne permet pas de mesurer les perfs globales...

    Enfin les benchs entre langages me feront toujours rires, ce qui changent ce n'est pas la vitesse d'exécution (de toute façon à l'arrivée c'est toujours du code machine qui s'exécute), c'est les possibilités du langages qui font la différence, et forcer de reconnaître que Java a une syntaxe plus agréable que C++, une portabilité plus aisée, sans doute une meilleure productivité, mais que question tuning tu pourras TOUJOURS faire mieux en C++ et que il restera toujours des trucs impossible à faire en Java. Et puis bon les libs du JDK sont pas codés en Java hein ;)
    • [^] # Re: mouaich.

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

      Il a pas dit "Java c'est rapide comparé à C++", il a juste dit, regarder à l'execution de certains tests précis les deux sont comparables. Il en a juste marre d'entendre à tous les coups dès qu'on parle de Java "C'est lent, c'est pas portable, c'est pas libre, ..."
      • [^] # Re: mouaich.

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

        * Java n'est pas libre.

        * Java n'est pas plus portable que C++ (je peux écrire du code portable en C++ standard, il faut simplement recompiler, tout comme je dois changer de JVM,quand je change d'achitecture).

        Ces deux points sont incontestables, désolé.
        • [^] # Re: mouaich.

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

          je peux écrire du code portable en C++ standard, il faut simplement recompiler, tout comme je dois changer de JVM,quand je change d'achitecture

          mmmmh... si tu es a la recherche d'un code performant, rien qu'avec les différences entre les compilateurs, tu vas devoir modifier ton source de toute facon... alors la portabilité du C++, tres moyen ! A la rigueur l'argument est recevable pour le plain C. Mais reste le pb des dépendances avec des libs qui ne sont peut etre pas dispo sur toutes les plateformes, etc...

          Sur ce point de la portabilité, et pour avoir essayer les 2, y'a pas photo, java n'est peut etre pas libre (histoire de temps ?), mais il est beaucoup plus facile a porter !!

          Aurel, qui ne portera jamais qqchose en C++ sur IA64 par exemple, alors que la JVM pour IA64 et hop ! le code marche ! :D
          • [^] # Re: mouaich.

            Posté par  . Évalué à -1.

            mmmmh... si tu es a la recherche d'un code performant, rien qu'avec les différences entre les compilateurs, tu vas devoir modifier ton source de toute facon... alors la portabilité du C++, tres moyen !

            Ca s'appelle les #ifdef OSLINUX, etc... et c'est utilisé de partout.
            • [^] # Re: mouaich.

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

              C'est probablement ce que le monsieur essaie de t'expliquer. Pour avoir du code "portable" en C ou C++ il faut faire du code différent en fonction des plate-formes à coups de #ifdef. Quand tu montes dans l'abstraction des langages (Java ou Perl par exemple) tu te rends compte qu'il y a de moins en moins besoin de ce genre de choses, c'est pourquoi on parle de code "portable" en lui-même.
              • [^] # Re: mouaich.

                Posté par  . Évalué à 1.

                C'est la bibliothèque utilisée qui est pas portable alors, pas C ou C++.
                Il suffit alors de bien choisir ses bibliothèques. WxWidgets, Boost, etc.
        • [^] # Re: mouaich.

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

          * Java n'est pas libre.

          Non mais il est ouvert. Il est géré par le JCP et non par Sun et les sources sont disponibles pour lecture, c'est déjà pas mal. Par contre, beaucoup de logiciels libres sont écrit en Java et je trouve toujours insultant pour leurs auteurs quand ces logiciels se font accueillir par des "Java ça pue c'est pas libre"

          * Java n'est pas plus portable que C++ (je peux écrire du code portable en C++ standard, il faut simplement recompiler, tout comme je dois changer de JVM,quand je change d'achitecture).

          En Java, tu ne dois pas recompiler le code. Tu as un binaire, ce même binaire tournera sur la JVM A et sur la JVM B tant que ces JVM implémentent les spécifications. La portabilité binaire et source, c'est quand même pas la même chose quoi que t'en dise.
          • [^] # Re: mouaich.

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

            La portabilité binaire et source, c'est quand même pas la même chose quoi que t'en dise.

            Je dirais même plus, java à la portabilité binaire et source, alors que c++ n'a la portabilité que par source.
          • [^] # Re: mouaich.

            Posté par  . Évalué à 1.

            En Java, tu ne dois pas recompiler le code. Tu as un binaire, ce même binaire tournera sur la JVM A et sur la JVM B tant que ces JVM implémentent les spécifications.

            Manque de bol, Java en change comme de chemise. Les bytecode en version n ne fonctionnent plus avec les versions n-1. Il faut recompiler, comme en C++.

            La portabilité binaire et source, c'est quand même pas la même chose quoi que t'en dise.

            C'est surtout intéressant pour les logiciels propriétaires.
            • [^] # Re: mouaich.

              Posté par  . Évalué à 4.

              Je ne vois pas pourquoi il faut recompiler ???

              Logiquement, je fais un programme java dans la version 1.1 de la JDK. Ce programme marchera tel quel si je le lance avec un JDK supérieur (compatibilité descendante).

              En gros ce que tu dis c'est que si tu fais un programme avec le JDK 1.4, il ne marchera pas avec le JDK 1.1 ! Ben oui, c'est vrai mais je ne vois pas le problème, je ne connais AUCUN langage qui permet de tenir une compatibilté descendante ET montante (pour rappel, le fait de changer de version c'est pas juste pour faire jolie mais pour apporter des améliorations dans les langages). A moins d'utiliser IPOT je ne vois comment on pourrait deviner à l'avance les spécifications des JDK futurs.

              Je ne parle même pas de compatibilité des binaires C++ et C avec toutes les dépendances (compilateur, système, noyau, libc, librairie supplémentaires ...).
              • [^] # Re: mouaich.

                Posté par  . Évalué à 1.

                C'est pas pire que d'autres langages mais c'est pas mieux, à cause de ce problème.

                La compatibilité binaire C++ arrive, c'est récent. Par contre pour le C, rien à envier à Java. C'est d'ailleurs ce qui fait que certains sont réticents pour passer de C à C++.
    • [^] # Re: mouaich.

      Posté par  . Évalué à 3.

      Ok je précise :)

      Je ne dis pas que java est plus rapide que C++, le journal est titré "java et c++", c'est le titre de l'article qui pose la question de savoir si java *serait* plus rapide par rapport au C++.

      Je souhaite juste porter l'attention de certains sur le java que l'addage
      souvent répeté ici "java est lent" n'a plus vraimment de signification de nos jours. Si ca peut aider certains a reconsiderer leurs préjugés c'est tant mieux.

      De toute façon comme je l'ai indiqué, comparer les performances
      de deux langages à l'aide de micro bench c'est peu significatif.

      Tout simplement par ce que si tu lances un profiler sur un programme, les portions le ralentissant seront seront dues à un défaut de conception, un mauvaise architecture logicielle, et pas à la vitesse d'éxecution d'une boucle for. ( néanmoins pour un programme ayant une architecture "idéale" ça impacterait les performances, d'ou la possibilité en java de faire des appels de code natifs pour des algos critiques ).


      Ps: les librairies du Jdk sont codées en java avec des appels Jni natifs dedans bien évidemment.
      • [^] # Re: mouaich.

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

        On est bien d'accord, les benchs n'ont pas beaucoup d'intérêt, sauf à trouver des gros défaut dans l'implémentation de certains API (genre quand ca va 100 fois moins vite sur une plateforme, faut se poser des questions sur l'implémentation).

        Ce qui fait la réputation de "Java c'est lent" c'est surtout les différences de perfs entre Java sous Windows et Java sous Linux, et évidemment le fait que Java bouffe de la RAM, ce qui ne change rien quand on en a assez, mais qui bien sûr font chutter les perfs dès qu'on n'a plus ce qu'il faut...

        "Ps: les librairies du Jdk sont codées en java avec des appels Jni natifs dedans bien évidemment."
        Donc bien évidemment, les libs sont implémentées en C++, et que implicitement on peut obtenir des perfs exactement identiques entre C++ et Java, comme quoi ce n'est pas le langage qui fait la différence mais bien l'implentation...

        (d'ailleur une question qui tue : on dit implémentation ou inplentation ? Les 2 sont-ils français ?)
      • [^] # Re: mouaich.

        Posté par  . Évalué à 2.

        Globalement, à l'utilisation, Java reste plus lent. Si on prend des cas d'école, on pourra faire tourner un code plus vite sous Java que C++ (surtout avec un peu de mauvaise foi, si on n'optimise pas autant C++ que Java).

        Ceci dit Java n'est pas excessivement lent. Ca reste toujours le démarrage de la JVM qui se ressent, ou des parties lourdes de la bibliothèque comme Swing. Ca peut donc etre acceptable.

        Le seul problème est que en génral pour rendre Java plus rapide il faut vraiment etre un expert, connaitre les bons trucs, quasiment savoir ce que fait la bibliothèque (pas seulement l'interface, un peu l'implémentation aussi). Ca nécessiterait donc un très long apprentissage, et à ce moment là l'avantage par rapport à C++ (qui lui en nécessite vraiment un, très payant d'ailleurs) diminue.

        Bref les principaux critères restent la conception, les algorithmes et la connaissance du langage, sa bonne utilisation.
        • [^] # Re: mouaich.

          Posté par  . Évalué à 4.

          Je suis d'accord avec toi ... mais le premier avantage de Java par rapport à C++ et on oublie souvent de le dire c'est sa relative (par rapport à C++) simplicité d'utilisation pour un débutant.

          Premièrement, à l'exécution les segfaults sont très rares (à vrai dire, j'en ai vu qu'une fois dans un pb de partage de données entre 300 Threads), on préfére les IndexOutOfBoundException, IOException ... C'est plus parlant surtout quand on commence à développer et qu'on se gourre tout le temps dans les comptages d'index.

          Deuxièmement, on évite l'arithmétique des pointeurs et la gestion des allocations dynamiques (je n'ai jamais aimé passé 2 minutes à eplucher un 'man' pour savoir si le char* passé en paramètres devait être alloué par moi, par la méthode ou tout simplement se trouvait en champ static).

          Après, un développeur débutant en Java fera surement du code aussi grade qu'un développeur C++, voir plus s'il n'a jamais fait de langage objets avant. Mais ça n'a rien a voir, on devient bon développeur en développant quelque soit le langage. Avant qu'un développeur Java puisse utiliser tous les frameworks (Struts, J2EE ...) et pattern (Observer, MVC, Singleton ...) intélligement il faut un certain temps de programmation 'je réinvente la roue'.

          Pour finir, je dirais que Java n'est pas le langage ultime, mais il faut bien reconnaître que de la même manière que C++ et SmallTalk en leurs époques, il a permis de franchir un nouveau cap dans l'abstraction du développement.
          • [^] # Re: mouaich.

            Posté par  . Évalué à 1.

            Je suis d'accord avec toi ... mais le premier avantage de Java par rapport à C++ et on oublie souvent de le dire c'est sa relative (par rapport à C++) simplicité d'utilisation pour un débutant.

            Pour le débutant (typiquement, le stagiaire), je suis d'accord. Mais l'informatique n'est pas faite que par des stagiaires ou des non informaticiens.

            Premièrement, à l'exécution les segfaults sont très rares (à vrai dire, j'en ai vu qu'une fois dans un pb de partage de données entre 300 Threads), on préfére les IndexOutOfBoundException, IOException ... C'est plus parlant surtout quand on commence à développer et qu'on se gourre tout le temps dans les comptages d'index.

            Tu es libre d'utiliser un bon système de gestion d'erreur en C++. Mais c'est vrai que c'est un point fort de Java.

            Deuxièmement, on évite l'arithmétique des pointeurs et la gestion des allocations dynamiques (je n'ai jamais aimé passé 2 minutes à eplucher un 'man' pour savoir si le char* passé en paramètres devait être alloué par moi, par la méthode ou tout simplement se trouvait en champ static).

            Je crois que tu as de sérieuses lacunes ou que tu parles de C et non de C++ si tu te consacres autant à ces problèmes. En C++ on évite l'allocation dynamique "à la main" (on prend des conteneurs, le cas échéant on les fabrique et alors tout est bien encapsulé), on ne fait pas d'arithmétique de pointeurs sauf cas exceptionnels (a priori inutile) et on n'utilise pas de char* mais des std::string ou std::vector, leur caractère const et "passé en référence" suffisant à tout connaitre.

            Le C++ (et non le C avec une vague connaissance des classes C++ par dessus) est parfois bien plus simple que Java. Car il faut distinguer : simple à apprendre (Java) et simple à utiliser (C++, après un apprentissage un peu plus difficile que Java).

            Pour finir, je dirais que Java n'est pas le langage ultime, mais il faut bien reconnaître que de la même manière que C++ et SmallTalk en leurs époques, il a permis de franchir un nouveau cap dans l'abstraction du développement.

            C++ a quasiment toutes ces facilités de Java, il permettait déjà cette abstraction. Java est juste plus orienté là dedans, donc plus simple à apprendre et propose une bibliothèque standard plus large (bien qu'ayant des lacunes sur les conteneurs, ça doit être corrigé maintenant avec les génériques).
  • # java c'est pas libre ca sux

    Posté par  . Évalué à 1.

    vive C# et Mono !

    histoire d'orienter le troll : il y a des comparatifs de perf récents entre Mono/dotNet ? et entre Mono/Java ? et entre dotNet/Java ?
    • [^] # Re: java c'est pas libre ca sux

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

      Questions perfs, c'est toujours pareil, il y a tellement de facteurs qu'il est bien difficile de faire des comparaisons...
      Une chose est sûre : Mono est plus lent que .NET (quoique certains trucs vont plus vite)

      Entre .NET et Java, forcement, Microsoft annonce des perfs bien supérieures, mais là encore tout dépend de l'utilisation, et comme d'hab, il est bien impossible de comparer des applications réelles... Mais on peut facilement imaginer que une bonne conception de l'application cachera les différences de rapidité...

      Une autre chose est sûre : ce qui fait la supériorité de Mono/.NET sur Java, c'est les possibilité techniques (genre c'est pas demain la veille qu'on verra QuakeII sur Java) et le respect des standards, mais là on s'éloigne du troll original...
      • [^] # Re: java c'est pas libre ca sux

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

        Explique moi pourquoi on ne verrait pas de Quake 2 sur Java???

        Avec Java3D qui est un "bindings" de Opengl, je ne vois pas ou est le problème...

        Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

        • [^] # Re: java c'est pas libre ca sux

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

          Parcque .NET/Mono supporte entre autre la notion de pointeurs et permet donc d'utiliser ou de porter du code écrit en C comme c'est le cas pour Quake2 (il reste tout de même quelques adaptations à effectuer sur le code)... Si tu veux le faire en Java, ben, tu recodes tout...
  • # explications ?

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

    Je ne pige pas comment un language intérprété peut être plus rapide qu'un language compilé (genre en "method call", c'est assez impressionnant).
    Le language interprété doit faire la même chose que le language compilé, mais avec une couche de plus, nan (genre la jvm est une sorte de processeur tournant sur un autre proc) ?
    Ou alors c'est gcc qui est mauvais, mais ça m'étonnerait (d'après les benchs contre d'autres compilateurs, il est parfois un peu plus lent, mais pas des masses).
    Dernière possibilité : ce sont des benchs sur des applications élémentaires. Peut-être qu'en augmentant la taille de l'application, on verait la balance pencher dans l'autre sens.
    (mon but n'est pas de détruire Java, mais de comprendre. Or instinctivement, je suis amené à penser que compilé est plsur apide qu'interprété...)
    • [^] # Re: explications ?

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Ou alors c'est gcc qui est mauvais, mais ça m'étonnerait (d'après les benchs contre d'autres compilateurs, il est parfois un peu plus lent, mais pas des masses).

      Il y a aussi des cas ou le binaire généré par GCC est 2x plus lent sur des G5 que celui généré par XLF (code fortran, CHARMM pour ne pas le nommer), et là, ca fait mal !
    • [^] # Re: explications ?

      Posté par  . Évalué à 2.

      « Je ne pige pas comment un language intérprété peut être plus rapide qu'un language compilé »

      Il me semble que le java est compilé "just-in-time" c'est à dire entre le chargement et l'execution... pourtant ça reste plus rapide que du c++ même en prenant en compte le temps d'initialisation... Effectivement, il semblerait qu'un troll vienne de mourir... paix à son âme...
    • [^] # Re: explications ?

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

      Gcc est mauvais en C++ (il n'est bon qu'en C sur x86, à ce que je sais) (on peut disclaimer que c'est quand même compliqué de bien optimiser le C++) et la JVM optimise "on the fly" quand elle exécute, ce qui lui permet d'être souvent plus lente au démarrage mais parfois plus rapide au cours de l'exécution.
      • [^] # Re: explications ?

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

        C'est pas de l'optimisation "on the fly" c'est de la compilation "on the fly". En gros la JVM passe une partie du code en code natif histoire d'améliorer les perfs.
    • [^] # Re: explications ?

      Posté par  . Évalué à 3.

      Il y a une explication simple, la gestion de la memoire. Si les allocations /desallocations sont fait n'importe comment, le systeme peut perdre une partie impressionnante de son temps dans ce genre de chose stupide. Surtout que face au GC de Java, c'est vraiment la premiere difference. D'apres les commentaires de Slashdot, ca serait la source des differences.

      Pour exemple, j'ai avec un copain code un petit logiciel, on perdait 93% de notre temps a faire des allocations memoires. Apres avoir definit une politique plus judicieuse de la memoire, cette phase est devenu negligeable. Donc si on fait des benchs C++ vs Java redefinir les operateurs new et delete pour obtenir les meme comportement en C++ qu'en Java me parait un minimum pour faire une comparaison objective...
    • [^] # Re: explications ?

      Posté par  . Évalué à 2.

      Il y a aussi une autre explication : la jvm peut dans certains cas decider d'inliner certains appels. Ce qui fait qu'il n'y a plus d'appels de methodes.
      En c++, si tu ne compiles pas avec f-inline et si tu ne proposes pas au compilo d'inliner certaines methodes (via le mot clef inline), il ne le fera pas.

      Bref, plus je lis et relis ce bench, plus je suis d'accord avec certains commentaires sur slashdot : il ne compare pas la meme chose.
      • [^] # Re: explications ?

        Posté par  . Évalué à 1.

        De nos jours les optimiseurs ont au contraire tendance à inliner ou non selon leurs heuristiques et de moins en moins en fonction de ce qu'indique le code. Pour rappel, le inline de C++ est indicatif : le compilateur n'est pas obligé de le suivre, et il peut inliner même sans ce mot clé.
  • # Java est une usine à gaz...

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

    C'est un bench foireux. Il semblerait que le temps de démarrage de la JVM ne soit même pas pris en compte...

    On peut aussi faire un autre bench : la mémoire utilisée. Et là, désolé mais C++ est très largement devant.

    Java est une usine à gaz.

    Ce n'est pas un troll, c'est la réalité.
    Je défie quiconque de me prouver le contraire...
    • [^] # Re: Java est une usine à gaz...

      Posté par  . Évalué à 2.

      Extrait de l'article

      >> JVM startup time was included in these results. "That means even
      >> with JVM startup time, Java is still faster than C++ in many of
      >> these tests," says Lea.
      • [^] # Re: Java est une usine à gaz...

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

        Hé hé, merci le cache, hein !
        Pour bein faire, il faudrait rebooter la machine à chaque fois.

        Je réitère : c'est un test bidon ! :-)
        • [^] # Re: Java est une usine à gaz...

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

          Pourquoi, tu rebootes ta machine entre le lancement de plusieurs applications ? Faut pas te raccrocher à tout prix à cet argument, ils incluent le startup time donc tu as tort sur ce point ; ton OS cache les accès disques, c'est tout, à chaque langage/compilateur/application d'en tenir compte.

          On peut trouver pas mal d'autres points qui font que javasux (mais sûrement encore plus qui font que c++sux alors ça va).
    • [^] # Re: Java est une usine à gaz...

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

      On peut aussi faire un autre bench : la mémoire utilisée. Et là, désolé mais C++ est très largement devant.

      while (! memoryleaks ) :)
      • [^] # Re: Java est une usine à gaz...

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

        Quelqu'un qui programme mal en C++ ne programmera pas mieux en Java (pas des memory leaks (quoique...) mais d'autres problèmes).
        • [^] # Re: Java est une usine à gaz...

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

          L'effet global sera meilleur car Java est bien plus un langage pour neuneux que C++ : le programmeur a moins de libertés et la JVM fait plus de choses à sa place ; je pense donc qu'un mauvais programmeur fera de "moins mauvais" programmes en Java qu'en C++ (à moins que tu me veuilles citer les "autres problèmes" dont tu parles, et qu'ils soient totalement inacceptables par rapport à des pointeurs fantômes qui font planter aléatoirement une application à des milliers de lignes de code de l'origine du problème, mais je n'en connais personnellement pas).
    • [^] # Re: Java est une usine à gaz...

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

      Java est une usine à gaz.

      Plus que le langage, c'est l'habileté et l'expérience du programmeur, dans le choix du design, dans l'implémentation, puis dans le profiling, qui font qu'un code sera rapide ou pas.
  • # Java et C++

    Posté par  . Évalué à 2.

    Le temps de chargement de la machine virtuelle java est long ! la mémoire utilisée est importante !

    Peut-être qu'une fois chargée, une application java peut avoir des performances comparables à d'autres languages.... mais pas avec la même utilisation mémoire et pas pour des applications graphiques avec swing !

    Un simple petit script qui lance 10 fois helloWorld en parrallèle (HelloWorld qui attend que return soit pressé pour se terminer) devrait mettre en évidence ces problèmes...

    Ensuite, sur un pintel 6600Ghz 3gb ram ou un pintel II 100Mhz, 128mb ram, je pense que c'est encore plus flagrant...

    Note: j'avais vu des benchmarks gcj (http://gcc.gnu.org/java/(...) qui compile du java en natif): des fois les gains de performance sont important, des fois on est plus lent qu'avec la jvm. dans tous les cas, la mémoire utilisée est moins importante.

    Est-ce que quelqu'un a des expériences avec gcj ?
    • [^] # Re: Java et C++

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      j'avais fait quelque test, je n'avais pas poussé car je n'avais pas vu de différence de vitesse significative avec le bytecode+jvm... :(
  • # Bref..

    Posté par  . Évalué à 1.

    Outre ces tests peu significatif, je trouve que c'est le débat qu'il engendre qui montre bien que finalement, personne n'est capable à 100% de montrer que Java est plus ou moins lent qu'un autre langage, ou encore qu'il soit plus ou moins mauvais..
    Personne n'ici n'est capable d'apporter un réel argument sans mauvaise fois ou qui ne soit irréprochable, et les autres ne sont pas capables d'encaisser les quelques critiques réalistes et parfois si insignifiantes..
    Ceci est valable pour les "pro-Java" et les "pro-C++"..

    Sur ce je vous laisse troller de bon coeur..
  • # Ce benchmark compare du Java à du C++ mais...

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

    Au delà du résultat, que je trouve contestable, il est plus important de voir pourquoi ce benchmark ne peut être pris en considération lorsqu'on souhaite comparer Java et C en termes de perfs.

    En résumant, j'estime que l'auteur compare du Java avec du très mauvais code C. Je ne sais pas quel est le niveau du codeur C/C++ derrière ces petits benchs, mais force est de constater qu'il n'a aucun bon sens, tant en terme de gestion de mémoire que de performances. Un comble lorsqu'on tente de comparer les performances de deux langages.

    Je prend pour exemple le code du fichier matrix.cpp. Pour moi, codeur C depuis déjà quelques années, quand on me dit d'allouer une matrice, j'alloue directement un bloc de sizeof(element)*n*m, mais je n'alloue pas un tableau de pointeurs pour ensuite allouer chaque ligne separement, et ce pour deux raisons:
    - c'est sous efficace en terme d'espace memoire (le surcout de n pointeurs) et c'est un surcout en terme d'appels à malloc.
    - accéder à un élément devient couteux, car il y a deja une indirection memoire pour acceder a l'adresse de la ligne.
    (- le traitement sequentiel des elements est non optimal a cause de la rupture en fin de chaque ligne)

    Peut être le codeur cherchait à avoir un code syntaxiquement proche (eg: m[i][j] au lieu d'un m[i*n+j]).

    D'ailleurs je doute que le new int[n][m] corresponde au code C proposé, je parierai bien 0.3€ que la JVM alloue n*m*sizeof(int), et l'operateur d'acces mat[i][j] n'est qu'une vue de l'esprit, et est traduit dans un bytecode proche de mat[n*i+j].

    J'invite tout le monde a se pencher sur le code pour comprendre que ce benchmark n'est tout simplement pas crédible. Le code C/C++ ne correspond pas du tout à ce qu'un codeur C/C++ typique aurait écrit, il resemble plus à une transcription litérale de la version Java. Et donc, ce bench compare Java, avec du C++ qui se prend pour du Java (mais sans jamais faire l'effort de simuler une gestion memoire equivalente, cad ne pas detruire les objets a chaque boucle mais le recycler comme le ferait le GC de la JVM, ou encore anticiper sur le compilateur pour ecrire du code efficace et simple, étape accomplie par le bytecode->code machine du JIT)

    J'utilise Java tous les jours au boulot et j'en suis satisafait, je ne crache donc pas du tout sur Java. Par contre je crache sur ce benchmark qui compare des carrotes et des choux... oui c'est pas pareil, et on est bien incapable de conclure que les choux sont meilleurs que les carrotes.
    • [^] # Re: Ce benchmark compare du Java à du C++ mais...

      Posté par  . Évalué à 2.

      D'autant plus que le gas fait + [i][k] * [k][j] dans les boucle interne, avec une imbrication en i, j, k, ce qui est une horreur innomable en terme de gestion du cache. Il fait la même chose en java, mais comme la jvm est capable de faire des choses Chamanique en runtime a ce qu'il parrait... (et ptet que le compilo java est plus performant). En plus en java les latence d'acces de la ram doivent surrement etre masqué par le code de la JVM tandis qu'en C++ c'est masqué par des...NOP !
    • [^] # Re: Ce benchmark compare du Java à du C++ mais...

      Posté par  . Évalué à 3.

      Il ne faut peut être pas exagérer non plus... on peut effectivement trouver quelques trucs à redire sur le code qui a été écrit dans certains cas, mais de là à invalider tous les résultats, c'est un peu gros... Par exemble, le test de fibonacci est (pour moi) écrit tout a fait normalement dans les deux langages, ben le java l'emporte haut la main!

      Évidement on va pas conclure que le java est 1.356 fois plus rapide que le c++ d'après ce benchmark, mais par contre je suis impressionné par la progression faite par le java qui, d'un point vu vitesse (pour la mémoire c'est pas encore ça), équivaut a peu près au C/C++, alors qu'il présente beaucoup de fonctionalités plus confortables pour le développeur.

      Il faut aussi voir que ce benchmark ne fait aucun test sur l'interface graphique où java ne doit pas être très brillant...
    • [^] # Re: Ce benchmark compare du Java à du C++ mais...

      Posté par  . Évalué à 1.

      > j'estime que l'auteur compare du Java avec du très mauvais code C.

      On trouve souvent ce défaut à propos de Python : on compare un bon programmeur Python à un mauvais programmeur C++ par exemple.

      Ce que je dis n'est pas du tout anti-Python : ce langage a ses qualités indéniables, mais les comparaisons devraient se faire avec des programmeurs de compétence équivalente dans leurs langages respectifs. Et ensuite on peut remarquer qu'avoir un bon niveau en C++ demande un apprentissage bien plus long. Mais le minimum est de comparer des codes dans lesquels on tire le meilleur du langage.
  • # Saint Thomas

    Posté par  . Évalué à 4.

    Bon ben moi j'y croyais un peu à moitié donc j'ai refait les tests, et voilà les résultats pour :
    java 1.4.2
    java 1.4.2 -server
    java 1.5 beta
    java 1.5 beta -server
    g++ -03 -march athlon-xp

    Les résultats sont globalement identiques, un peu plus en faveur du C++ quand même que les tests de l'autre gars. On remarque que pour des données ou un nombre d'itération petits, le C++ fait un bien meilleur score à cause du temps d'init de java ; pour diminuer l'importance de ce temps il suffit d'augmenter le temps d'execution, mais le problème est que lorsqu'on choisi certaines valeurs, java plante à cause du manque de mémoire, là où le C++ passe les doigts dans le nez!
    Sinon j'ai pris -O3 comme optimisation pour gcc à la place de -O2, qui est meilleur contrairement à ce que dit le gars.

    Enfin bon ça ne change par grand chose à la conclusion : java est globalement aussi rapide que le C++ (pour moi ça remet pas mal de choses en cause...)


    ---- ackermann 11 ----
    4.35user 0.01system 0:04.45elapsed 98%CPU
    0.96user 0.01system 0:01.52elapsed 63%CPU
    4.12user 0.01system 0:05.02elapsed 82%CPU
    0.98user 0.01system 0:01.08elapsed 91%CPU
    1.17user 0.00system 0:01.21elapsed 96%CPU
    ---- fibo 45 ----
    21.15user 0.00system 0:21.32elapsed 99%CPU
    16.00user 0.00system 0:16.15elapsed 99%CPU
    27.49user 0.01system 0:27.69elapsed 99%CPU
    16.35user 0.01system 0:16.48elapsed 99%CPU
    24.44user 0.00system 0:24.62elapsed 99%CPU
    ---- hash 500000 ----
    4.48user 0.09system 0:04.70elapsed 97%CPU
    4.08user 0.09system 0:04.34elapsed 96%CPU
    4.08user 0.09system 0:04.47elapsed 93%CPU
    3.64user 0.08system 0:03.94elapsed 94%CPU
    1.84user 0.04system 0:01.91elapsed 98%CPU
    ---- hash2 3000 ----
    11.78user 0.01system 0:11.93elapsed 98%CPU
    8.94user 0.01system 0:09.07elapsed 98%CPU
    11.96user 0.01system 0:12.12elapsed 98%CPU
    10.08user 0.00system 0:10.22elapsed 98%CPU
    17.10user 0.00system 0:17.21elapsed 99%CPU
    ---- heapsort 5000000 ----
    8.10user 0.05system 0:08.33elapsed 97%CPU
    8.78user 0.05system 0:08.93elapsed 98%CPU
    8.21user 0.06system 0:08.53elapsed 96%CPU
    8.26user 0.05system 0:08.48elapsed 98%CPU
    9.73user 0.02system 0:09.83elapsed 99%CPU
    ---- matrix 100000 ----
    27.74user 0.00system 0:27.97elapsed 99%CPU
    21.13user 0.01system 0:21.29elapsed 99%CPU
    29.22user 0.01system 0:29.46elapsed 99%CPU
    21.32user 0.01system 0:21.52elapsed 99%CPU
    12.01user 0.00system 0:12.13elapsed 99%CPU
    ---- methcall 1000000000 ----
    20.19user 0.00system 0:20.38elapsed 99%CPU
    2.49user 0.00system 0:02.54elapsed 98%CPU
    18.53user 0.01system 0:18.69elapsed 99%CPU
    2.58user 0.01system 0:02.63elapsed 98%CPU
    12.88user 0.00system 0:12.97elapsed 99%CPU
    ---- nestedloop 45 ----
    25.00user 0.01system 0:25.27elapsed 98%CPU
    20.41user 0.01system 0:20.61elapsed 99%CPU
    25.91user 0.01system 0:26.16elapsed 99%CPU
    20.53user 0.01system 0:20.72elapsed 99%CPU
    10.78user 0.00system 0:10.88elapsed 99%CPU
    ---- objinst 100000000 ----
    9.33user 0.33system 0:09.79elapsed 98%CPU
    9.20user 0.32system 0:09.62elapsed 99%CPU
    10.21user 0.40system 0:10.70elapsed 99%CPU
    9.86user 0.41system 0:10.38elapsed 98%CPU
    23.24user 0.00system 0:23.40elapsed 99%CPU
    ---- random 300000000 ----
    34.56user 0.00system 0:34.82elapsed 99%CPU
    21.29user 0.00system 0:21.49elapsed 99%CPU
    37.71user 0.01system 0:38.03elapsed 99%CPU
    25.23user 0.01system 0:25.45elapsed 99%CPU
    4.41user 0.00system 0:04.47elapsed 98%CPU
    ---- sieve 100000 ----
    13.49user 0.01system 0:13.63elapsed 99%CPU
    12.21user 0.00system 0:12.30elapsed 99%CPU
    14.94user 0.01system 0:15.07elapsed 99%CPU
    9.75user 0.01system 0:09.89elapsed 98%CPU
    10.56user 0.00system 0:10.65elapsed 99%CPU
    ---- strcat 1000000 ----
    0.48user 0.03system 0:00.63elapsed 82%CPU
    0.49user 0.02system 0:00.58elapsed 88%CPU
    0.41user 0.04system 0:00.52elapsed 86%CPU
    0.45user 0.04system 0:00.55elapsed 88%CPU
    0.11user 0.01system 0:00.16elapsed 78%CPU
    ---- sumcol ( < fichier 243 Mo) ----
    19.66user 0.64system 0:20.66elapsed 98%CPU
    13.18user 0.61system 0:13.94elapsed 98%CPU
    19.68user 0.65system 0:20.52elapsed 99%CPU
    10.58user 0.62system 0:11.32elapsed 98%CPU
    15.24user 0.45system 0:15.83elapsed 99%CPU
    ---- wc ( < fichier 265 Mo) ----
    4.46user 0.58system 0:08.57elapsed 58%CPU
    4.30user 0.59system 0:08.46elapsed 57%CPU
    6.08user 0.41system 0:09.96elapsed 65%CPU
    3.81user 0.55system 0:08.73elapsed 49%CPU
    2.20user 0.49system 0:02.80elapsed 96%CPU
    • [^] # Re: Saint Thomas

      Posté par  . Évalué à 4.

      Regarde le code C++.
      Tout ce que ce benchmark prouve, c'est que ce gars a bien raison de développer en Java.

Suivre le flux des commentaires

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