Pourquoi encore C++ ?

Bonjour,

jeanmarc.vanel@gmail.com a écrit :

Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.

Marginal, c'est discutable. La même chose se fait peut-être en à peu
près le même temps dans les deux langages. Mais C++ permet d'envisager
des méthodes que Java ne permet pas (sans JNI). Et qui peuvent être plus
rapides.
Je suppose que cela arrive souvent en pratique.

Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.

Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?

Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++

C'est tout de même un point qui me semble important !

- 2. les mauvaises performances de nombreuses applications Java

Sur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.

Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.

Et cela pour une raison bien simple: écrire une application Java
utilisable mais peu performante est possible sans cette conscience
claire .
Alors qu'en C/C++ c'est presque impossible.

L'exemple typique d'application où Java n'a pas percé est le
navigateur.

Je pense qu'un avantage légitime de C++, c'est que ce n'est pas un
langage qu'on compile une fois pour le distribuer partout. On a besoin
d'une distribution différente pour chaque plate-forme, et surtout pour
chaque environnement.

Cela implique qu'on peut intégrer un programme C++ à l'OS sur lequel il
fonctionne. On peut faire des mappings fichier/mémoire qu'on utilise
exactement comme prévu par l'OS. On peut se définir comme application
par défaut si l'OS a cette notion. On peut déplacer et copier des
fichiers de façon efficace avec une API directe (il n'y a pas si
longtemps on ne pouvait pas effacer un fichier avec Java.)
On peut accéder à la base de registre, énumérer la liste des disques
durs disponibles et leurs partitions, montées ou pas, si l'OS est
d'accord. Accéder aux APIs de périphériques comme les graveurs DVD,
accéder à la couche USB pour les téléphones portables et webcams.

Au moins quelques-unes de ces capacités finissent par être nécessaires
pour un programme aussi universel qu'un navigateur. Et elles ne sont pas
du tout dans la culture 'build once, run anywhere' de Java, bien que pas
impossible en sachant chercher des bibliothèques JNI et en ajoutant
soi-même ce qui manque.


Ah, et puis de façon plus pragmatique et sans prévoir ce qui sera
possible dans le futur : on ne peut pas toujours exiger la présence ou
l'installation d'une JVM. Mais on peut toujours compter sur un minimum
vital de bibliothèques C/C++ sur un OS précis, et mettre le reste en
bundle plus ou moins caché.


Disclaimer : En revanche, je préfère personnellement utiliser Java quand
c'est possible. Je suis bien plus efficace dans ce langage, j'ai
l'impression qu'il travaille pour moi au lieu du contraire.

--
Mayeul

>> Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.

Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.

Et jusqu'à certains qui croient que le GC est capable de décider ce qui
doit être garbager sans besoin de dé-référencer!
Sur la derniere remarque, chaque JVM ( Sun, IBM,Oracle/BEA, ...) a une
multitutide de parametres qui permettent de gérer la stratégie
d'allocation et garbage. C'est là souvent que ce joue une partie de la
performance de l'application ( l'autre partie étant la (mauvaise)
qualité du code).

jlp wrote:

Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.

Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.

Et jusqu'à certains qui croient que le GC est capable de décider ce qui
doit être garbager sans besoin de dé-référencer!

Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)

Sur la derniere remarque, chaque JVM ( Sun, IBM,Oracle/BEA, ...) a une
multitutide de parametres qui permettent de gérer la stratégie
d'allocation et garbage. C'est là souvent que ce joue une partie de la
performance de l'application ( l'autre partie étant la (mauvaise)
qualité du code).

Mayeul wrote:

Bonjour,

jeanmarc.vanel@gmail.com a écrit :

Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.

Marginal, c'est discutable. La même chose se fait peut-être en à peu
près le même temps dans les deux langages. Mais C++ permet d'envisager
des méthodes que Java ne permet pas (sans JNI). Et qui peuvent être plus
rapides.
Je suppose que cela arrive souvent en pratique.

Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.

Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?

Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++

C'est tout de même un point qui me semble important !

- 2. les mauvaises performances de nombreuses applications Java

Sur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.

Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.

Les deux ou trois premières réponses de
http://www.google.com/search?hl=en&q=site%3Ajava.sun.com+filetype%3Apdf+garbage+collector
donnent des indications intéressantes à ce sujet ;-)

"Garbage collection (GC) is probably the most widely misunderstood
feature of the Java platform. GC is typically advertised as removing all
memory management responsibility from the application developer. This
just isn’t the case."

Jean-Claude Arbaut a écrit :

jlp wrote:

Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.

Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.

Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!

Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)

Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).

jlp a écrit :

Jean-Claude Arbaut a écrit :

jlp wrote:

Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.

Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.

Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!

Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)

Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).

et pour ajouter de la complexité, Java gére 4 niveaux de référence (
Strong, Soft, Weak, Phantom) avec des stratégies de Garbage différentes
pour chaque type de référence. Mais là c'est JVM editer dépendant pour
ces stratégies.

Jean-Claude Arbaut a écrit :

Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)

Oui elle sera éliminée si elle n'est plus accessible depuis nulle part...

Grossièrement le GC effectue un parcours de graphe depuis les objets
persistants (les objets présents sur la pile d'appel ou les references
static). Si ta structure complexe se trouve sur un ilot isolé non
accessible depuis ces objets "persitants" alors elle sera éliminée.

sam.

Le Sun, 23 Nov 2008 19:00:24 +0100, jlp a écrit :

Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!

Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)

Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).

Salut.
Es-tu sur?

C'est l'opposé de la réponse de Samuel Devulder
(<4929ac3a$0$27457$426a34cc@news.free.fr>)

Pour faire plus simple je la cite :

==== Oui elle sera éliminée si elle n'est plus accessible depuis nulle part...

Grossièrement le GC effectue un parcours de graphe depuis les objets
persistants (les objets présents sur la pile d'appel ou les references
static). Si ta structure complexe se trouve sur un ilot isolé non
accessible depuis ces objets "persitants" alors elle sera éliminée.
====
Si tu déréférences un Vecteur par exemple (en supposant que ses
éléments ne soient pas référencés ailleurs), on se retrouve face à
la "structure complexe sur un ilôt isolé" non?

Sinon on va finir par regretter les destructeurs du C++ qui eux sont
appelés à coup sur, contrairement au finalize ;)

Eric.

Eric Razny wrote:

Salut.
Es-tu sur?

C'est l'opposé de la réponse de Samuel Devulder
(<4929ac3a$0$27457$426a34cc@news.free.fr>)

Pour faire plus simple je la cite :

==== > ...
==== >
Si tu déréférences un Vecteur par exemple (en supposant que ses
éléments ne soient pas référencés ailleurs), on se retrouve face à
la "structure complexe sur un ilôt isolé" non?

Sinon on va finir par regretter les destructeurs du C++ qui eux sont
appelés à coup sur, contrairement au finalize ;)

Eric.

Du peu que j'ai retenu de mes lectures des docs de Sun, je pense aussi
que Samuel a raison. En fait je me demandais surtout si ça pouvait aider
le GC (en gros, le faire finir plus vite), de casser les structures.
Je ne sais pas si ça vaut le coup. Quant au finalize, j'avoue que je
ne maîtrise pas encore complètement toutes les étapes du GC en java :-)

Déjà, en faisant des tests un peu "bourrins" (des créations d'objets
en grand nombre, en éliminant les références au fur et à mesure, et on
regarde l'espace libre avant et après un GC), c'est pas très clair, on
a quelques octets qui disparaissent et qui réapparaissent comme par
magie :D

Jean-Claude Arbaut a écrit :

Mayeul wrote:

Bonjour,

jeanmarc.vanel@gmail.com a écrit :

Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.

Marginal, c'est discutable. La même chose se fait peut-être en à peu
près le même temps dans les deux langages. Mais C++ permet d'envisager
des méthodes que Java ne permet pas (sans JNI). Et qui peuvent être
plus rapides.
Je suppose que cela arrive souvent en pratique.

Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.

Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?

Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++

C'est tout de même un point qui me semble important !

- 2. les mauvaises performances de nombreuses applications Java

Sur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.

Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.

Les deux ou trois premières réponses de
http://www.google.com/search?hl=en&q=site%3Ajava.sun.com+filetype%3Apdf+garbage+collector

donnent des indications intéressantes à ce sujet ;-)

Sauf que le premier lien pointe sur un pdf qui date de l'an 2000 !
(Google n'est pas la panacée...)

Il faut plutôt aller voir ici :
http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/
Ca c'est un article intéressant.

"Garbage collection (GC) is probably the most widely misunderstood
feature of the Java platform. GC is typically advertised as removing all
memory management responsibility from the application developer. This
just isn’t the case."

S'il n'y avait qu'en Java que le GC est mal compris. Hélas, la plupart
des développeurs ne possèdent pas la culture nécessaire pour bien
comprendre le GC.
Dans tout bon GC, il y a un mécanisme de "vieillissement" (comme dans
les OS avec machine à segmentation mémoire comme GCOS7 sur le DPS7, par
exemple) un peu semblable à celui expliqué dans la référence que j'ai
donnée plus haut.
Toute explication qui fait abstraction de ce mécanisme est sans intérêt
car celui-ci explique pourquoi il est difficile de comprendre ce que
fait réellement un GC (que ce soit celui de Java ou autre).
Il faut remarquer, en outre, que ce que doit faire réellement le GC de
la JVM ne fait pas parti des spécifications de celle-ci. Chaque JVM fait
donc, en gros, ce qui lui plaît :-)

Pour changer de sujet et revenir au sujet initial de ce fil, la
réputation de mauvaise performance de Java date des implémentations
initiales des JVM. Aujourd'hui, avec les JIT (Just In Time) compiler, il
ne doit pas y avoir de problème sauf que plus de 80% des programmeurs
Java codent comme des pieds (ou avec leurs pieds, au choix). Hélas c'est
aussi vrai (encore plus probablement) pour les programmeurs C++.