décalages de bits

Bonjour à tous !

Je suis nouveau sur ce forum et ceci est mon premier post.

Je développe actuellement en J2ME et afin d'optimiser mon code, je souhaite remplacer des opérations de type:
var = var / 128;
par:
var = var >> 7;
Je me pose la question suivante: est-il utile de faire ce remplacement ou est-ce que le compilateur, en rencontrant la 1ère opération, fait lui même l'optimisation en remplacant la division par un décalage de bits ? Si c'est le cas, je préfère la 1ère notation (par soucis de clarté dans mon code source)

Merci d'avance pour votre aide !!

Bonne continuation à vous !

Hello,

En règle générale, je dirais qu'il s'agit d'une optimisation inutile, pouvant poser plus de problèmes qu'elle n'en résout:

1) favoriser un code clair au détriment des performances n'est généralement pas considéré comme malsain en programmation. Au contraire, les optimisations doivent être ciblées et répondre à un réel problème de performances. Un code clair et simple peut être optimisé sans trop de difficultés par la suite, si le besoin s'en fait sentir. Un code complexe et pseudo-optimisé est plus difficile à comprendre et maintenir. Il faut mieux le documenter, pour le rendre accessible à d'autres programmeurs. Il aura certainement plus de bugs. Il déstabilise le lecteur par son caractère "tordu" (illogique)
2) si la valeur du diviseur change (127 au lieu de 128), on ne peut plus utiliser le décalage, il faut donc changer d'implémentation, ce qui n'est pas souhaitable.
3) dans la plupart des cas, le gain réel en performances d'une optimisation de ce genre peut être jugé négligeable (selon les algorithmes), car noyé dans la masse de traitements
4) Assez souvent, les implémentations des JVM diffèrent: ce qui est vrai sous win32 ne l'est pas forcément sous Mac, certaines optimisations sont disponibles sur certaines architectures matérielles et d'autres non, et les versions anciennes des JVM sont généralement moins performantes que les récentes... bref il est très difficile de dire, en java, qu'un code tournera toujours mieux qu'un autre quelle que soit la situation.

Enfin voilà, beaucoup de blabla, mais c'est mon avis. Le programmeur Java n'a pas à s'ennuyer des détails de l'implémentation d'une division. Il se trouve à un niveau supérieur. Il réclame une division. Java s'occupe du reste. Si la JVM remarque qu'elle peut gagner 50 cycles machines grâce à une astuce quelconque, elle ne va sûrement pas s'en priver. Mais maintenant, est-ce qu'elle sait qu'une division par une puissance de 2 revient à un décalage des bits vers la droite........ Je serais tenté de répondre oui, mais c'est incertain et sujet à variations selon la version...

Mieux vaut chercher à utiliser moins de gros objets, moins de threads, à favoriser la réutilisation des instances existantes plutôt que de les recréer, limiter le travail du garbage collector et la consommation mémoire... Et surtout, utiliser au maximum ce qui existe déjà dans les librairies standards.....

;)

PS: si quelqu'un désire complèter...

Merci Pill_S pour cette réponse claire et fournie ! :) Je vais me pencher sur les méthodes d'optimisation que tu suggères.

Ceci dit, je pense que je vais continuer à remplacer les multiplications et divisions par une puissance de 2 par des décallages de bits car dans mon code, y'en a énormement dans de nombreuses boucles ! (rotations de points dans l'espace, calculs de coordonnés d'intersections entre un plan et une droite) tous ces calculs sont difficile à faire sans float (je programme en J2ME avec le Wireless ToolKit de Sun) et j'ai donc simplement pris soin de décaller les valeurs avant de les utiliser dans mes différents calculs pour conserver un minimum de précision. Mes tables de sinus et de cosinus, par exemple, sont elles mêmes remplies de valeurs comprises entre -128 et +128

Comme tu dis, il est possible qu'il soit inutile de remplacer les multiplications/divisions par des décallages. J'ai essayé de tester ça dans mon code mais j'ai l'impression que le compilateur voit bien que dans le code les calculs de ces tests ne sont pas utilisés par la suite, ce qui fait qu'il semble tout simplement les ignorer... Je vais donc essayer une différente approche pour determiner s'il y a vraiment gain de vitesse.
J'enverrais un post sur mes conclusions pour ceux que ça pourrait éventuellement interesser.

Pour ajouter un dernier souffle au moulin de Pill_S, cette optimisation était réellement utilisée en ASM sur les registres de la CPU. L'utiliser aujourd'hui sur unr variable dont on ne maitrise pas l'optimisation (mapping sur registre VM ?, registre CPU ?) c'est perdre de l'agilité.

Citation:

---

Envoyé par Alwin

Pour ajouter un dernier souffle au moulin de Pill_S, cette optimisation était réellement utilisée en ASM sur les registres de la CPU. L'utiliser aujourd'hui sur unr variable dont on ne maitrise pas l'optimisation (mapping sur registre VM ?, registre CPU ?) c'est perdre de l'agilité.

---

j'avoue que je n'ai pas tout compris, je croyais qu'une opération sur une variable ne pouvait se faire qu'au travers d'un registre...