Discussion :

[gorgonite]

C'etait juste une remarque humoristique pour répondre au troll de gorgonite.

ce n'était pas un troll, mais les intégristes java ne veulent pas reconnaître que sun s'est jamais foulé côté GC

[pseudocode]

ce n'était pas un troll, mais les intégristes java ne veulent pas reconnaître que sun s'est jamais foulé côté GC

C'est vrai qu'il a fallu attendre le JDK1.2 pour avoir autre chose que l'algo mark-sweep. De la à dire que c'était "minimaliste limite pathétique", ca n'engage que toi.

D'ailleurs je pense que cette technique est toujours employée dans le GC de Boehm (gcj).

[gorgonite]

C'est vrai qu'il a fallu attendre le JDK1.2 pour avoir autre chose que l'algo mark-sweep. De la à dire que c'était "minimaliste limite pathétique", ca n'engage que toi.

c'est la méthode la plus simple qu'on puisse imaginer côté GC, et lorsqu'on compare au GC de .Net ou de OCaml, même la version actuelle de sun est à la traine

[pseudocode]

c'est la méthode la plus simple qu'on puisse imaginer côté GC, et lorsqu'on compare au GC de .Net ou de OCaml, même la version actuelle de sun est à la traine

Oui, surement. D'un autre coté, je ne pense pas que l'algo du GC "seul" explique la difference de performance entre une application Java et C++.

Donc ce n'est peut-etre pas une priorité absolue pour gagner de la perf !

[gorgonite]

Donc ce n'est peut-etre pas une priorité absolue pour gagner de la perf !

en perf pure, pas forcemment, mais pour réduire le coup en mémoire, c'est indispensable

[pseudocode]

en perf pure, pas forcemment, mais pour réduire le coup en mémoire, c'est indispensable

"La mémoire n'est pas un probleme." (c) Microsoft Windows Vista

C'est vrai que toute amélioration de ce coté la est bonne a prendre. Ceci dit Java n'a pas été concu dans un objectif de performance CPU/Mémoire. Pas plus que Basic, ou Prolog, ou PHP, ou...

Pour moi il est clair que C++ est imbattable dans la catégorie "langage objet" pour les projets dont les caracteristiques de performances CPU/Mémoire sont vitales.

Dans les projets que je rencontre, la performance est moins importante que la robustesse, la sécurité, la modularité ou l'évolutivité. La plupart du temps le "client" est près a sacrifier les performances sur l'autel du "vite fait/bien fait pour pas cher". Et dans ces cas la je dis merci a Java, au JDK, a Eclipse et aux librairies de la communauté.

[millie]

Dans les projets que je rencontre, la performance est moins importante que la robustesse, la sécurité, la modularité ou l'évolutivité. La plupart du temps le "client" est près a sacrifier les performances sur l'autel du "vite fait/bien fait pour pas cher". Et dans ces cas la je dis merci a Java, au JDK, a Eclipse et aux librairies de la communauté.

Je ne sais pas trop comment tourner ça, enfin, je vais essayer. J'ai travaillé il y a quelques mois sur une application Java EE assez gourmande en traitement.
Donc, sur la machine de tests, les temps de réponse étaient incroyablement long.
On a ensuite mis l'application en production sous websphere sur un zSeries (mainframes)... Et bien ça déboîtait complètement au niveau temps. Si bien que développer une application en C++ pour avoir des gains de performances auraient été pas du tout utile sur ce coup ci même si les temps de réponse étaient mauvais sur les petits systèmes (à noter que vu la spécificité du java quant au fait qu'il n'y ait pas à recompiler pour un autre système ou à chercher des bibliothèques multiplateformes, a permis de passer en production d'un petit système à un gros système en quelques minutes).

Donc juste pour dire que si les machines peuvent suivre, le gain en temps (niveau développement) que pourrait apporter Java devient pour moi un très gros arguments pour.

Evidemment, si vous êtes spécialiste C++ et que vous développez très bien dans ce langage, cet argument ne tient pas forcement.


Bon, je passerais sous silence qu'il était nécessaire d'avoir une interface web avec un serveur sur un mainframe, ce qui écartait C++

[sinok]

En même temps javaEE est un cas bien particulier, et je doute que le C++ puisse rivaliser de ce coté là, je me vois pas coder un intranet ou un site web en CGI bin et C++ (çà tiendrais plus du cauchemar qu'autre chose...).

De plus d'expèrience, le plus long sur les applis web se trouve avant tout au niveau SGBD où tu passes ton temps à optimiser les procédures stockées ou requêtes.
Ensuite si tu ramène une couche SOA (bref des WebServices à la pelle avec transfos de XML entre deux états), la le serveur d'appli et le serveur physique peuvent amener une grosse différence s'ils sont bien configurés (sinon un WAS peut devenir une véritable usine à Gaz, comme on peut en voir sur les serveurs de dev ou test).


En général c'est plutôt un but un outil. Si on a besoin d'un outil réalisant des algos violents et lourds (genre du simplexe couplé à du knapsack en série pour faire du bin packing), là le C++ n'est pas négociable, même si c'est réalisable en java çà se traine.
Par contre sur des applis moins lourdes niveau ressource j'aurais tendance à me diriger vers java pour les masses de biblios portables, toutes connes et über utiles comme ce que propose Jakarta, la facilité niveau dev qu'il apporte, les outils (Eclipse ou IntelliJ sont tout de même plutôt appréciables comme IDE, et netbeans se met à niveau à l'heure actuelle), la modularité et l'extensibilité de Swing en tant que framework UI (les avantages du lightweight bref...).

[Luc Hermitte]

pour mettre de l'huile sur le feu, voici un lien (en anglais) mettant en évidence quelques défauts du C++ :

Defective C++

Un des rares endroits où le mainteneur de cette liste de défauts ait daigné répondre en public, c'est sur clc++.m. Il y a un très long thread. Certaines de ses objections y sont plus détailées.

[pascal t]

Je tombe tardivement sur le sujet mais j'ai quelques banalités oubliées dans les derniers posts mais qui me semblent importantes :

1/ a partir du moment ou il y a beaucoups d'IO ou d'appels de services externe le language importe peu (sauf si IO mal implementées)

2/ sur une grosse application la préallocation de variables dans des tableaux est toujours un gain de performances quel que soit le langage car réduit fortement la fragmentation, le GC lent ou pas est un avantage car facile d'emploi, je ne vois pas comment il pourrait concurrencer un traitement manuel de la memoire en pure perf.

3/ pour la mise au point et la modification dynamique l'IDE importe plus que le language (par exemple un MSVC permet de la modification de code et recompilation minimale sans requerir un redemarrage du progr)

4/ les librairies standarts ont l'avantage d'etre standart au "package", mais les standarts en ce domaine sont plutot liés a l'activité du "développeur" et celui ci dans le cadre d'une application multiplateforme s'assure toujours en préalable de la disponibilité des librairies requises sur les plateformes cibles, ceci quel que soit le langage.


J'aurais une forte tendance a preferer le C++ dans les appli critiques requierant beaucoups de calcul en temps réel, etant en plus confiant sur l'appui des lib C en complement, voire ASM si la plateforme est garanti famille 8086. Le troll sur la JVM ecrite en C++ n'est pas qu'un troll, mais le besoin de puissance n'est pas toujours reel.


Pour ceux qui pensent le C++ inadapté aux applis serveur WEB il existe des libraires de classes dédiées, j'avais testé ca un moment, mais j'ai généralement plus d'accés BDD que de pur calcul dans mes appli WEB et donc le C++ me semble lourd comparé a un langage interprété, et surtout requierant une team plus "chere" pour la maintenance.

Pour tout autre cadre ou la perf n'est pas critique seule la facilité de maintenance m'importe. Je n'hesite pas a utiliser massivement du PHP meme sur des postes de travail, via shell ou serveur local, car la communauté fourni des outils fantastiques (mais ceci est hors sujet).

Malgré sa syntaxe proche de celle du C++ qui est pour moi un avantage notable, apres avoir aidé au debugging d'une appli java sur Websphere il y a quelques années j'ai gardé des réticences envers la "facilité" de mise au point et la stabilité serveur, surement dépassées.

[Mat.M]

Ce que je cherche a montrer c'est que la jvm progresse serieusement de version en version. Et a partir de la 1.5 je trouve deplacé de considéré java comme lent par rapport au C dans une application complete et pratique. les resultats sont equivalants.

oui c'est tout à fait explicable que C ou Java cela ne change rien parce que de toute façon l'un ou l'autre exploitent et déléguent des traitements à des bibliothèques spécialisées et particulièrement optimisées ( en C/C++ ? )
C'est comme faire une appli C/S avec base de données; développer cela en C++ ne présente pas vraiment grand intérêt parce que de toute façon le moteur de bdd prend en charge les traitements.

[Aminer]

Je pense que c'est une mauvaise chose que de comparer Java au C++ !!!
C++ etant très proche de la machine s'adapte aux solutions avec contraintes sur la vitesse d'execution, Java etant un langage compilé puis interpreté par la JVM s'adapte aux probleme ou la vitesse n'est pas un réel probleme !!!

La programmation etant l'une des dernieres etapes de conception d'un projet, je pense que vous aurez amplement le temps de trouver le langage qui convient au projet, et pourquoi ne pas utiliser une approche hybride JAva/C++ !!

[bountykiler]

Salut à tous.
Juste pour dire que je commence à en avoir assez de lire tous ces posts ou les gens stigmatisent le C++ comme étant seulement un langage plus proche de la machine et donc favorisant les optimisations, et donc les perfs.
Même si cela est vrai, je trouve que c'est réducteur. Il ne faut pas non plus oublier que le C++ va plus loin que java dans certains aspects, tels que la programmation générique par exemple. Maintenant, java a d'autres avantages, comme le fait d'avaoir une introspection plus poussée. Après, à chacun de voir ce qui lui convient le mieux.

[Aminer]

Salut à tous.
Juste pour dire que je commence à en avoir assez de lire tous ces posts ou les gens stigmatisent le C++ comme étant seulement un langage plus proche de la machine et donc favorisant les optimisations, et donc les perfs.
Même si cela est vrai, je trouve que c'est réducteur.

qui a dit SEULEMENT ??? , je connais surement autant que toi les avantage du langages C++, et je n'ai vraiment pas envi de tous les citer, parce que le contexte qui est celui de comparer deux puissants langages de programmation en se basants sur les faiblesses de l'un et mettant en profit les avantages de l'autre ne me convient pas !!

Après, à chacun de voir ce qui lui convient le mieux.

La c'est bien dit

[eclesia]

oui c'est tout à fait explicable que C ou Java cela ne change rien parce que de toute façon l'un ou l'autre exploitent et déléguent des traitements à des bibliothèques spécialisées et particulièrement optimisées ( en C/C++ ? )
C'est comme faire une appli C/S avec base de données; développer cela en C++ ne présente pas vraiment grand intérêt parce que de toute façon le moteur de bdd prend en charge les traitements.

il y en a qui trouve toujours a redire. il y a les fichiers et le reste aussi, la communication avec les clients ...etc... Ok ya bien une base de données en C++ derriere (d'un autre coté je me demande si un prog C peut attaquer une base derby ou javaDB?) mais j'ai bien dit que je voulais montrer un resultat général, par sur un point précis.

[bitbis]

Moi je pense qu'il y a une autre différence assez importante et qui influe de façon importante sur le coût de production.
C'est qu'en c++, il y a beaucoup de libs différence qui font la même chose, avec des conventions de nommage différente et à l'implémentation variable aussi.
Pour s'y retrouver la dedans, il faut d'une part les connaitre trés bien et d'autre part faire énormément de recherche.
Une étude assez récente a montré que environ 70% du temps nécessaire à l'implémentation d'un logiciel était des recherche (grep par exemple).
D'où l'efficacité en gain de temps des environnements de développement du type Eclipse ou Visual C++ par rapport à emacs, VI ou autre éditeur de geek (sans offense).

Les librairies de java par rapport à C++, utilisent pour la plupart les mêmes conventions de nommage et sont trés bien documentés.

Je ne sais pas s'il y a des études qui ont étés faites sur le temps nécéssaire à l'implémentation d'un même code en Java et en C++ mais il y a à mon avis une différence assez conséquente.

Donc en résumé : Java => gain de temps et de compétences pour l'implémentation.

[bitbis]

oui c'est tout à fait explicable que C ou Java cela ne change rien parce que de toute façon l'un ou l'autre exploitent et déléguent des traitements à des bibliothèques spécialisées et particulièrement optimisées ( en C/C++ ? )
C'est comme faire une appli C/S avec base de données; développer cela en C++ ne présente pas vraiment grand intérêt parce que de toute façon le moteur de bdd prend en charge les traitements.

Il y a aussi peu de différences de performances entre des algorithmes entièrement java et des algo entièrement C.
Les JVM sont de plus en plus optimisées. Il y a nottament des systèmes de précompilation (et optimisation pour la machine particulière) de code critiques (codes des boucles par exemple) en code machine (non virtuelle) avant exécution. Cela permet d'avoir des vitesses d'exécution proche des exécutables binaires (.exe) tout en étant multi plateforme (cette compilation est effectuée au moment de l'éxécution par la JVM) tout en ne rajoutant que peu de temps pré éxécution puisque seule une partie du code est recompilé.
De plus ce travail de recompilation est peu couteux car il n'y a pas d'analyse lexicale à faire et le code est déjà dans une représentation facile à utiliser (binaire java .class).

[pascal t]

Il me semble que focaliser sur la performance n'est pas un argument a developper pour "valoriser" le Java.

Une machine virtuelle et un garbage collector garantissent une performance moindre pour le Java, meme si elle est bien meilleure qu'aux debuts des JVM.

Le debat sur les qualités /faiblesses respectives des deux protagonistes merite certainement d'autres approches que la seule restitution de puissance en production.

[FloMo]

Donc en résumé : Java => gain de temps et de compétences pour l'implémentation.

Qt4 : choix du langage ( C++ en natif, bindings en Java, Python ), performances accrues ( cf. Opera, Skype, VLC 0.9.0, KDE 4 ), très bonne documentation d'une API très complète ( http://qt.developpez.com/doc/4.3/index/ ) , portabilité ( Windows jusqu'à Vista, Linux, MacOS, bientôt WinCE ), designer intégré et extensible, open-source, compatible avec les outils classiques ( plugins Eclipse, Visual Studio, KDevelop ).

A noter que Qt 4.4 ( en technical preview ) apportera un outil d'affichage de contenu web compatible avec les standards ( passe l'ACID 2 ), performant et permettant d'interagir avec Qt via le JavaScript ( basé sur WebKit ). De plus, un outil de rendu multimédia sera aussi intégré. Le tout sera en multi-plateformes et disponible pour Avril en version stable.

Un excellent outil étant à la fois simple, efficace et réellement multi-plateformes.

[kpouer]

Il me semble que focaliser sur la performance n'est pas un argument a developper pour "valoriser" le Java.

Une machine virtuelle et un garbage collector garantissent une performance moindre pour le Java, meme si elle est bien meilleure qu'aux debuts des JVM.

Le debat sur les qualités /faiblesses respectives des deux protagonistes merite certainement d'autres approches que la seule restitution de puissance en production.

Bien entendu il n'est pas question d'utiliser l'argument des performances pour valoriser java. Mais il faut reconnaitre que les performances du c++ face au java ne sont plus aussi importantes et que a part dans quelque cas particuliers ce ne seront pas les performances qui feront choisir un langage plutot qu'un autre