optimisation par le compilateur

Bonjour,

Est-ce que je peux compter sur le compilateur pour:

1. Réécrire une boucle for itérant sur des indices et indexant les éléments d'un array par [i] en une boucle optimisée (probablement par arithmétique de pointeurs et déréférence). (Je préfère boucler sur des indices car c'est plus lisible à mon goût.)
2. Compiler inline les petites fonctions utilitaires? (Même remarque, ces petites fonctions font office d'auto-documentation).
3. Mettre en registre les données locales critiques, utilisées intensément, comme un accumulateur de boucle?

J'aimerais savoir cela pour gcc en particulier, mais aussi pour les compilateurs C en général. J'ai lu plusieurs fois que nos (ridicules, triciales) tentatives d'optimisation "manuelles" sont souvent inutiles, voire nuisibles. Aussi, à quoi servent les annotations comme inline et register si de toute façon le compilateur fait le boulot tout seul. D'autre part, y a-t-il quelque part une doc sur les niveaux d'optimisation (commandés par arguments en ligne de commande), ce que gcc fait ou pas, précisément, à chaque niveau d'optim (ça, c'est pour la culture générale :-)? Enfin, quel niveau recommander en "rapport qualité-prix" ;-), je veux dire à partir de quel niveau l'augmentation de quantité de travail par le compilateur ne vaut-elle plus le coup?

Le but, c'est d'avoir un code lisible, pas surchargé ni "distordu" pour gagner des micro-secondes à l'exécuition, et malgré tout une efficacité raisonnable.

Merci,
denis

Bonjour denispir

Ne compte jamais sur un compilateur pour optimiser ton code. Si tu veux être sur, fait lui générer l'assembleur et voit par toi même.

Pour le moment, je n'ai pas vu de doc qui décrivent les optimisations faites par un compilateur.

Bonjour,

Je pense que ce genre d'optimisation est "ridicule". Il est préférable d'améliorer un algorithme / de changer l'utilisation CPU / mémoire afin d'éviter de faire mille calculs inutile est répétitif et un tas de choses comme cela.

Pour le reste, je fais "confiance" à mon compilateur (ils sont vraiment puissant de nos jours), comme cela je ne perd pas de temps sur des optimisation bien trop souvent inutiles (bien sur, j'active les options qui vont bien -DNDEBUG / -O3 ...).

Après, si vraiment j'ai un problème de performance, je trace mon programme pour savoir quels sont les points faibles.

Pas mieux :)

Avec une précision = -O2 marche bien dans la quasi-totalité des cas, -O5 nettement moins.

Maintenant, la principale optimisation se situe entre la chaise et le clavier ..

L'algorithmie est essentielle.

Les inline ou autres ne sont vraiment à utiliser que lorsqu'on est déjà certain que l'algoriihme en tant que tel est optimisé, que les options des compilo ont été déjà utilisées, et que l'on a toujours un problème de performances.

Salut,

pareil :)

Les compilateurs optimisent le code obtenu souvent bien mieux qu'un humain, surtout si tu lui donnes des indications. Avec gcc tu peux indiquer quelles fonctions sont critiques (attribut hot) par exemple, lesquelles tu veux inliner, les pointeurs qui ne couvrent pas la même zone mémoire (restrict), si ton processeur accepte ou non des intructions vectorielles (réécriture de boucle) ... un seul mot : la doc gcc. Intel optimise aussi bien le code obtenu, là aussi il y a une doc faramineuse.
Et finalement tu as une floppée d'outils d'aide à l'optimisation comme les profilers, gcc (et icc, je crois, pas sûr) permet aussi de recompiler après une phase de profilage pour profiter des données collectées. Tu peux pousser ça très loin, valgrind avec l'outil cachegrind te permet de profiler le cache par exemple.

Salut,

Je pense que les compilos de nos jours optimisent mieux le code que la grande majorité des programmeurs.

Mais que cela était dit plus haut la meilleur des optimisation reste dans l'algo en lui même.

Perso je regarde systématiquement le code généré par gcc par la commande:

objdump -D monprogramme > monprogramme.dump

Ca me permet de mieux comprendre comment fonctionne le compilo et donc la programmation en règle générale.

@+