Java et optimisation

Le
Jean-Claude Arbaut
Bonjour,

Est-ce que vou savez si le compilateur javac est capable
d'optimiser une expression du genre a[i]*(a[i]+1),
en ne faisant qu'un seul r©f©rence au talbeau ?
Est-ce qu'il vaut mieux d©finir une variable t=a[i] ?

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 ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Claude Arbaut
Le #16602342
Bonjour,

Est-ce que vous savez si le compilateur javac est capable
d'optimiser une expression du genre a[i]*(a[i]+1),
en ne faisant qu'une seul r©f©rence au tableau ?
Est-ce qu'il vaut mieux d©finir une variable t=a[i] ?

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 ?


(les fautes en moins, c'est mieux !)
Real Gagnon
Le #16602382
Jean-Claude Arbaut $876$:

Bonjour,

Est-ce que vou savez si le compilateur javac est capable
d'optimiser une expression du genre a[i]*(a[i]+1),
en ne faisant qu'un seul r©f©rence au talbeau ?
Est-ce qu'il vaut mieux d©finir une variable t=a[i] ?

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 ?




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
Le #16619681
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
Le #16634541
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
Le #16641721
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 :

http://www.bodybuildingfrance.com/competitions/comq132/cat07.htm

:)
Jean-Claude Arbaut
Le #16641711
Emmanuel Bourg wrote:
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 :

http://www.bodybuildingfrance.com/competitions/comq132/cat07.htm

:)



Ce n'est pas lui non plus :D
Jean-Claude Arbaut
Le #16645751
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]
Publicité
Poster une réponse
Anonyme