[JVM] Optimiser l'exécution

Bonjour,
mon collègue m'a posé une question que je trouve pertinente mais dont je n'ai pas la réponse. J'ai bien évidemment cherché sur le net mais je n'ai pas eu de réponse.

Voici la fameuse question :
"Quelle est la méthode la plus rapide pour le compilateur pour comparer des nombres?"
proposition 1 : mon nombre (X) != 2
proposition 2 : mon nombre (X) <= 2

Pour vous résumer le cas d'utilisation, on doit faire des tests (des centaines de milliers) sur des int qui sont des indicateurs.
Je ne peux pas vous en dire plus, mais on doit optimiser le code pour gagner en temps d'exécution.

Salut,

On peut optimiser l'exécution de la JVM pour pas mal de choses, mais cela concerne essentiellement la gestion de la mémoire (et en particulier du Garbage Collector), la gestion des entrées/sorties, le chargement/l'instanciation d'objets, ce genre de choseq. Les calculs et comparaisons sont souvent effectuées par le processeur et son unité arithmétique et logique, ou dans certains cas délégués à des composants plus puissants en calcul comme les GPU, ce qu'on ne peut pas faire directement en Java, mais qui est possible via JNI/JNA. Il y a aussi différentes JVM et certaines sont peut-être dédiées aux calculs et comparaisons et donc optimisées pour.

On peut aussi parfois avoir le choix entre différentes syntaxes Java, dont certaines peuvent être plus performantes que d'autre, et l'architecture du programme peut aussi avoir son importance, sans parler de mettre en place des caches, des pools, etc.

Et puis il y a les optimisations du compilateur qui va en sorte réécrire du code à sa sauce pour optimiser. Se prendre la tête pour écrire une expression qui sera de toute manière remaniée n'a pas d'intérêt.

Quoiqu'il en soit, je ne sais pas si c'est une faute de frappe, ou pas, mais choisir entre (X) != 2 et (X) <= 2, ne relève pas des performances, mais de l'algorithme, ces deux contions n'étant pas du tout équivalentes. Éventuellement le choix entre x!=2 et (x<2 || x>2) pourrait avoir un sens, ou entre (x!=2) et !(x==2). En plus dans ce cas, je suis à peu près sûr que le compilateur choisi de lui-même la méthode qui convient le mieux. Et je suis à peu près sûr que l'accès à la valeur de x (accès mémoire, copie dans un registre) est bien plus pesante (hors cache, parce que dans les machines modernes il faut aussi tenir compte des multiples caches, à tous les niveaux, sans parler du swapping qui vient foutre son dawa dans l'histoire) que la comparaison elle-même.

Et puis l'optimisation, on y travaille surtout quand le code fonctionne mais que les performances ne sont pas acceptables (je ne dis pas qu'il y a des domaines où il faut être super synchrone...). Avec un profiler on détecte les points qui prennent vraiment du temps et sur lesquels on estime qu'on peut gagner beaucoup de temps en travaillant le moins possible (parce ce que s'il faut un an de prise de tête pour gagner 1 ms, ça n'a aucun intérêt) et on travaille dessus. Je ne connais pas les arcanes internes de toutes les JVM, mais je doute qu'on puisse gagner grand chose entre les deux écritures citées ci-avant? Si c'est pour gagner 1 nanoseconde sur un traitement de 20 minutes où est l'intérêt ?

Enfin, il faut penser aussi à la lisibilité du code : si c'est pour gagner 1 ms sur un traitement de 1 minute mais que la maintenance prend 100 fois plus de temps parce que le programme est imbitable et que le moindre truc qu'on change fout en l'air tout le boulot d'optimisation, qu'il faut refaire, on aura perdu beaucoup de temps pour rien.

Pour en venir à la question plus pragmatique à la fin de ton message, je répondrais donc par une question : est-ce que tu as lancé un profiler sur ton programme, pour identifier les parties à cibler pour une optimisation ?

Citation:

Envoyé par sylvain.bron

proposition 1 : mon nombre (X) != 2
proposition 2 : mon nombre (X) <= 2

C'est vrai que comme l'a dit joel ces deux tests ne sont pas équivalentes.

Perso, je me poserai plus ce genre de question sur des choses genre :

(X) * 2
(X) << 1

Et la réponse serait de faire des milliers (millions ?) de test pour voir s'il y a une diff au niveau du temps... et sur des JVM, vendeurs et plateformes différentes aussi.