Discussion :

[TabrisLeFol]

Bonjour,
Je dispose d'une fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void iterativelyCalled(MyType t) {//blabla}

En supposant que je dispose également d'une

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Collection<MyType> c

Je dois donc afin d'utiliser ma fonction sul l'ensemble des elements de celle-ci utiliser un iterateur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Iterator<MyType> it = c.iterator();
while(it.hasNext()) iterativelyCalled(it.next());

L'optimisation possible est d'utiliser l'inlining, cependant ne pouvant le forcer en Java, on doit soit faire un copier coller soit esperer ou etre sur qu'il se produira.
Ma question est :
* dans le cas de l'exemple iteratif, la jvm peut elle utiliser l'inlining.
* si on bouge ce code dans la classe possedant la methode en creant une methode intermediaire, void iterativelyCalled(Collection<MyType> c) augmente t on les chances d'avoir un inlining?
J'imagine qu'une reponse peut se trouver dans les descriptions techniques des jvm mais pour l'instant je n'ai pas trouvé...

Je pose cette question dans le cadre d'une Iteration avec un iterateur mais le problème est le même quelque soit le type de boucle. (for ou for each par exemple)

[adiGuba]

Salut,

* dans le cas de l'exemple iteratif, la jvm peut elle utiliser l'inlining.

Oui... et elle peut même mettre 'inline' des méthodes qui ne devrait pas l'être...

La JVM prend en compte l'inlining selon plusieurs critère (taille de la méthode, pas d'effet de bord, etc.). J'étais tombé sur une doc la dessus mais je ne l'ai plus sous la main... Si je la retrouve...


La JVM 'server' doit surement mettre plus de méthode 'inline' (cf le test 3 de ce sujet : La machine virtuelle Java est-elle vraiment lente ?).

* si on bouge ce code dans la classe possedant la methode en creant une methode intermediaire, void iterativelyCalled(Collection<MyType> c) augmente t on les chances d'avoir un inlining?

Je ne pense pas... et je ne comprend pas trop l'intérêt de passer par une méthode intermédiaire...

A la rigueur tu pourrais mettre ta méthode en final pour améliorer ses chances d'être inline...

a++

[TabrisLeFol]

Entendu.
En ce qui concerne la methode intermediaire, de une elle evite de repeter des iterations si j'utilise beaucoup de collection externe à cette classe (c'est de l'optimisation de code mais pas de performance effectivement), et de deux, je pensais qu'étant apellée plus souvent elle aurait theoriquement plus de chance d'etre inline. Mais bon ce raisonnement doit etre bien pauvre par raport à la logique mise en place pour réaliser le choix des fonctions inline. (Que je connais mais que dans les très grandes lignes.)

Pour le mot clef final, j'ai lu effecivement quelque part que certains l'utilisaient dans cet objectif mais j'ai lu aussi que cela n'avait plus d'influence sur les dernières jvms.... Cependant, j'ai pris aussi l'habitude de mettre final presque partout ou je pouvais... (Oui, aussi les variables (paramètres, attributs, ou locales) et les classes...).

[adiGuba]

Entendu.
En ce qui concerne la methode intermediaire, de une elle evite de repeter des iterations si j'utilise beaucoup de collection externe à cette classe (c'est de l'optimisation de code mais pas de performance effectivement),

Sur ce point on est d'accord

et de deux, je pensais qu'étant apellée plus souvent elle aurait theoriquement plus de chance d'etre inline. Mais bon ce raisonnement doit etre bien pauvre par raport à la logique mise en place pour réaliser le choix des fonctions inline. (Que je connais mais que dans les très grandes lignes.)

Mais ta méthode intermédiare n'influe pas sur le nombre de fois où la méthode est appellé...

Pour le mot clef final, j'ai lu effecivement quelque part que certains l'utilisaient dans cet objectif mais j'ai lu aussi que cela n'avait plus d'influence sur les dernières jvms....

En fait dans les première versions de Java c'était le compilateur qui s'occupait des méthodes inlines. Et du coups le mot-clef final est une des principales conditions pour que la méthode soit inline (si la méthode n'est pas final l'appel pourrait être fait sur une classe fille qui redéfinit la méthode...)

Mais désormais c'est la JVM qui s'occupe de cela et elle détermine selon le contexte d'exécution si elle peut mettre la méthode inline ou pas...

Cependant, j'ai pris aussi l'habitude de mettre final presque partout ou je pouvais... (Oui, aussi les variables (paramètres, attributs, ou locales) et les classes...).

Attention à ce que cela ne dérange pas ton modèle objet !
Il ne faut pas tout mettre en final pour espérer des optimisations, mais selon tes besoins (une méthode final est une méthode qui ne doit pas être redéfini dans les classes filles, une classe final ne peut pas être hérité, un attribut final ne peux pas être modifié,etc...).

Par contre pour les paramètres je n'y vois aucun inconviénient (je trouve même que cela aurait du être l'état par défaut).

a++

PS : quel type d'application tu developpes ? La JVM server serait peut-être un bon choix...

[TabrisLeFol]

Je connais les signification du mot clef final mais il est vrai qu'en ce qui concerne les fonctions et les classes, bien que connaissant sa signification, je ne sais pas trop ce qu'il convient de faire. Ce que font la majorité est de mettre final que quand on est certain que l'on veut cette fonctionalité mais d'autres estiment qu'il ne faut permettre d'etendre que quand on le souhaite et que donc final devrait etre un choix par defaut. Developpant de petites applications pour moi, je ne pense pas que quelqu'un sous-classe mes interfaces, classes, l'un ou l'autre ne me pose pas de grand probleme étant donné que je sais toujours en avance les heritages que je souhaite utiliser...

L'application que je "developpe", en fait pour l'instant je cherche surtout comment l'organiser, s'apparente à l' OrganicBuilder Mais je souhaite l'optimiser pour des calculs plus lourds (plus d'atomes, plus de règles, plus vite) et aussi produire un code bien documenté et organisé. Le fait de l'organiser en applet peut peut-etre reduire les performances (je n'ai aucune idée sur la question) mais le logiciel étant aussi à but didactique, cette forme est bien adaptée.

Etant donné que tu connais les "generiques", je pourrais te demander ton avis sur ceci?

[adiGuba]

Salut,

Ce que font la majorité est de mettre final que quand on est certain que l'on veut cette fonctionalité mais d'autres estiment qu'il ne faut permettre d'etendre que quand on le souhaite et que donc final devrait etre un choix par defaut.

C'est la différence entre le C++ et Java !
En C++ toutes les méthodes sont finales et il faut utiliser le mot-clef virtual pour pouvoir les redéfinir dans les classes filles.
En Java toutes les méthodes sont virtuelles et il faut utiliser le mot-clef final pour empêcher les classes filles de les redéfinir.

Developpant de petites applications pour moi, je ne pense pas que quelqu'un sous-classe mes interfaces, classes, l'un ou l'autre ne me pose pas de grand probleme étant donné que je sais toujours en avance les heritages que je souhaite utiliser...

Oui mais cela peut te déranger pour de future évolution... On est d'accord que sur une petite application ce n'est pas vraiment génant (il suffit d'enlever le mot-clef final), mais si tu écris des librairies réutilisable cela peut être plus génant...

Enfin je ne pense pas vraiment qu'il y ai une grosse différence entre l'exécution d'une méthode final et d'une méthode non-final du moment qu'aucune classe fille n'a été chargé en mémoire (cf le test sur les mutateurs dans le lien donné plus haut).


Nota : si tu met ta classe en final, tu n'as pas besoin de déclarer le final sur toutes tes méthodes puisque c'est implicite

L'application que je "developpe", en fait pour l'instant je cherche surtout comment l'organiser, s'apparente à l' OrganicBuilder Mais je souhaite l'optimiser pour des calculs plus lourds (plus d'atomes, plus de règles, plus vite) et aussi produire un code bien documenté et organisé.

Je pense qu'il faut que tu te focalises plus dans l'organisation de ton code et ton modèle objet, plutôt que de chercher des optimisations de performances...

En effet il faut optimiser le code lorsqu'il y a des problèmes, et non pas essayer de prévoir les problèmes là où il n'y sont pas... sinon tu risques plus de perdre du temps à optimiser du code pour des broutilles...

Le fait de l'organiser en applet peut peut-etre reduire les performances (je n'ai aucune idée sur la question) mais le logiciel étant aussi à but didactique, cette forme est bien adaptée.

Le problème ne vient pas des Applets mais des technologies utilisée...
Généralement les applets utilisent AWT (et globalement du code Java 1.1) afin de rester compatible avec la JVM de Microsoft...
Or Swing est bien plus performant dans les dernières versions, tout comme les dernières JVM...

Note : Tu peux également utiliser Java Web Start... Jette un coup d'oeil aux demos de Gfx : http://gfx.developpez.com


a++

[adiGuba]

Quelques docs :

Tu peux voir l'intérêt de l'inline dynamique sur cette page : The Java HotSpot Performance Engine: Method Inlining Example


Et sur cette page tu trouveras quelques détails sur les méthode inlines avec HotSpot : http://java.sun.com/products/hotspot/docs/general/hs2.html

Un compilateur statique (comme java < 1.2 ou les compilateurs C++) est limité dans le type de méthode qu'il peut mettre 'inline' : il est limité aux méthode static, final ou private, c'est à dire toutes les méthodes qui ne peuvent pas être redéfini dans une classe fille...

Avec un compilateur dynamique tel que HotSpot, le compilateur peut mettre n'importe quelle méthode 'inline' tant qu'aucune classe fille n'a été chargé, car il pourra désoptimiser le code en cas de besoin...

a++

PS : mais je n'ai pas retrouvé la doc que je cherchais...

[TabrisLeFol]

Mais ta méthode intermédiare n'influe pas sur le nombre de fois où la méthode est appellé...

Justement, l'optimisation n'est pas vraiment sur le nombre. Je m'explique, si on considere que dans mon code le methode simple est appelée n fois elle n'est pas appelée n fois au meme endroit on pourrait avoir, un endroit a appels , un autre b, ... et le dernier (n-a-b...). Le fait de rassembler dans une methode intermediaire implique que les n appels seront réalisés au meme endroit, donc cette zone sera vraiment "chaude". Meme si cela n'aide pas la JVM, mon code est plus optimisé et également, pour moi, à la main, l'inlining sera plus facile, mais je ne sais pas si cela peut avoir des consequences sur la jvm.

C'est la différence entre le C++ et Java !
En C++ toutes les méthodes sont finales et il faut utiliser le mot-clef virtual pour pouvoir les redéfinir dans les classes filles.
En Java toutes les méthodes sont virtuelles et il faut utiliser le mot-clef final pour empêcher les classes filles de les redéfinir.

Je viens justement du C++. J'avais compris que la synthaxe impliquait un comportement différent. Mais je ne savais lequel serait "le meilleur" ; en vue du HotSpot, le final semble avoir perdu son "efficacité pour l'inlining", ainsi j'utiliserait le comportement "java" sans trop me poser de questions. Neanmoins, comme je le disais plus haut, je ne suis jamais vraiment sur de savoir si on doit accepter que telle ou telle methode/classe soit redefinissable ou non. Le comportement par defaut en C++ serait de dire non mais en Java de dire oui. Enfin, il est vrai que je n'ai pas encore developé d'application de grande envergure ni de bibliotheque... Cela n'est donc pas un problème critique pour moi...

Tu peux également utiliser Java Web Start...

Oui, je suis de plus en plus interessé par JWS, il va falloir que je trouve le temps pour l'installer correctement. Car j'ai installé un jdk (et donc un jre), mon browser (firefox) dispose d'un plug-in java mais pour l'instant les fichiers *.jnlp ne sont associés pas associée à une action, et firefox me propose uniquement de les telecharger... J'imagine que j'ai peut etre loupé quelquechose mais je ne sais pas quoi.
OS : Linux (Ubuntu)

Merci pour les documents, certains commentaires sont vraiments interessants/instructifs d'autres j'ai l'impression que sun fait de la pub....