[Débat] C++ vs Java

Citation:

---

Envoyé par kpouer

Ben je vais essayer de faire un exemple java :
class A
{
void tutu() {...}

void tata() {...}
}

On aura donc 2 liens de la classe A vers ses méthodes, donc 2 x 32 bits

---

Dans un objet de la classe tu auras (vraissemblablement, il y a d'autres techniques possibles) un pointeur vers une table contenant 2 pointeurs.

Citation:

---

class B extends A
{
// on surcharge tutu()
void tutu() {...}
}

---

Dans un objet de classe B tu auras un pointeur vers une table contenant 2 pointeurs, un vers B::tutu, un vers A::tata.

En C++ on a deux types de fonctions membres, les fonctions membres virtuelles -- qui ont une entrée dans la table -- et les fonctions membres non virtuelles -- qui n'en ont pas. Si une classe n'a pas de fonctions membres virtuelles, elle n'a pas non plus de pointeur vers cette table (qui serait vide). Ce pointeur a un cout qui est particulièrement sensible pour de petits objets. Comme exemple tu as un point en 3 dimentions, un autre exemple où ça coute proportionellement beaucoup sont les wrappers (pour lesquelles Java double la mémoire nécessaire).

Citation:

---

Envoyé par Jean-Marc.Bourguet

Dans un objet de la classe tu auras (vraissemblablement, il y a d'autres techniques possibles) un pointeur vers une table contenant 2 pointeurs.



Dans un objet de classe B tu auras un pointeur vers une table contenant 2 pointeurs, un vers B::tutu, un vers A::tata.

En C++ on a deux types de fonctions membres, les fonctions membres virtuelles -- qui ont une entrée dans la table -- et les fonctions membres non virtuelles -- qui n'en ont pas. Si une classe n'a pas de fonctions membres virtuelles, elle n'a pas non plus de pointeur vers cette table (qui serait vide). Ce pointeur a un cout qui est particulièrement sensible pour de petits objets. Comme exemple tu as un point en 3 dimentions, un autre exemple où ça coute proportionellement beaucoup sont les wrappers (pour lesquelles Java double la mémoire nécessaire).

---

Eh bien même dans le cas que tu donnes, ca ne concerne que les objets et non leurs instances non ? Donc je ne vois pas en quoi la mémoire serait tellement affectée par cette histoire de méthodes virtuelles puisque c'est pas multiplié par le nombre d'instances.
Par contre effectivement les wrappers occupent plus de mémoire que le type primitif associé (ce qui est bien logique :) et il vaut mieux éviter leur utilisation tant qu'on peut.

Citation:

---

Envoyé par kpouer

Eh bien même dans le cas que tu donnes, ca ne concerne que les objets et non leurs instances non ? Donc je ne vois pas en quoi la mémoire serait tellement affectée par cette histoire de méthodes virtuelles puisque c'est pas multiplié par le nombre d'instances.

---

tu veux sans doute faire la distinction entre classe et instance :roll:


l'utilisation d'une table virtuelle oblige à stocker un tableau de pointeurs de fonctions par classe, et à effectuer une double indirection pour appeler la méthode...


nb: en Java, c'est double indirection n'est effectuée qu'une seule fois car le bytecode est réécrit à la volée au moment du premier appel afin de mettre directement l'adresse de la méthode appelée... ce qui accélerera le second appel ;)

Citation:

---

Envoyé par Razgriz

Une des principales faiblesses du Java est de sa récursivité assez faible, compte tenu qu'on travaille sur la JVM, et le fait que quoiqu'on en dise, ce n'est pas si portable que ça. Essyez un peu de développer une belle GUI sous Windows, elle est super, vous la lancez sous Linux elle s'exécute toujours mais
les espacements, tailles des composants ont varié, du coup si votre fenêtre ne peut être agrandie, c'est pas top. Ce n'est qu'un exemple parmi d'autres similaires, ça s'exécute, mais c'est moins bien...

---

:applo:
et après on va nous dire que Java et autre c'est portable...

Et moi je me pose des questions : en programmation Windows lorsqu'on fait un clic souris c'est un message système qui est envoyé à l'application.
Bien ; avec Linux cela doit être similaire ( un peu comme Qt qui gère les signaux )
Comment cela est-il géré en interne via la JVM pour une appli Java ? :roll:

Citation:

---

Envoyé par epsilon68

JVM client 30 secondes
JVM server 22 secondes
C++ 13 secondes

---

Ok même une applet Java peut parfois être plus rapide que C++
:D
Et as-tu fait des tests avec une interface graphique ? :roll: :mrgreen:

Citation:

---

Envoyé par Mat.M

Et as-tu fait des tests avec une interface graphique ?

---

non, j'avais fait un renderer tres simple en Java (une lumiere, remplissage des faces avec z-buffer) mais c'etait lent. Je voulais faire le meme truc en C++ mais j'ai pas eu le courage, je ne peux donc rien dire.

Citation:

---

Envoyé par epsilon68

JVM client 30 secondes
JVM server 22 secondes
C++ 13 secondes

---

Par curiosité (je sais je suis trop curieux :aie:) : quel est le domaine du test ??

Citation:

---

Envoyé par Mat.M

:applo:
et après on va nous dire que Java et autre c'est portable...

---

Heu... la taille des composants ne doit pas être géré manuellement ! C'est une règle des développements de GUI portable...
Le problème peut se retrouver aussi sous Windows avec des thèmes ou des polices différentes...

En utilisant un layout on évite ce genre de problème !


a++

Citation:

---

Envoyé par kpouer

Eh bien même dans le cas que tu donnes, ca ne concerne que les objets et non leurs instances non ?

---

J'ai un probleme de terminologie ici. Dans ce contexte, objet et instance me semblait plus ou moins interchangeable. En tout cas, je n'ai jamais vu parler de l'instance d'un objet.

Pour reexpliquer la chose de maniere plus fondamentale plutot qu'en utilisant une des techniques utilisees. Si on veut de la surcharge determinee dynamiquement (alias dynamic dispatch, ce qui se passe pour les membres virtuels en C++, pour toutes les methodes en Java) il faut que les objets -- ou les instances -- comportent une indication de leur type dynamique. En C++ seules les instances de classes ayant des membres derives ont une telle indication. En Java les instances de toutes les classes doivent avoir cette indication. Et elle prend de la place.

Citation:

---

Envoyé par Jean-Marc.Bourguet

J'ai un probleme de terminologie ici. Dans ce contexte, objet et instance me semblait plus ou moins interchangeable. En tout cas, je n'ai jamais vu parler de l'instance d'un objet.

Pour reexpliquer la chose de maniere plus fondamentale plutot qu'en utilisant une des techniques utilisees. Si on veut de la surcharge determinee dynamiquement (alias dynamic dispatch, ce qui se passe pour les membres virtuels en C++, pour toutes les methodes en Java) il faut que les objets -- ou les instances -- comportent une indication de leur type dynamique. En C++ seules les instances de classes ayant des membres derives ont une telle indication. En Java les instances de toutes les classes doivent avoir cette indication. Et elle prend de la place.

---

Oui je me suis mal exprimé quand j'ai dit objet je pensais "Class".
Donc ce que je veux dire c'est que l'histoire des liens vers les méthodes ne concernent que les class et non leurs instances. Donc oui même en admettant que ces liens prennent de la place ca devrait être assez faible car la class n'est chargée qu'une seule fois quelque soit le nombre d'instances. Et puis si on a vraiment envi de faire des économies on déclare la méthode final.
On peut faire un calcul vite fait. Si un projet utilise 2000 classes, 100 méthodes chacunes (de belles classes hein :), Ben 4 octets par lien ca fait moins de 800 ko, s'ils sont a double sens ca reste moins de 2 Mo, c'est donc pas un argument très crédible contre Java selon moi

Citation:

---

Envoyé par kpouer

On peut faire un calcul vite fait. Si un projet utilise 2000 classes, 100 méthodes chacunes (de belles classes hein :), Ben 4 octets par lien ca fait moins de 800 ko, s'ils sont a double sens ca reste moins de 2 Mo, c'est donc pas un argument très crédible contre Java selon moi

---

dommage pour le calcul, mais il faut regarder de plus près comment est implémentée la réprésentation d'une classe dans la jvm...

la vtable est un tableau d'une structure particulilère contenant de nombreuses informations en plus du simple pointeur de fonctions ;)

du style :
+ pointeur vers la classe à laquelle la méthode appartient
+ flags pour les accès
+ nombre d'arguments
+ pointeur vers une fonction native ou une structure représentant la méthode

etc.

je ne rentrerai pas dans les détails... mais il ne faut pas oublier que les méthodes java doivent aussi être accessibles par introspection et invocation dynamique ;)

Citation:

---

Envoyé par kpouer

On peut faire un calcul vite fait. Si un projet utilise 2000 classes, 100 méthodes chacunes (de belles classes hein :), Ben 4 octets par lien ca fait moins de 800 ko, s'ils sont a double sens ca reste moins de 2 Mo, c'est donc pas un argument très crédible contre Java selon moi

---

Ca dépend de ta cible... mais le problème est le même sous Java que sous C++, si ce n'est qu'en Java il faut explicitement indiqué que la méthode n'est pas virtual avec le mot-clef final :

Lorsqu'en C++ on a ceci :

Code:

---

1 2 3 4 5 6 7 8

// Méthode non virtuelle void method() { ... }   // Méthode virtuelle : virtual void method() { ... }   // Méthode virtuelle pure : virtual void method() = 0;

---

L'équivalent Java est :

Code:

---

1 2 3 4 5 6 7 8

// Méthode non virtuelle public final void method() { ... }   // Méthode virtuelle : public void method() { ... }   // Méthode virtuelle pure : public abstract void method();

---

C'est juste l'approche de la POO qui n'est pas la même, mais on peut faire la même chose...

a++

Citation:

---

Envoyé par adiGuba

Ca dépend de ta cible... mais le problème est le même sous Java que sous C++, si ce n'est qu'en Java il faut explicitement indiqué que la méthode n'est pas virtual avec le mot-clef final

---

Je ne connais pas grand chose a Java, mais il me semblait que le seul effet formel de final sur les methodes etait d'empecher qu'elles soient supplantees (overwritten, je ne connais pas la terminologie francophone utilisee en Java). Elles se comportent donc toujours comme des fonctions virtuelles du C++.

Citation:

---

Envoyé par gorgonite

dommage pour le calcul, mais il faut regarder de plus près comment est implémentée la réprésentation d'une classe dans la jvm...

la vtable est un tableau d'une structure particulilère contenant de nombreuses informations en plus du simple pointeur de fonctions ;)

du style :
+ pointeur vers la classe à laquelle la méthode appartient
+ flags pour les accès
+ nombre d'arguments
+ pointeur vers une fonction native ou une structure représentant la méthode

etc.

je ne rentrerai pas dans les détails... mais il ne faut pas oublier que les méthodes java doivent aussi être accessibles par introspection et invocation dynamique ;)

---

Ca d'accord mais par exemple le nombre d'arguments n'est stocké qu'une fois par méthode, même si la méthode se trouve dans plusieurs classes donc ca ne change pas grand chose.
La question au départ c'était de dire que si on instantie un objet Tutu, comme il hérite obligatoirement de Object, ca lui ajoute des tas de méthodes inutiles et que donc ca prend des ressources. Le fait est que ces ressources supplémentaires sont négligeables car elles ne sont prises qu'une fois par la JVM et non pour chaque instance.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je ne connais pas grand chose a Java, mais il me semblait que le seul effet formel de final sur les methodes etait d'empecher qu'elles soient supplantees (overwritten, je ne connais pas la terminologie francophone utilisee en Java).

---

Oui (perso je j'utilise plutôt "redéfinir" mais on se comprend c'est le principal ;)).

Citation:

---

Envoyé par Jean-Marc.Bourguet

Elles se comportent donc toujours comme des fonctions virtuelles du C++.

---

C'est vrai au niveau du bytecode, mais sauf erreur cela ne l'est plus lors de l'exécution puisque les méthodes final peuvent être "inliné" ;)

A noter que la JVM peut d'ailleurs traiter une méthode virtuelle (non-final) comme une méthode non-virtuelle (final) si elle n'a pas été redéfinie (overwritten ;)) dans d'autres classes...

a++

Citation:

---

Envoyé par kpouer

Ca d'accord mais par exemple le nombre d'arguments n'est stocké qu'une fois par méthode, même si la méthode se trouve dans plusieurs classes donc ca ne change pas grand chose.

---

ces infos sont stockées au niveau de la classe où est déclarée cette méthode bien sur... après la vtable fait les indirections ;)

Citation:

---

Envoyé par kpouer

La question au départ c'était de dire que si on instantie un objet Tutu, comme il hérite obligatoirement de Object, ca lui ajoute des tas de méthodes inutiles et que donc ca prend des ressources. Le fait est que ces ressources supplémentaires sont négligeables car elles ne sont prises qu'une fois par la JVM et non pour chaque instance.

---

on n'est pas en SmallTalk, donc ce n'est pas faux... mais il faut signaler qu'ajouter ce genre de petites tables à chaque classe peut, malgré le chargement paresseux, engendrer une surcharge de l'occupation mémoire "virtuelle" (je ne parle pas de ce que fait le GC) qui n'aurait pas lieu en C++
la question est aussi de savoir si ce problème est vraiment critique... et c'est d'autant moins vrai que les classes sont complexes (avec plein de gros attributs non statiques), car chaque instance va se mettre à couter beaucoup, ce qui relativisera le cout de la classe ;)

Citation:

---

Envoyé par kpouer

La question au départ c'était de dire que si on instantie un objet Tutu, comme il hérite obligatoirement de Object, ca lui ajoute des tas de méthodes inutiles et que donc ca prend des ressources.

---

Ca ne lui ajoute pas un tas, ca ajoute une marque de type qui fait 4 bytes (et est generalement un pointeur vers une description plus detaillee du type, y compris des pointeurs vers les methodes). Ce marqueur a un cout en espace proportionnellement d'autant plus important que la classe est petite. Ce marqueur n'est la en C++ que si la classe a des membres virtuels.

Citation:

---

Envoyé par adiGuba

C'est vrai au niveau du bytecode, mais sauf erreur cela ne l'est plus lors de l'exécution puisque les méthodes final peuvent être "inliné" ;)

---

le mot inliné n'est pas approprié... l'utilisation de l'inlining dépend beaucoup de la méthode :P

comme je l'ai signalé plus haut, c'est plutot cela qui est effectué... et même sur les méthodes "virtuelles" (nb: je peux l'affirmer, je bosse sur le code d'une jvm sun ;))

Citation:

---

Envoyé par gorgonite

nb: en Java, c'est double indirection n'est effectuée qu'une seule fois car le bytecode est réécrit à la volée au moment du premier appel afin de mettre directement l'adresse de la méthode appelée... ce qui accélerera le second appel

---

Citation:

---

Envoyé par kpouer

La question au départ c'était de dire que si on instantie un objet Tutu, comme il hérite obligatoirement de Object, ca lui ajoute des tas de méthodes inutiles et que donc ca prend des ressources. Le fait est que ces ressources supplémentaires sont négligeables car elles ne sont prises qu'une fois par la JVM et non pour chaque instance.

---

comme l'a dit jean marc, le fait d'avoir des methode virtuelles ajoute 1 pointeur par Instance vers le "descripteur" de classe. ce n'est pas grand chose, mais lorsque les données de l'objet ne font que quelques octets, le surcout n'est pas négligeable. L'aventage de C++ dans ce domaine est qu'on peut très bien se passer de ce surcout en n'ayant pas de fonction virtuelle, ce qui n'est pas possible en Java.
de plus, je me demande bien quelle est la taille d'un Object en memoire... toute nos classe heritant de celle ci, si elle a le moindre attribut, on se le recupere sans forcement le vouloir :?

Citation:

---

Envoyé par bafman

comme l'a dit jean marc, le fait d'avoir des methode virtuelles ajoute 1 pointeur par Instance vers le "descripteur" de classe. ce n'est pas grand chose, mais lorsque les données de l'objet ne font que quelques octets, le surcout n'est pas négligeable. L'aventage de C++ dans ce domaine est qu'on peut très bien se passer de ce surcout en n'ayant pas de fonction virtuelle, ce qui n'est pas possible en Java.
de plus, je me demande bien quelle est la taille d'un Object en memoire... toute nos classe heritant de celle ci, si elle a le moindre attribut, on se le recupere sans forcement le vouloir :?

---

Ca me parrait logique remarque, faut bien que l'instance sache de quoi elle est une instance. Par contre on ne duplique pas la définition de la classe.
La taille d'un Object je sais pas, mais il n'a aucun champ d'instance donc ne devrait pas induire d'occupation mémoire supplémentaire du fait qu'on hérite de lui.

Citation:

---

Envoyé par bafman

de plus, je me demande bien quelle est la taille d'un Object en memoire... toute nos classe heritant de celle ci, si elle a le moindre attribut, on se le recupere sans forcement le vouloir :?

---

un attribut non statique... ;)

suffit de vérifier... :P
http://java.sun.com/j2se/1.5.0/docs/...ng/Object.html

Citation:

---

Envoyé par gorgonite

le mot inliné n'est pas approprié... l'utilisation de l'inlining dépend beaucoup de la méthode :P

---

J'ai bien dit que les méthodes "pouvait" être "inliné" ;)
Après cela dépend aussi d'autre critère (comme la taille de la méthode, etc.)

Citation:

---

Envoyé par Jean-Marc.Bourguet

Ce marqueur a un cout en espace proportionnellement d'autant plus important que la classe est petite. Ce marqueur n'est la en C++ que si la classe a des membres virtuels.

---

Tout à fait d'accord sur ce point (bien que j'ignorais cette possibilité du C++). Il est clair que le C/C++ apporte de plus grande possibilité dans la gestion de la mémoire (personne n'a dit le contraire ;)).

a++