J'ai trouvé cet article intéressant :
http://www.devx.com/amd/Article/21314
Bien qu'écrit pour AMD, je pense qu'une bonne part des indées peuvent
s'appliquer sans problème au PowerPC. Cependant j'aimerais l'avis
d'experts ou un lien vers un article équivalent à propos du PowerPC.
Pour certaines choses bien précis, oui. Pour d'autres, non. Par exemple, un compilateur C / C++ ne va jamais changer l'ordre d'exécution des tests (points 4 et 5 dans l'article ci-dessus).
Les gains que les optimisations au niveau du compilateur apportent sont nettement plus faibles que ce celles que le programmeur peut apporter (en réfléchissant un peu et en s'aidant d'outils d'analyse de performance).
tu veux dire que le compilateur ne sait pas réecrire plus intelligemment les algorithmes du programmeur ?
Oui. Le compilateur est très efficace pour optimiser l'exécution d'un code donné sur un processeur donné. Par contre, si le code n'est pas optimal pour la fonctionnalité recherchée (genre il utilise un boucle pour calculer la somme de N premiers entiers au lien d'utiliser la formule de Gauss), le compilateur ne verra pas que le code est sous-optimal.
Patrick -- Patrick Stadelmann
In article <etPan.4191022c.5f905eb5.143d@utopia>,
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
Pour certaines choses bien précis, oui. Pour d'autres, non. Par exemple,
un compilateur C / C++ ne va jamais changer l'ordre d'exécution des
tests (points 4 et 5 dans l'article ci-dessus).
Les gains que les optimisations au niveau du compilateur apportent sont
nettement plus faibles que ce celles que le programmeur peut apporter
(en réfléchissant un peu et en s'aidant d'outils d'analyse de
performance).
tu veux dire que le compilateur ne sait pas réecrire plus intelligemment
les algorithmes du programmeur ?
Oui. Le compilateur est très efficace pour optimiser l'exécution d'un
code donné sur un processeur donné. Par contre, si le code n'est pas
optimal pour la fonctionnalité recherchée (genre il utilise un boucle
pour calculer la somme de N premiers entiers au lien d'utiliser la
formule de Gauss), le compilateur ne verra pas que le code est
sous-optimal.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Pour certaines choses bien précis, oui. Pour d'autres, non. Par exemple, un compilateur C / C++ ne va jamais changer l'ordre d'exécution des tests (points 4 et 5 dans l'article ci-dessus).
Les gains que les optimisations au niveau du compilateur apportent sont nettement plus faibles que ce celles que le programmeur peut apporter (en réfléchissant un peu et en s'aidant d'outils d'analyse de performance).
tu veux dire que le compilateur ne sait pas réecrire plus intelligemment les algorithmes du programmeur ?
Oui. Le compilateur est très efficace pour optimiser l'exécution d'un code donné sur un processeur donné. Par contre, si le code n'est pas optimal pour la fonctionnalité recherchée (genre il utilise un boucle pour calculer la somme de N premiers entiers au lien d'utiliser la formule de Gauss), le compilateur ne verra pas que le code est sous-optimal.
Patrick -- Patrick Stadelmann
DINH Viêt Hoà
tu veux dire que le compilateur ne sait pas réecrire plus intelligemment les algorithmes du programmeur ?
Oui. Le compilateur est très efficace pour optimiser l'exécution d'un code donné sur un processeur donné. Par contre, si le code n'est pas optimal pour la fonctionnalité recherchée (genre il utilise un boucle pour calculer la somme de N premiers entiers au lien d'utiliser la formule de Gauss), le compilateur ne verra pas que le code est sous-optimal.
ah ouais ? c'est bizarre ? Je pensais que les années de recherche en compilation avait permis d'aboutir à des choses plutôt optimales en matière de compilation.
-- DINH V. Hoa,
"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.
tu veux dire que le compilateur ne sait pas réecrire plus intelligemment
les algorithmes du programmeur ?
Oui. Le compilateur est très efficace pour optimiser l'exécution d'un
code donné sur un processeur donné. Par contre, si le code n'est pas
optimal pour la fonctionnalité recherchée (genre il utilise un boucle
pour calculer la somme de N premiers entiers au lien d'utiliser la
formule de Gauss), le compilateur ne verra pas que le code est
sous-optimal.
ah ouais ?
c'est bizarre ?
Je pensais que les années de recherche en compilation avait permis
d'aboutir à des choses plutôt optimales en matière de compilation.
--
DINH V. Hoa,
"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.
tu veux dire que le compilateur ne sait pas réecrire plus intelligemment les algorithmes du programmeur ?
Oui. Le compilateur est très efficace pour optimiser l'exécution d'un code donné sur un processeur donné. Par contre, si le code n'est pas optimal pour la fonctionnalité recherchée (genre il utilise un boucle pour calculer la somme de N premiers entiers au lien d'utiliser la formule de Gauss), le compilateur ne verra pas que le code est sous-optimal.
ah ouais ? c'est bizarre ? Je pensais que les années de recherche en compilation avait permis d'aboutir à des choses plutôt optimales en matière de compilation.
-- DINH V. Hoa,
"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.
Patrick Stadelmann
In article , DINH Viêt Hoà wrote:
Je ne vois alors pas dans quel sens c'est difficile à identifier.
Ca l'est à posteriori : quand tu as remarqué que le problème est causé par une valeur globale incorrecte, tu sais juste que l'erreur est dans l'une des N fonctions qui modifie la globale. Si le bug est peu reproductible, tout ce que tu peux faire c'est monitorer la globale et attendre que le problème ce reproduise.
Patrick -- Patrick Stadelmann
In article <etPan.419110be.1803a564.143d@utopia>,
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
Je ne vois alors pas dans quel sens c'est difficile à identifier.
Ca l'est à posteriori : quand tu as remarqué que le problème est causé
par une valeur globale incorrecte, tu sais juste que l'erreur est dans
l'une des N fonctions qui modifie la globale. Si le bug est peu
reproductible, tout ce que tu peux faire c'est monitorer la globale et
attendre que le problème ce reproduise.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Je ne vois alors pas dans quel sens c'est difficile à identifier.
Ca l'est à posteriori : quand tu as remarqué que le problème est causé par une valeur globale incorrecte, tu sais juste que l'erreur est dans l'une des N fonctions qui modifie la globale. Si le bug est peu reproductible, tout ce que tu peux faire c'est monitorer la globale et attendre que le problème ce reproduise.
Patrick -- Patrick Stadelmann
ol.g+news
Patrick Stadelmann wrote:
Par contre, si le code n'est pas optimal pour la fonctionnalité recherchée (genre il utilise un boucle pour calculer la somme de N premiers entiers au lien d'utiliser la formule de Gauss), le compilateur ne verra pas que le code est sous-optimal.
Bah, on a un compilo qui sait déjà remplacer l'appel à sqrt() par la variante hardware, c'est sur le bon chemin :-)
Pour les boucles la situation se complique encore avec un proc comme le 970 dont le prefetch hardware va détecter des patterns d'accès sur jusqu'à 4 flots simultanés. C'est rigolo.
Ol. -- Olivier Gutknecht
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Par contre, si le code n'est pas optimal pour la fonctionnalité
recherchée (genre il utilise un boucle pour calculer la somme de N
premiers entiers au lien d'utiliser la formule de Gauss), le compilateur
ne verra pas que le code est sous-optimal.
Bah, on a un compilo qui sait déjà remplacer l'appel à sqrt() par la
variante hardware, c'est sur le bon chemin :-)
Pour les boucles la situation se complique encore avec un proc comme le
970 dont le prefetch hardware va détecter des patterns d'accès sur
jusqu'à 4 flots simultanés. C'est rigolo.
Par contre, si le code n'est pas optimal pour la fonctionnalité recherchée (genre il utilise un boucle pour calculer la somme de N premiers entiers au lien d'utiliser la formule de Gauss), le compilateur ne verra pas que le code est sous-optimal.
Bah, on a un compilo qui sait déjà remplacer l'appel à sqrt() par la variante hardware, c'est sur le bon chemin :-)
Pour les boucles la situation se complique encore avec un proc comme le 970 dont le prefetch hardware va détecter des patterns d'accès sur jusqu'à 4 flots simultanés. C'est rigolo.
Ol. -- Olivier Gutknecht
lucsky
DINH Viêt Hoà wrote:
ah ouais ? c'est bizarre ?
Non pas vraiment.
Je pensais que les années de recherche en compilation avait permis d'aboutir à des choses plutôt optimales en matière de compilation.
Des années de recherche en compilation, et on en est encore à se taper cette grosse merde de gcc, dingue non ?
Un compilateur ce n'est rien d'autre qu'une moulinette à transformer quelque chose de haut niveau en quelque chose de plus bas niveau qu'un hardware cible sera capable de digérer, avec éventuellement quelques tours de passe-passe liées au spécificités du hardware en question pour pouvoir aller plus vite. Ni plus, ni moins. Une moulinette.
Maintenant, comme le disait Patrick, détecter un code non optimal algorithmiquement (ce qui est encore largement le meilleur moyen d'optimiser efficacement quand c'est possible) c'est une autre paire de manche. Il faut traverser la barrière qui sépare la syntaxe de la sémantique, et même si c'était faisable facilement, il y aurait sans doute tout un tas d'informations contextuelles à fournir en plus pour que le boulot soit fait correctement.
Donc autant le faire à la main, parceque le développeur est celui qui a toutes les billes en main et est donc celui qui est le plus à même de prendre les bonnes décisions: remplacer un algo merdeux, par un algo efficace.
Le reste, c'est de la branlette pour demo-makers.
-- Luc Heinrich -
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
ah ouais ?
c'est bizarre ?
Non pas vraiment.
Je pensais que les années de recherche en compilation avait permis
d'aboutir à des choses plutôt optimales en matière de compilation.
Des années de recherche en compilation, et on en est encore à se taper
cette grosse merde de gcc, dingue non ?
Un compilateur ce n'est rien d'autre qu'une moulinette à transformer
quelque chose de haut niveau en quelque chose de plus bas niveau qu'un
hardware cible sera capable de digérer, avec éventuellement quelques
tours de passe-passe liées au spécificités du hardware en question pour
pouvoir aller plus vite. Ni plus, ni moins. Une moulinette.
Maintenant, comme le disait Patrick, détecter un code non optimal
algorithmiquement (ce qui est encore largement le meilleur moyen
d'optimiser efficacement quand c'est possible) c'est une autre paire de
manche. Il faut traverser la barrière qui sépare la syntaxe de la
sémantique, et même si c'était faisable facilement, il y aurait sans
doute tout un tas d'informations contextuelles à fournir en plus pour
que le boulot soit fait correctement.
Donc autant le faire à la main, parceque le développeur est celui qui a
toutes les billes en main et est donc celui qui est le plus à même de
prendre les bonnes décisions: remplacer un algo merdeux, par un algo
efficace.
Je pensais que les années de recherche en compilation avait permis d'aboutir à des choses plutôt optimales en matière de compilation.
Des années de recherche en compilation, et on en est encore à se taper cette grosse merde de gcc, dingue non ?
Un compilateur ce n'est rien d'autre qu'une moulinette à transformer quelque chose de haut niveau en quelque chose de plus bas niveau qu'un hardware cible sera capable de digérer, avec éventuellement quelques tours de passe-passe liées au spécificités du hardware en question pour pouvoir aller plus vite. Ni plus, ni moins. Une moulinette.
Maintenant, comme le disait Patrick, détecter un code non optimal algorithmiquement (ce qui est encore largement le meilleur moyen d'optimiser efficacement quand c'est possible) c'est une autre paire de manche. Il faut traverser la barrière qui sépare la syntaxe de la sémantique, et même si c'était faisable facilement, il y aurait sans doute tout un tas d'informations contextuelles à fournir en plus pour que le boulot soit fait correctement.
Donc autant le faire à la main, parceque le développeur est celui qui a toutes les billes en main et est donc celui qui est le plus à même de prendre les bonnes décisions: remplacer un algo merdeux, par un algo efficace.
