Discussion :

[kox2ee]

Bonjour, c'est intéressant...
on arrête pas le progrès
Il semble que l'allocation sur la pile de java 7 ait quelques effets :

Java 7 :
affectation interne, type primitif: 3445
affectation interne, type primitif: 3424
affectation interne, type primitif: 3415
affectation externe, type primitif: 3418
affectation externe, type primitif: 3499
affectation externe, type primitif: 3410
affectation interne, objet: 3431
affectation interne, objet: 3427
affectation interne, objet: 3428
affectation externe, objet: 3398
affectation externe, objet: 3421
affectation externe, objet: 3420

Ou si tu es déjà en java 7, questionneuse, il te reste à changer de processeur...

[adiGuba]

Bon je viens de faire quelques essais, et je pense avoir découvert l'origine du problème : questionneuse semble utiliser la JVM "client".

Lorsqu'on parle performance, on utilise généralement la JVM "server" qui active toutes les optimisations possible... et là on n'a pas de différence d'exécution (comme pour kox2ee).

A l'inverse la JVM client a pour objectif de démarrer l'application le plus rapidement possible, et elle n'effectue donc pas toutes les optimisations possibles.

En utilisant la JVM "client" j'obtiens des résultats similaires à ceux de questionneuse... mais cela ne vient pas de la position de la déclaration de la variable !!!



En effet cela semble plutôt venir de la JVM "client" qui n'optimise pas les premières boucles.
En effet si on inverse l'ordre des boucles, on obtient un résultat inverse !!!



a++

[questionneuse]

Salut,


Tu utilises quelle version de Java ?
Quel est la version retourné par "java -version" ?

java 1.6.0_26

[adiGuba]

Je parlais de la version complète, par exemple :

Code :

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

1
2
3
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)

a++

[questionneuse]

En effet cela semble plutôt venir de la JVM "client" qui n'optimise pas les premières boucles.
En effet si on inverse l'ordre des boucles, on obtient un résultat inverse !!!

effectivement le fait d'inverser l'ordre des boucles (donc de faire externe-interne-externe-interne au lieu de interne-externe-interne-externe) inverse les résultats c'est vraiment surprenant, j'ai du mal à comprendre...

affectation externe, type primitif: 7891
affectation externe, type primitif: 7930
affectation externe, type primitif: 8292
affectation interne, type primitif: 5457
affectation interne, type primitif: 5454
affectation interne, type primitif: 5475
affectation externe, objet: 7981
affectation externe, objet: 8056
affectation externe, objet: 7896
affectation interne, objet: 5416
affectation interne, objet: 5365
affectation interne, objet: 5412

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-9M3425)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)

[thelvin]

Probablement l'optimisation JIT qui décide d'intervenir pendant la première boucle, voyant qu'il y a du code optimisable appelé tout le temps. Quelque chose de ce genre.
C'est pour ça que faire des micro-benchmarks, c'est une science en soi.

[adiGuba]

effectivement le fait d'inverser l'ordre des boucles (donc de faire externe-interne-externe-interne au lieu de interne-externe-interne-externe) inverse les résultats c'est vraiment surprenant, j'ai du mal à comprendre...

Le compilateur se nomme "HotSpot", et ce n'est pas pour rien : cela signifie qu'il va détecter les portions de code très utilisé pour les optimiser. Par contre le niveau d'optimisation peut varier pour éviter de passer plus de temps à optimiser le code qu'à l'exécuter...

Il y a de forte chance que le premier type de boucle ne soit pas complètement optimisé, d'où la différence de résultat...



Ce qui est drôle aussi c'est que j'obtiens les mêmes résultats que toi, alors que ce n'était pas le cas auparavant. Je pensais que cela venais de la JVM mais ce n'est pas le cas.
Comme je ne suis pas sur le même poste cela doit venir d'une différence matérielle (une optimisation CPU peut-être ?).




Toutefois et malgré tout on parle d'une différence de moins de 3s sur 10 milliards d'itération ! Ramenée à une itération on tombe à 0,0000000003 s soit 300 nano-secondes...

C'est quelque chose de vraiment anecdotique, et on a déjà perdu plus de temps sur cette discussion qu'on n'en perdra dans toutes nos applications en utilisant une boucle interner ou externe !!!


a++