Ben c'est pas dur, y'a que deux règles pour l'optimisation :
1°/ On n'optimise pas.
2°/ (pour experts seulement) On n'optimise pas encore.
Blague à part, effectivement, les compilateurs optimisants sont plutôt assez bien fichus de nos jours, et un bon algo restera en général bien plus efficace qu'une micro-optimisation locale. Il y a des exceptions, bien entendu.
Pour répondre à un commentaire vu plus haut concernant les histoires d'optimisation pour les caches, etc.. Si on prend la bibliothèque MKL (Math Kernel Library) d'Intel qui a été optimisée aux petits oignons et tout, on s'aperçoit que les défauts de cache, on s'en fout. Elle en fait plein, plus que des bibliothèques justement étudiées pour les minimiser. En contrepartie, elle fait plein de préchargements intelligents.
C'est ça le gros problème de l'optimisation : on cherche à améliorer la localité ? Très bien, on améliore. Mais on oublie que les défauts de cache sont parfois peu important vis à vis d'autres facteurs (un défaut de TLB par exemple est souvent bien plus déterminant qu'un défaut de cache L2). Ou bien on se rend compte que tout bêtement, un compilateur donné ne sait pas correctement dérouler des boucles un peu irrégulières, et qu'il suffit de le faire à la main pour gagner 20 à 30% de performances (déjà expérimenté sur icc version Itanium). Mais là, on se rend dépendant d'un compilateur donné.
Donc toute la difficulté est dans le compromis portabilité du code/portabilité des performances/optimisations spécifiques, et franchement, avant d'en arriver à ce genre de choses, je pense que bien définir ses structures de données et ses algorithmes est sacrément plus important.
[^] # Re: Plop !
Posté par lasher . En réponse au journal "L'informatique Paradoxale". Évalué à 7.
1°/ On n'optimise pas.
2°/ (pour experts seulement) On n'optimise pas encore.
Blague à part, effectivement, les compilateurs optimisants sont plutôt assez bien fichus de nos jours, et un bon algo restera en général bien plus efficace qu'une micro-optimisation locale. Il y a des exceptions, bien entendu.
Pour répondre à un commentaire vu plus haut concernant les histoires d'optimisation pour les caches, etc.. Si on prend la bibliothèque MKL (Math Kernel Library) d'Intel qui a été optimisée aux petits oignons et tout, on s'aperçoit que les défauts de cache, on s'en fout. Elle en fait plein, plus que des bibliothèques justement étudiées pour les minimiser. En contrepartie, elle fait plein de préchargements intelligents.
C'est ça le gros problème de l'optimisation : on cherche à améliorer la localité ? Très bien, on améliore. Mais on oublie que les défauts de cache sont parfois peu important vis à vis d'autres facteurs (un défaut de TLB par exemple est souvent bien plus déterminant qu'un défaut de cache L2). Ou bien on se rend compte que tout bêtement, un compilateur donné ne sait pas correctement dérouler des boucles un peu irrégulières, et qu'il suffit de le faire à la main pour gagner 20 à 30% de performances (déjà expérimenté sur icc version Itanium). Mais là, on se rend dépendant d'un compilateur donné.
Donc toute la difficulté est dans le compromis portabilité du code/portabilité des performances/optimisations spécifiques, et franchement, avant d'en arriver à ce genre de choses, je pense que bien définir ses structures de données et ses algorithmes est sacrément plus important.