Discussion :

[LGnord]

Bonjour,

Je souhaite comparer les performances de deux algorithmes nommés algo1 et algo2.


Dans un premier cas de figure, j'ai deux classes Main différentes. Je lance deux fois java et j'obtiens que mes deux algos sont équivalent. Ils prennent environ 2 secondes.

Dans un deuxième de cas de figure, j'ai une classe Main qui lance les deux algos séquentiellement. Mon deuxième algo devient alors 5 fois plus rapide.

J'imagine qu'il y a un phénomène de cache ou autre qui entre en jeu.

Est-il possible de l'éviter? Par exemple, est-il possible que mes deux algos soit lancée dans 2 VM différentes (autrement dit que mon programme Java crée une vm puis y exécute un bout de code). Utiliser des threads est-il suffisant?

Merci

[thelvin]

J'imagine qu'il y a un phénomène de cache ou autre qui entre en jeu.

Cache et optimisation Just-In-Time des parties communes aux deux algos. C'est donc le premier qui se tape l'optimisation à chaud, et le second qui en profite.

Est-il possible de l'éviter? Par exemple, est-il possible que mes deux algos soit lancée dans 2 VM différentes (autrement dit que mon programme Java crée une vm puis y exécute un bout de code).

Bien sûr, Java peut lancer des programmes indépendants, comme par exemple un nouveau programme Java.

À noter que comparer des performances est une science, et que juste le test "temps de l'algo 1" et "temps de l'algo 2" n'est pas forcément pertinent. Par exemple les données du jeu de test, ou leur mode d'accès, peuvent être trop différentes d'un cas réel. Ou alors, en-dessous d'un certain temps, il peut être sans intérêt de choisir l'un plutôt que l'autre, le véritable temps étant dépensé ailleurs que dans ces algos. Ce ne sont que des exemples. C'est une science.

Utiliser des threads est-il suffisant?

Pas du tout. À la limite ce serait un peu plus "justice" parce que les deux algos, tournant en même temps, auront autant de chances l'un que l'autre de devoir se taper le gros du boulot.
Mais les résultats seront quand même faussés.

[adiGuba]

Salut,


Le mieux serait de répéter les traitements plusieurs fois.

Les premiers sont "faussé" par la compilation JIT, mais on arrive ensuite à des résultat plus stable...

Et attention aux différences inférieurs à 32 voir 64 millisecondes.
L'horloge n'ayant pas forcément une bonne granularité ces écarts sont insignifiant...

a++

[LGnord]

Merci de votre aide.

Je sais bien que cela est une science. Néanmoins, on me demande de produire un résultat à partir du quel des décisions importantes seront prises.

Savez-vous ce que vaut le livre
"Java Performance" de Charlie Hunt et Binu John?

[caféiste]

Salut à tous,

Mon premier post

Dans ton cas, j'aurais essayé de mettre chaque algo dans une thread en MAX_PRIORITY, et les faire tourner une multitude de fois en incluant des sleep pour éviter au maximum d'autre tache de s'exécuter pendant que tes threads s'exécutent.
Plus tu exécutera tes threads plus tu te rapprochera, statistiquement du résultat sur les performances.

[LGnord]

J'ai trouvé une solution à mon problème:

Code :

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

-Djava.compiler=NONE

Plus d'information:
How to make sure no jvm and compiler optimization occurs

[thelvin]

Mais n'est-il pas un peu idiot, quand on s'intéresse aux performances, de supprimer les optimisations ? Il est tout de même assez rare dans le monde réel, qu'elles ralentissent le programme au lieu de l'accélérer. C'est un peu le principe...

[LGnord]

Ta remarque est pleinne de bon sens et me questionne aussi.

Par exemple, je dois implémenter un algorithme qui est lineaire sur le papier. Quand je mesure les performances de mon code par rapport à la taille de l'entrée:

• avec l'option -Djava.compiler=NONE, j'ai une belle ligne droite. Je suis donc convaincu et je peux convaincre le reste de l'équipe.

• sans cette option, j'ai des résultats que je ne sais pas interpreter. Du coup, on reste dans le flou et personne n'ose valider le code...

Pour moi, j'ai plus de controle en empéchant la JVM de faire des optimisations dans mon dos.

[thelvin]

Oui oui, il n'y a aucune doute à ce sujet. Ça nous rapporte à la question de ce qui est le plus important entre :

- S'exécuter avec les meilleures performances

ou

- Savoir quelles seront les performances.

En ce qui me concerne, je favoriserai presque toujours le premier. Et si quelqu'un me livrait quelque chose qui ne le fait pas, dans un contexte où la performance est importante, je lui demanderais des comptes.
Pour ce qui est des craintes de validation, c'est simple. La complexité théorique est <calcul de la complexité théorique avec gestion des contraintes du langage>. Cela doit produire telle courbe : <à peu près ce que tu as en désactivant les optimisations>. Les résultats réels restent en-dessous de cette courbe. Code validé.


Le second ne m'intéresse que dans des cas d'étude théorique de la complexité. Ou si je dois respecter des contraintes de temps réel extrêmes (en gros, quand je ne peux pas considérer vraie l'assertion "la version optimisée ne sera jamais moins rapide que la version optimisée" parce qu'il existe quelques microsituations où c'est faux, et que cela pourrait en théorie produire, contre toute probabilité, des cas où ça arrive aussi en macro).

[adiGuba]

Pour moi, j'ai plus de controle en empéchant la JVM de faire des optimisations dans mon dos.

Le problème avec cette optique, c'est que tu risques de partir dans la mauvaise direction, en "optimisant" ton algo pour une JVM en mode "interprété", mais qui ne le seront pas forcément pour une JVM classique avec compilation JIT.


Sinon pour avoir des résultats plus "fiable" avec le compilateur JIT, il faut répéter le test plusieurs fois jusqu'à ce que la durée du traitement se stabilise...


a++