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.
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.
laisse tomber, il vaut mieux laisser le compilateur faire ce genre d'optimisations à ta place, il le fait souvent mieux que toi.
-- DINH V. Hoa,
"sunZ ! capitaine de soirées"
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.
laisse tomber, il vaut mieux laisser le compilateur faire ce genre
d'optimisations à ta place, il le fait souvent mieux que toi.
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.
laisse tomber, il vaut mieux laisser le compilateur faire ce genre d'optimisations à ta place, il le fait souvent mieux que toi.
-- DINH V. Hoa,
"sunZ ! capitaine de soirées"
bernard tatin
DINH Viêt Hoà wrote:
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.
laisse tomber, il vaut mieux laisser le compilateur faire ce genre d'optimisations à ta place, il le fait souvent mieux que toi.
Ce que j'ai compris, c'est qu'en réalité on aide le compilateur à mieux optimiser. Et ce que j'ai compris, c'est que ça marche. On ne divise pas les temps d'exécution par deux. Mais on arrive à gagner quelques pourcent, qui, accumulés à quelques autres pourcent gagnés avec d'autres considérations, finissent par faire une différence sensible.
Bernard.
DINH Viêt Hoà wrote:
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.
laisse tomber, il vaut mieux laisser le compilateur faire ce genre
d'optimisations à ta place, il le fait souvent mieux que toi.
Ce que j'ai compris, c'est qu'en réalité on aide le compilateur à mieux
optimiser. Et ce que j'ai compris, c'est que ça marche. On ne divise pas
les temps d'exécution par deux. Mais on arrive à gagner quelques
pourcent, qui, accumulés à quelques autres pourcent gagnés avec d'autres
considérations, finissent par faire une différence sensible.
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.
laisse tomber, il vaut mieux laisser le compilateur faire ce genre d'optimisations à ta place, il le fait souvent mieux que toi.
Ce que j'ai compris, c'est qu'en réalité on aide le compilateur à mieux optimiser. Et ce que j'ai compris, c'est que ça marche. On ne divise pas les temps d'exécution par deux. Mais on arrive à gagner quelques pourcent, qui, accumulés à quelques autres pourcent gagnés avec d'autres considérations, finissent par faire une différence sensible.
Bernard.
Patrick Stadelmann
In article , DINH Viêt Hoà wrote:
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.
laisse tomber, il vaut mieux laisser le compilateur faire ce genre d'optimisations à ta place, il le fait souvent mieux que toi.
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).
Patrick -- Patrick Stadelmann
In article <etPan.418e5e34.5ac1aff5.143d@utopia>,
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
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.
laisse tomber, il vaut mieux laisser le compilateur faire ce genre
d'optimisations à ta place, il le fait souvent mieux que toi.
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).
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
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.
laisse tomber, il vaut mieux laisser le compilateur faire ce genre d'optimisations à ta place, il le fait souvent mieux que toi.
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).
Patrick -- Patrick Stadelmann
ol.g+news
bernard tatin wrote:
Ce que j'ai compris, c'est qu'en réalité on aide le compilateur à mieux optimiser. Et ce que j'ai compris, c'est que ça marche. On ne divise pas les temps d'exécution par deux. Mais on arrive à gagner quelques pourcent, qui, accumulés à quelques autres pourcent gagnés avec d'autres considérations, finissent par faire une différence sensible.
A vérifier dans le contexte PowerPC / OS X / gcc. Je suis souvent dubitatif sur ce genre de réarrangement qui au pire vont empêcher le compilateur de détecter certaines patterns courantes. De toutes façons, comme dit Patrick, tout ce qui n'est pas fondé sur des mesures concrètes (par exemple avec Shark qui a l'énorme mérite de faire à la fois de l'analyse statique et dynamique) ne vaut pas grand chose 'a priori'. Par contre c'est très vrai que des choses comme un souci d'alignement va avoir un impact fort, et plus encore sur le G5 que dans les générations précédentes.
L'équivalent - un peu plus général - de cet article serait: <http://developer.apple.com/technotes/tn/tn2086.html> <http://developer.apple.com/technotes/tn/tn2087.html> <http://developer.apple.com/performance/g5optimization.html>
Il y a aussi un article tout récent d'introduction à l'indispensable Shark: <http://developer.apple.com/tools/sharkoptimize.html>
Ol. -- Olivier Gutknecht
bernard tatin <bernard.tatin@nospam.tele2.fr> wrote:
Ce que j'ai compris, c'est qu'en réalité on aide le compilateur à mieux
optimiser. Et ce que j'ai compris, c'est que ça marche. On ne divise pas
les temps d'exécution par deux. Mais on arrive à gagner quelques
pourcent, qui, accumulés à quelques autres pourcent gagnés avec d'autres
considérations, finissent par faire une différence sensible.
A vérifier dans le contexte PowerPC / OS X / gcc. Je suis souvent
dubitatif sur ce genre de réarrangement qui au pire vont empêcher le
compilateur de détecter certaines patterns courantes.
De toutes façons, comme dit Patrick, tout ce qui n'est pas fondé sur des
mesures concrètes (par exemple avec Shark qui a l'énorme mérite de faire
à la fois de l'analyse statique et dynamique) ne vaut pas grand chose 'a
priori'. Par contre c'est très vrai que des choses comme un souci
d'alignement va avoir un impact fort, et plus encore sur le G5 que dans
les générations précédentes.
L'équivalent - un peu plus général - de cet article serait:
<http://developer.apple.com/technotes/tn/tn2086.html>
<http://developer.apple.com/technotes/tn/tn2087.html>
<http://developer.apple.com/performance/g5optimization.html>
Il y a aussi un article tout récent d'introduction à l'indispensable
Shark:
<http://developer.apple.com/tools/sharkoptimize.html>
Ce que j'ai compris, c'est qu'en réalité on aide le compilateur à mieux optimiser. Et ce que j'ai compris, c'est que ça marche. On ne divise pas les temps d'exécution par deux. Mais on arrive à gagner quelques pourcent, qui, accumulés à quelques autres pourcent gagnés avec d'autres considérations, finissent par faire une différence sensible.
A vérifier dans le contexte PowerPC / OS X / gcc. Je suis souvent dubitatif sur ce genre de réarrangement qui au pire vont empêcher le compilateur de détecter certaines patterns courantes. De toutes façons, comme dit Patrick, tout ce qui n'est pas fondé sur des mesures concrètes (par exemple avec Shark qui a l'énorme mérite de faire à la fois de l'analyse statique et dynamique) ne vaut pas grand chose 'a priori'. Par contre c'est très vrai que des choses comme un souci d'alignement va avoir un impact fort, et plus encore sur le G5 que dans les générations précédentes.
L'équivalent - un peu plus général - de cet article serait: <http://developer.apple.com/technotes/tn/tn2086.html> <http://developer.apple.com/technotes/tn/tn2087.html> <http://developer.apple.com/performance/g5optimization.html>
Il y a aussi un article tout récent d'introduction à l'indispensable Shark: <http://developer.apple.com/tools/sharkoptimize.html>
Ol. -- Olivier Gutknecht
pdorange
Olivier Gutknecht <ol.g+ wrote:
L'équivalent - un peu plus général - de cet article serait: <http://developer.apple.com/technotes/tn/tn2086.html> <http://developer.apple.com/technotes/tn/tn2087.html> <http://developer.apple.com/performance/g5optimization.html>
Qui notamment précise (Be a good citizen) qu'il est préférable d'éviter les globales, ce qui est en contradiction avec le point #1 de l'article cité (concernant AMD)...
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
Olivier Gutknecht <ol.g+news@free.fr> wrote:
L'équivalent - un peu plus général - de cet article serait:
<http://developer.apple.com/technotes/tn/tn2086.html>
<http://developer.apple.com/technotes/tn/tn2087.html>
<http://developer.apple.com/performance/g5optimization.html>
Qui notamment précise (Be a good citizen) qu'il est préférable d'éviter
les globales, ce qui est en contradiction avec le point #1 de l'article
cité (concernant AMD)...
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st>
Clarus, the DogCow <www.clarus.mac-fan.com>
L'équivalent - un peu plus général - de cet article serait: <http://developer.apple.com/technotes/tn/tn2086.html> <http://developer.apple.com/technotes/tn/tn2087.html> <http://developer.apple.com/performance/g5optimization.html>
Qui notamment précise (Be a good citizen) qu'il est préférable d'éviter les globales, ce qui est en contradiction avec le point #1 de l'article cité (concernant AMD)...
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
Patrick Stadelmann
In article <1gmznxa.ueytvgyttp7wN%, (Pierre-Alain Dorange) wrote:
Qui notamment précise (Be a good citizen) qu'il est préférable d'éviter les globales, ce qui est en contradiction avec le point #1 de l'article cité (concernant AMD)...
Non, il ne parlent pas exactement de la même chose mais l'idée est la même. Les variables globales sont de toutes façons à éviter indépendamment de la plateforme (c'est potentiellement une source de bugs difficiles à identifier).
Patrick -- Patrick Stadelmann
In article <1gmznxa.ueytvgyttp7wN%pdorange@pas-de-pub-merci.mac.com>,
pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) wrote:
Qui notamment précise (Be a good citizen) qu'il est préférable d'éviter
les globales, ce qui est en contradiction avec le point #1 de l'article
cité (concernant AMD)...
Non, il ne parlent pas exactement de la même chose mais l'idée est la
même. Les variables globales sont de toutes façons à éviter
indépendamment de la plateforme (c'est potentiellement une source de
bugs difficiles à identifier).
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Qui notamment précise (Be a good citizen) qu'il est préférable d'éviter les globales, ce qui est en contradiction avec le point #1 de l'article cité (concernant AMD)...
Non, il ne parlent pas exactement de la même chose mais l'idée est la même. Les variables globales sont de toutes façons à éviter indépendamment de la plateforme (c'est potentiellement une source de bugs difficiles à identifier).
Patrick -- Patrick Stadelmann
DINH Viêt Hoà
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 ?
-- DINH V. Hoa,
"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.
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 ?
--
DINH V. Hoa,
"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.
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 ?
-- DINH V. Hoa,
"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.
DINH Viêt Hoà
Non, il ne parlent pas exactement de la même chose mais l'idée est la même. Les variables globales sont de toutes façons à éviter indépendamment de la plateforme (c'est potentiellement une source de bugs difficiles à identifier).
Tu veux préciser quand tu dis que ça peut-être une source de bugs ? Je ne vois pas trop comme ça ... Pour moi, c'est juste un problème de maintenabilité les variables globales.
-- DINH V. Hoa,
"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.
Non, il ne parlent pas exactement de la même chose mais l'idée est la
même. Les variables globales sont de toutes façons à éviter
indépendamment de la plateforme (c'est potentiellement une source de
bugs difficiles à identifier).
Tu veux préciser quand tu dis que ça peut-être une source de bugs ?
Je ne vois pas trop comme ça ...
Pour moi, c'est juste un problème de maintenabilité les variables
globales.
--
DINH V. Hoa,
"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.
Non, il ne parlent pas exactement de la même chose mais l'idée est la même. Les variables globales sont de toutes façons à éviter indépendamment de la plateforme (c'est potentiellement une source de bugs difficiles à identifier).
Tu veux préciser quand tu dis que ça peut-être une source de bugs ? Je ne vois pas trop comme ça ... Pour moi, c'est juste un problème de maintenabilité les variables globales.
-- 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:
Tu veux préciser quand tu dis que ça peut-être une source de bugs ? Je ne vois pas trop comme ça ... Pour moi, c'est juste un problème de maintenabilité les variables globales.
C'est de cela que je parle.
Patrick -- Patrick Stadelmann
In article <etPan.419109bd.55e0bbde.143d@utopia>,
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
Tu veux préciser quand tu dis que ça peut-être une source de bugs ?
Je ne vois pas trop comme ça ...
Pour moi, c'est juste un problème de maintenabilité les variables
globales.
C'est de cela que je parle.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Tu veux préciser quand tu dis que ça peut-être une source de bugs ? Je ne vois pas trop comme ça ... Pour moi, c'est juste un problème de maintenabilité les variables globales.
C'est de cela que je parle.
Patrick -- Patrick Stadelmann
DINH Viêt Hoà
In article , DINH Viêt Hoà wrote:
Tu veux préciser quand tu dis que ça peut-être une source de bugs ? Je ne vois pas trop comme ça ... Pour moi, c'est juste un problème de maintenabilité les variables globales.
C'est de cela que je parle.
Je ne vois alors pas dans quel sens c'est difficile à identifier. Quand je parle de maintenabilité, il s'agit bien d'extensibilité du programme. Ca n'a rien à voir avec des histoires de bugs (ou presque).
-- DINH V. Hoa,
"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.
In article <etPan.419109bd.55e0bbde.143d@utopia>,
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
Tu veux préciser quand tu dis que ça peut-être une source de bugs ?
Je ne vois pas trop comme ça ...
Pour moi, c'est juste un problème de maintenabilité les variables
globales.
C'est de cela que je parle.
Je ne vois alors pas dans quel sens c'est difficile à identifier.
Quand je parle de maintenabilité, il s'agit bien d'extensibilité du
programme. Ca n'a rien à voir avec des histoires de bugs (ou presque).
--
DINH V. Hoa,
"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.
Tu veux préciser quand tu dis que ça peut-être une source de bugs ? Je ne vois pas trop comme ça ... Pour moi, c'est juste un problème de maintenabilité les variables globales.
C'est de cela que je parle.
Je ne vois alors pas dans quel sens c'est difficile à identifier. Quand je parle de maintenabilité, il s'agit bien d'extensibilité du programme. Ca n'a rien à voir avec des histoires de bugs (ou presque).
-- DINH V. Hoa,
"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.
