Il y a toujours javap (avec le jdk) qui permet d'examiner le bytecode genere.
http://www.rgagnon.com/javadetails/java-0495.html
Cependant lors de l'execution, HotSpot peut optimiser dynamiquement le code alors c'est pas evident de determiner a l'avance l'avantage de ces "micro-optimisations" sans faire des benchmarks appropries avec les differentes approches.
Bye. -- Real Gagnon from Quebec, Canada * Java, Javascript, VBScript and PowerBuilder code snippets * http://www.rgagnon.com/howto.html * http://www.rgagnon.com/bigindex.html
Jean-Claude Arbaut <jeanclaudearbaut@orange.fr> wrote in news:48aed8f4$0
$876$ba4acef3@news.orange.fr:
Il y a toujours javap (avec le jdk) qui permet d'examiner le bytecode
genere.
http://www.rgagnon.com/javadetails/java-0495.html
Cependant lors de l'execution, HotSpot peut optimiser dynamiquement le
code alors c'est pas evident de determiner a l'avance l'avantage de ces
"micro-optimisations" sans faire des benchmarks appropries avec les
differentes approches.
Bye.
--
Real Gagnon from Quebec, Canada
* Java, Javascript, VBScript and PowerBuilder code snippets
* http://www.rgagnon.com/howto.html
* http://www.rgagnon.com/bigindex.html
Il y a toujours javap (avec le jdk) qui permet d'examiner le bytecode genere.
http://www.rgagnon.com/javadetails/java-0495.html
Cependant lors de l'execution, HotSpot peut optimiser dynamiquement le code alors c'est pas evident de determiner a l'avance l'avantage de ces "micro-optimisations" sans faire des benchmarks appropries avec les differentes approches.
Bye. -- Real Gagnon from Quebec, Canada * Java, Javascript, VBScript and PowerBuilder code snippets * http://www.rgagnon.com/howto.html * http://www.rgagnon.com/bigindex.html
Emmanuel Bourg
Jean-Claude Arbaut a écrit :
D'autre part, est-ce qu'il est équivalent du point de vue de la vitesse, de déclarer une variable dans le corps d'une boucle ou à l'extérieur ?
De mémoire je crois que c'est équivalent, mais je n'ai pas de référence sous la main. Dans le doute un petit programme de test peut permettre de le vérifier rapidement.
Jean-Claude Arbaut a écrit :
D'autre part, est-ce qu'il est équivalent du
point de vue de la vitesse, de déclarer une variable
dans le corps d'une boucle ou à l'extérieur ?
De mémoire je crois que c'est équivalent, mais je n'ai pas de référence
sous la main. Dans le doute un petit programme de test peut permettre de
le vérifier rapidement.
D'autre part, est-ce qu'il est équivalent du point de vue de la vitesse, de déclarer une variable dans le corps d'une boucle ou à l'extérieur ?
De mémoire je crois que c'est équivalent, mais je n'ai pas de référence sous la main. Dans le doute un petit programme de test peut permettre de le vérifier rapidement.
Jean-Claude Arbaut
Emmanuel Bourg wrote:
Jean-Claude Arbaut a écrit :
D'autre part, est-ce qu'il est équivalent du point de vue de la vitesse, de déclarer une variable dans le corps d'une boucle ou à l'extérieur ?
De mémoire je crois que c'est équivalent, mais je n'ai pas de référence sous la main. Dans le doute un petit programme de test peut permettre de le vérifier rapidement.
Ok, merci à tous les deux pour les réponses, je vais retourner à mon clavier et regarder de plus près comment ça se passe "à l'intérieur" ;-)
PS: rien à voir avec le sujet, mais... ce nom ne m'est pas inconnu. Quelque chose à voir avec Nîmes, ou bien il s'agit d'un homonyme ? :-)
Emmanuel Bourg wrote:
Jean-Claude Arbaut a écrit :
D'autre part, est-ce qu'il est équivalent du
point de vue de la vitesse, de déclarer une variable
dans le corps d'une boucle ou à l'extérieur ?
De mémoire je crois que c'est équivalent, mais je n'ai pas de référence
sous la main. Dans le doute un petit programme de test peut permettre de
le vérifier rapidement.
Ok, merci à tous les deux pour les réponses, je vais retourner à mon
clavier et regarder de plus près comment ça se passe "à l'intérieur" ;-)
PS: rien à voir avec le sujet, mais... ce nom ne m'est pas inconnu.
Quelque chose à voir avec Nîmes, ou bien il s'agit d'un homonyme ? :-)
D'autre part, est-ce qu'il est équivalent du point de vue de la vitesse, de déclarer une variable dans le corps d'une boucle ou à l'extérieur ?
De mémoire je crois que c'est équivalent, mais je n'ai pas de référence sous la main. Dans le doute un petit programme de test peut permettre de le vérifier rapidement.
Ok, merci à tous les deux pour les réponses, je vais retourner à mon clavier et regarder de plus près comment ça se passe "à l'intérieur" ;-)
PS: rien à voir avec le sujet, mais... ce nom ne m'est pas inconnu. Quelque chose à voir avec Nîmes, ou bien il s'agit d'un homonyme ? :-)
Emmanuel Bourg
Jean-Claude Arbaut a écrit :
PS: rien à voir avec le sujet, mais... ce nom ne m'est pas inconnu. Quelque chose à voir avec Nîmes, ou bien il s'agit d'un homonyme ? :-)
Surement un homonyme, on tombe parfois sur des choses étonnantes en tapant son nom dans Google :
D'autre part, est-ce qu'il est équivalent du point de vue de la vitesse, de déclarer une variable dans le corps d'une boucle ou à l'extérieur ?
De mémoire je crois que c'est équivalent, mais je n'ai pas de référence sous la main. Dans le doute un petit programme de test peut permettre de le vérifier rapidement.
Ok, merci à tous les deux pour les réponses, je vais retourner à mon clavier et regarder de plus près comment ça se passe "à l'intérieur" ;-)
PS: rien à voir avec le sujet, mais... ce nom ne m'est pas inconnu. Quelque chose à voir avec Nîmes, ou bien il s'agit d'un homonyme ? :-)
Ok, des fois que ça intéresserait quelqu'un... :-) (en espérant ne pas me planter, je débute en langage VM !)
Sans rentrer à fond dans les détail, la VM a un langage à pile, genre Forth. Lorsqu'on compile une méthode, les variables locales semblent être alouées à la compilation: ça ne coûte donc pas plus cher de déclarer à l'intérieur d'une boucle.
Les arguments de méthodes et les variables locales sont dans une pile, à raison d'une pile par thread. Il y a aussi une pile d'opérande, utilisée pour les calculs: on fait des échanges entre cette pile et les variables locales avec les instructions iload et istore.
Les expressions ne sont pas optimisées : (a+b)*(a+b) ne sera pas traduit en "a b + dup +" par exemple (pour ceux qui connaissent le langage de la HP48, qui ressemble à ce qui se passe ici). On peut optimiser à la main en utilisant une variable locale, mais alors on aura des iload/istore en plus. Javac ne semble pas permettre d'utiliser les instructions dup et swap "à la main", ce qui à mon avis serait le meilleur moyen d'optimiser le code.
Là, on a le choix entre des iload/istore en trop ou des opérations arithmétiques en trop. Je ne sais pas encore ce qui coûte le plus cher : ça dépendra évidemment de la complexité des expressions que l'on optimise.
Par contre, il existe apparemment des outils qui peuvent faire ça (taper "java optimization").
Autre type d'optimisation, j'ai vu sur ce site ( http://tomcopeland.blogs.com/juniordeveloper/2006/01/faster_java_boo.html ) que "x ^= true" est plus rapide que x = !x.
Pour terminer cette petite excursion, comme on l'a déjà fait remarquer, le JIT va de toute façon passer derrière tout ça, et il est difficile de savoir ce qu'il fait (en tout cas c'est difficile pour moi !). Alors à moins d'être vicieux et de tenir absolument à désactiver le JIT, je ne vois pas trop comment prévoir ce qui est le mieux.
Ah, aussi, j'avais fait quelques tests avec le JDK 7 il y a quelques temps, et la compilation JIT semblait pas mal du tout : une multiplication matricielle simpliste était aussi rapide en java qu'en C sans les optimisations de gcc. Par multiplication simpliste, j'entends trois boucles pour calculer c[i,j] += a[i,k]*b[k,j] avec pour seule astuce, que l'on code les boucles dans le bon ordre, c'est-à-dire de façon que l'indice qui change le plus souvent (le plus interne des trois), parcoure une zone de mémoire contiguë.
Moralité... je ne suis pas beaucoup plus avancé, mais au moins je vois comment c'est fait à l'intérieur :D
[dernière chose : java interdit le "goto", mais la VM s'en sert à tours de bras. Ca a donné l'idée à des gens de trafiquer un peu la compilation pour pouvoir quand même utiliser goto en java. Ca sert en particulier, si ma mémoire est bonne, dans f2j, un programme qui traduit automatiquement du fortran en java : en effet, fortran se sert beaucoup de goto]
Jean-Claude Arbaut wrote:
Emmanuel Bourg wrote:
Jean-Claude Arbaut a écrit :
D'autre part, est-ce qu'il est équivalent du
point de vue de la vitesse, de déclarer une variable
dans le corps d'une boucle ou à l'extérieur ?
De mémoire je crois que c'est équivalent, mais je n'ai pas de
référence sous la main. Dans le doute un petit programme de test peut
permettre de le vérifier rapidement.
Ok, merci à tous les deux pour les réponses, je vais retourner à mon
clavier et regarder de plus près comment ça se passe "à l'intérieur" ;-)
PS: rien à voir avec le sujet, mais... ce nom ne m'est pas inconnu.
Quelque chose à voir avec Nîmes, ou bien il s'agit d'un homonyme ? :-)
Ok, des fois que ça intéresserait quelqu'un... :-) (en espérant ne
pas me planter, je débute en langage VM !)
Sans rentrer à fond dans les détail, la VM a un langage à pile, genre
Forth. Lorsqu'on compile une méthode, les variables locales semblent
être alouées à la compilation: ça ne coûte donc pas plus cher de
déclarer à l'intérieur d'une boucle.
Les arguments de méthodes et les variables locales sont dans une pile,
à raison d'une pile par thread. Il y a aussi une pile d'opérande,
utilisée pour les calculs: on fait des échanges entre cette pile
et les variables locales avec les instructions iload et istore.
Les expressions ne sont pas optimisées : (a+b)*(a+b)
ne sera pas traduit en "a b + dup +" par exemple (pour ceux
qui connaissent le langage de la HP48, qui ressemble à ce qui
se passe ici).
On peut optimiser à la main en utilisant une variable locale,
mais alors on aura des iload/istore en plus. Javac ne semble
pas permettre d'utiliser les instructions dup et swap "à la main",
ce qui à mon avis serait le meilleur moyen d'optimiser le code.
Là, on a le choix entre des iload/istore en trop ou des opérations
arithmétiques en trop. Je ne sais pas encore ce qui coûte le
plus cher : ça dépendra évidemment de la complexité des
expressions que l'on optimise.
Par contre, il existe apparemment des outils qui peuvent faire
ça (taper "java optimization").
Autre type d'optimisation, j'ai vu sur ce site
(
http://tomcopeland.blogs.com/juniordeveloper/2006/01/faster_java_boo.html )
que "x ^= true" est plus rapide que x = !x.
Pour terminer cette petite excursion, comme on l'a déjà fait remarquer,
le JIT va de toute façon passer derrière tout ça, et il est difficile
de savoir ce qu'il fait (en tout cas c'est difficile pour moi !).
Alors à moins d'être vicieux et de tenir absolument à désactiver le JIT,
je ne vois pas trop comment prévoir ce qui est le mieux.
Ah, aussi, j'avais fait quelques tests avec le JDK 7 il y a quelques
temps, et la compilation JIT semblait pas mal du tout : une
multiplication matricielle simpliste était aussi rapide en java qu'en C
sans les optimisations de gcc.
Par multiplication simpliste, j'entends trois boucles pour calculer
c[i,j] += a[i,k]*b[k,j]
avec pour seule astuce, que l'on code les boucles dans le bon ordre,
c'est-à-dire de façon que l'indice qui change le plus souvent (le
plus interne des trois), parcoure une zone de mémoire contiguë.
Moralité... je ne suis pas beaucoup plus avancé, mais au moins je
vois comment c'est fait à l'intérieur :D
[dernière chose : java interdit le "goto", mais la VM s'en sert à tours
de bras. Ca a donné l'idée à des gens de trafiquer un peu la compilation
pour pouvoir quand même utiliser goto en java. Ca sert en particulier,
si ma mémoire est bonne, dans f2j, un programme qui traduit
automatiquement du fortran en java : en effet, fortran se sert beaucoup
de goto]
D'autre part, est-ce qu'il est équivalent du point de vue de la vitesse, de déclarer une variable dans le corps d'une boucle ou à l'extérieur ?
De mémoire je crois que c'est équivalent, mais je n'ai pas de référence sous la main. Dans le doute un petit programme de test peut permettre de le vérifier rapidement.
Ok, merci à tous les deux pour les réponses, je vais retourner à mon clavier et regarder de plus près comment ça se passe "à l'intérieur" ;-)
PS: rien à voir avec le sujet, mais... ce nom ne m'est pas inconnu. Quelque chose à voir avec Nîmes, ou bien il s'agit d'un homonyme ? :-)
Ok, des fois que ça intéresserait quelqu'un... :-) (en espérant ne pas me planter, je débute en langage VM !)
Sans rentrer à fond dans les détail, la VM a un langage à pile, genre Forth. Lorsqu'on compile une méthode, les variables locales semblent être alouées à la compilation: ça ne coûte donc pas plus cher de déclarer à l'intérieur d'une boucle.
Les arguments de méthodes et les variables locales sont dans une pile, à raison d'une pile par thread. Il y a aussi une pile d'opérande, utilisée pour les calculs: on fait des échanges entre cette pile et les variables locales avec les instructions iload et istore.
Les expressions ne sont pas optimisées : (a+b)*(a+b) ne sera pas traduit en "a b + dup +" par exemple (pour ceux qui connaissent le langage de la HP48, qui ressemble à ce qui se passe ici). On peut optimiser à la main en utilisant une variable locale, mais alors on aura des iload/istore en plus. Javac ne semble pas permettre d'utiliser les instructions dup et swap "à la main", ce qui à mon avis serait le meilleur moyen d'optimiser le code.
Là, on a le choix entre des iload/istore en trop ou des opérations arithmétiques en trop. Je ne sais pas encore ce qui coûte le plus cher : ça dépendra évidemment de la complexité des expressions que l'on optimise.
Par contre, il existe apparemment des outils qui peuvent faire ça (taper "java optimization").
Autre type d'optimisation, j'ai vu sur ce site ( http://tomcopeland.blogs.com/juniordeveloper/2006/01/faster_java_boo.html ) que "x ^= true" est plus rapide que x = !x.
Pour terminer cette petite excursion, comme on l'a déjà fait remarquer, le JIT va de toute façon passer derrière tout ça, et il est difficile de savoir ce qu'il fait (en tout cas c'est difficile pour moi !). Alors à moins d'être vicieux et de tenir absolument à désactiver le JIT, je ne vois pas trop comment prévoir ce qui est le mieux.
Ah, aussi, j'avais fait quelques tests avec le JDK 7 il y a quelques temps, et la compilation JIT semblait pas mal du tout : une multiplication matricielle simpliste était aussi rapide en java qu'en C sans les optimisations de gcc. Par multiplication simpliste, j'entends trois boucles pour calculer c[i,j] += a[i,k]*b[k,j] avec pour seule astuce, que l'on code les boucles dans le bon ordre, c'est-à-dire de façon que l'indice qui change le plus souvent (le plus interne des trois), parcoure une zone de mémoire contiguë.
Moralité... je ne suis pas beaucoup plus avancé, mais au moins je vois comment c'est fait à l'intérieur :D
[dernière chose : java interdit le "goto", mais la VM s'en sert à tours de bras. Ca a donné l'idée à des gens de trafiquer un peu la compilation pour pouvoir quand même utiliser goto en java. Ca sert en particulier, si ma mémoire est bonne, dans f2j, un programme qui traduit automatiquement du fortran en java : en effet, fortran se sert beaucoup de goto]
