Salut, desole pour le "retard" de cette reponse mais j'etais en deplacement en allemagne depuis jeudi. Je n'ai pas beaucoup de temps alors je reponds aussi vite que possible 
Citation :
phenixl>elle a permis de montrer qu'utiliser une JVM optimisante est incroyablement plus efficace que de rajouter une petite optimisation à lucarne à la main dans son source, optimisation qui rend par ailleurs celui-ci moins compréhensible.
|
Oui mais non 
Tu as montre que sur un petit exemple comme celui-ci en combinant JIT performant et optimisation de code tu obtenais un resultat encore plus rapide.
Quant au fait que le code soit moins comprehensible je ne suis pas d'accord : il est moins comprehensible car il n'y a pas de commentaires (pour moi >> 10 ou / 1024 c'est pareil je ne sais pas quel est le but : une ligne de commentaire et c'est ok tout le monde se comprend. Si le lecteur ne sait pas ce qu'est le bit shifting il devrait aller prendre qqes cours ou se renseigner AMHA)
Je suis un peu rude mais bon en francais on dit "informaticien" en anglais c'est "computer sciencist" terme qui indique un certain niveau... (je provoque un peu la )
Citation :
Maintenant, je ne dis pas qu'il ne faut jamais optimiser à la main, mais je dis que l'optimisation est une discipline qui demande rigueur, et que ce genre d'optimisation à lucarne est exactement ce qu'il ne faut pas faire.
|
Je suis d'accord a part que je dis que tu peux faire ce genre d'optimisation lorsque tu sais que le compilo ne remetra pas ton code dans son contexte et qu'il ne fera pas les optimisations adequates.
Le loop unroll en est un exemple : modification de l'algo afin de gagner en performances (et ca c'est de l'optimisation meme si tu semble ne pas etre d'accord avec ce terme)
Citation :
Contrairement à ce que tu dis, la plupart des compilateurs modernes ont un mode optimisant très efficace. La doc de gcc en donne une bonne idée (quoique ne sont pas détaillées les optimisations concernant, par exemple, la gestion des parcours de tableaux en utilisant des pointeurs).
|
Ma remarque ne concernait QUE les compilateurs java...
Mais l'optimisation peut se faire a d'aurtes niveaux que celui du JIT ou de la compilation : par exemple au niveau du confinement d'informations (La VM OVM sur laquelle j'ai bosse le fait par exemple : en verifiant que certains types sont confines tu peux changer leurs modifiers pour accelerer l'execution...)
Citation :
Malheureusement, JavaC est le parfait contre-exemple, et Jikes ne fait pas mieux car il a été conçu pour être un clone de JavaC du point de vue comportement (mais pas vitesse d'exécution ).
|
La on est d'accord.
Citation :
Ce que je vais dire est le résultat d'études poussées sur des centaines voire des milliers de projets (ce n'est pas moi qui les ai fait, je vous rassure ) :
|
Dans ce cas source stp (desole deformation professionnelle mais je suis tout a fait d'accord avec toi)
Citation :
l'optimisation manuelle est rarement bénéfique, et sans mesures préalables précises et localisées (j'insiste sur ce dernier mot), elle ne l'est quasiment jamais. D'ailleurs le nombre de programmes qui requièrent d'être vraiment optimisés sont rares, surtout en Java (au passage, remplacer un algorithme par un autre pour que le programme soit plus rapide, je n'appelle pas ça à proprement parler de l' "optimisation" ).
|
Je suis d'accord a 100%. Le cas dont je parlais est effectivement rare : ecriture en Java d'une VM Java avec besoin d'optimiser toutes les structures de donnees, et tout calcul interne afin de ne pas penaliser l'execution
Maintenant cote C++, plonge dans le code de HotSpot et va pleurer un coup : c'est UNE ET UNIQUE GROSSE optimisation : leur code est illisible et il est completement impossible de bosser dessus (faire des modifs etc) tellement tout est lier et allambique... Un ami a fait un internship chez Sun et a bosse sur des ameliorations possibles de HotSpot... Il se tirait des balles en lisant leur code. Maintenant voila : tu n'obtiens pas un JIT a hautes performances si tu n'optimise pas.
Citation :
Il est inutile et dangereux d'optimiser son source, sans avoir préalablement mesuré très précisément quels étaient ses goulots d'étranglement. Et le seul moyen d'obtenir ces mesures précises et localisées, ce n'est :
|
Les mesures sont une chose, mais avant tout il faut penser a l'architecture : avant d'optimiser tu modifie l'architecture, les algorithmes et uniquement ENSUITE et endernier recours tu optimises localement.
Citation :
- ni avec time(), qui est certes précis, mais ne donne absolument pas d'informations localisées -- il mesure un temps d'exécution global uniquement -- (et merci pour les utilisateurs de PC... )
|
J'ai cite time etant donne ton exemple : tu voulais un resultat sur un calcul global (tu calculais le temps pris par l'execution du tout)...
Utiliser JUnit ou tout autre profiler pour ca etait ridicule donc j'ai fais au plus simple
Si le calcul etait mnoye au milieu d'au autre code ok tu prends des outils de profiling, sinon time est parfait pour des petits tests (tu remarqueras que je t'ai dis de spliter ton test en deux )
Citation :
- ni avec System.currentTimeMillisec(), je te l'accorde, qui permet d'avoir des informations localisées, certes, mais peu précises -- mais il est cependant capable de donner des ordres de grandeur, et c'est précisément l'usage que j'en ai fait dans mon illustration précédente.
|
es ordres de grandeur sont completement fausses si tu as la moindre appli en fond, un quelconque service, connexion au web, mp3 qui tourne, etc... Time te donne, lui, le temps reel pris par l'application (d'ou son utilite)
Citation :
Non, le seul outil véritablement valable, c'est le profileur, qui mesure précisément le temps d'exécution passé sur chacune des lignes de code source, et le nombre de fois qu'une ligne a été exécutée. Et souvent, un programme est lent parce qu'il a été mal conçu (mauvaise architecture), ou qu'une ou plusieurs fonctions sont appelées beaucoup trop souvent, alors qu'on pourrait garder leur résultat en mémoire entre les appels. Revoir l'architecture du programme ou appeler beaucoup moins souvent une fonction coûteuse est souvent bien plus efficace que faire une petite optimisation à lucarne dans un coin que l'on suppose souvent exécuté et/ou "trop" coûteux.
...
|
Je signe des deux mains quant au reste.
Bon pour ceux que ce topic interesse j'ai retrouve dans ma bibliotheque cet excellent bouquin (introductif) :
Java Plateform Performance : Strategies and tactics
Steve Wilson - Jeff Kesselman
The Java series (Sun)
chez Addison Wesley
Steve Wilson est le responsable du perfomance tuning de J2SE
Voili voilou.
a+
Message édité par phenixl le 30-09-2002 à 13:09:40
FORUM HardWare.fr
![[:totoz]](https://forum-images.hardware.fr/images/perso/totoz.gif "[:totoz]")
