J'explique le probl=E8me recontr=E9 :
Je lance sur une machine 64 bits windows un programme soit en mode 64
soit en mode 32.
Lorsque je le lance en mode 32 bits il est beaucoup plus lent qu'en
mode 64.
Mon programme contient beaucoup de stl::vector (resize/reserve/
access).
Note :
Sous windows je compile avec visual 2008.
Sous linux 64 bits les timings sont correct (=E0 peu pres les memes
temps en 32 et 64 bits).
Pensez vous qu'il s'agit d'un probl=E8me li=E9 =E0 la STL ? (Comme le
probl=E8me n'est rencontr=E9 que sur des machines 32 bits).
J'ai test=E9 sur des machines windows purement 32 bits et les timings
sont lent aussi.
Merci d'avance d'engager la discussion.
Cordialement,
Pierre
>Lorsque je le lance en mode 32 bits il est beaucoup plus lent
D'une manière générale, si tu veux savoir pourquoi un programme est lent, la seule solution fiable est d'utiliser un profiler.
Bonjour, Merci pour tes réponses. Connais tu un profiler gratuit sous visual 2008 ?
Note : Les options de compilation sont les options par défaut.
Fabien LE LEZ
On Fri, 3 Jul 2009 00:18:30 -0700 (PDT), TheFrenchLeaf :
Connais tu un profiler gratuit sous visual 2008 ?
Il me semble que certaines versions de VS 2008 intègrent un profiler. Sinon, LTprof est d'un prix raisonnable (et a, je crois, une version de démo limitée dans le temps).
Note : Les options de compilation sont les options par défaut.
C'est peut-être là le problème. Si tu as un souci de performances, il faut bien étudier toutes les options liées à l'optimisation. A priori, le compilateur i386 et le compilateur AMD64 sont deux compilos différents ; il ne serait pas étonnant que les options optimales soient différentes.
Du côté des options de compilation, on voit parfois des trucs marrants : par exemple, j'ai un programme qui n'est rapide que compilé en -O1 ; les options -O2 et -O3, censées améliorer l'optimisation, rendent le programme bien plus lent. J'ai aussi vu un programme d'une centaine de lignes compiler et fonctionner rapidement sans optimisation, mais bloquer complètement VC++ 2008 avec /O1 (le compilateur n'arrivait pas à s'en sortir ; je l'ai arrêté de force au bout de quelques minutes).
On Fri, 3 Jul 2009 00:18:30 -0700 (PDT), TheFrenchLeaf :
Connais tu un profiler gratuit sous visual 2008 ?
Il me semble que certaines versions de VS 2008 intègrent un profiler.
Sinon, LTprof est d'un prix raisonnable (et a, je crois, une version
de démo limitée dans le temps).
Note : Les options de compilation sont les options par défaut.
C'est peut-être là le problème. Si tu as un souci de performances, il
faut bien étudier toutes les options liées à l'optimisation.
A priori, le compilateur i386 et le compilateur AMD64 sont deux
compilos différents ; il ne serait pas étonnant que les options
optimales soient différentes.
Du côté des options de compilation, on voit parfois des trucs
marrants : par exemple, j'ai un programme qui n'est rapide que compilé
en -O1 ; les options -O2 et -O3, censées améliorer l'optimisation,
rendent le programme bien plus lent.
J'ai aussi vu un programme d'une centaine de lignes compiler et
fonctionner rapidement sans optimisation, mais bloquer complètement
VC++ 2008 avec /O1 (le compilateur n'arrivait pas à s'en sortir ; je
l'ai arrêté de force au bout de quelques minutes).
On Fri, 3 Jul 2009 00:18:30 -0700 (PDT), TheFrenchLeaf :
Connais tu un profiler gratuit sous visual 2008 ?
Il me semble que certaines versions de VS 2008 intègrent un profiler. Sinon, LTprof est d'un prix raisonnable (et a, je crois, une version de démo limitée dans le temps).
Note : Les options de compilation sont les options par défaut.
C'est peut-être là le problème. Si tu as un souci de performances, il faut bien étudier toutes les options liées à l'optimisation. A priori, le compilateur i386 et le compilateur AMD64 sont deux compilos différents ; il ne serait pas étonnant que les options optimales soient différentes.
Du côté des options de compilation, on voit parfois des trucs marrants : par exemple, j'ai un programme qui n'est rapide que compilé en -O1 ; les options -O2 et -O3, censées améliorer l'optimisation, rendent le programme bien plus lent. J'ai aussi vu un programme d'une centaine de lignes compiler et fonctionner rapidement sans optimisation, mais bloquer complètement VC++ 2008 avec /O1 (le compilateur n'arrivait pas à s'en sortir ; je l'ai arrêté de force au bout de quelques minutes).
TheFrenchLeaf
Je regarde la avec AMD CodeAnalyst, mais je ne sais pas si je vais voir ce qui bloque.
Je regarde la avec AMD CodeAnalyst, mais je ne sais pas si je vais
voir ce qui bloque.
Je regarde la avec AMD CodeAnalyst, mais je ne sais pas si je vais voir ce qui bloque.
Wykaaa
Fabien LE LEZ a écrit :
[snip]
J'ai aussi vu un programme d'une centaine de lignes compiler et fonctionner rapidement sans optimisation, mais bloquer complètement VC++ 2008 avec /O1 (le compilateur n'arrivait pas à s'en sortir ; je l'ai arrêté de force au bout de quelques minutes).
C'est forcément un bug de l'optimiseur. Certains algorithmes d'optimisation doivent être passés dans un certain ordre sinon ça ne converge jamais (un algo défait l'optimisation qu'un précédent a fait). Il y a plusieurs passes sur l'optimisation, en général. L'idéal est d'arrêter les itérations quand "plus rien ne bouge" (convergence), mais en général, on s'arrête avant car sinon la phase d'optimisation peut prendre jusqu'à 99% du temps de compil ! Dans les années 70, je faisais des calculs d'entropie de matrices markoviennes en Fortran, j'avais dû réduire le niveau d'optimisation car sinon, j'avais des arguments de logarithmes qui devenaient négatifs ! (Compilateur Fortran IV sur un IBM 360). Il avait fallu plonger dans le "dump" pour voir que ça venait de l'optimisation...
Fabien LE LEZ a écrit :
[snip]
J'ai aussi vu un programme d'une centaine de lignes compiler et
fonctionner rapidement sans optimisation, mais bloquer complètement
VC++ 2008 avec /O1 (le compilateur n'arrivait pas à s'en sortir ; je
l'ai arrêté de force au bout de quelques minutes).
C'est forcément un bug de l'optimiseur. Certains algorithmes
d'optimisation doivent être passés dans un certain ordre sinon ça ne
converge jamais (un algo défait l'optimisation qu'un précédent a fait).
Il y a plusieurs passes sur l'optimisation, en général. L'idéal est
d'arrêter les itérations quand "plus rien ne bouge" (convergence), mais
en général, on s'arrête avant car sinon la phase d'optimisation peut
prendre jusqu'à 99% du temps de compil !
Dans les années 70, je faisais des calculs d'entropie de matrices
markoviennes en Fortran, j'avais dû réduire le niveau d'optimisation car
sinon, j'avais des arguments de logarithmes qui devenaient négatifs !
(Compilateur Fortran IV sur un IBM 360).
Il avait fallu plonger dans le "dump" pour voir que ça venait de
l'optimisation...
J'ai aussi vu un programme d'une centaine de lignes compiler et fonctionner rapidement sans optimisation, mais bloquer complètement VC++ 2008 avec /O1 (le compilateur n'arrivait pas à s'en sortir ; je l'ai arrêté de force au bout de quelques minutes).
C'est forcément un bug de l'optimiseur. Certains algorithmes d'optimisation doivent être passés dans un certain ordre sinon ça ne converge jamais (un algo défait l'optimisation qu'un précédent a fait). Il y a plusieurs passes sur l'optimisation, en général. L'idéal est d'arrêter les itérations quand "plus rien ne bouge" (convergence), mais en général, on s'arrête avant car sinon la phase d'optimisation peut prendre jusqu'à 99% du temps de compil ! Dans les années 70, je faisais des calculs d'entropie de matrices markoviennes en Fortran, j'avais dû réduire le niveau d'optimisation car sinon, j'avais des arguments de logarithmes qui devenaient négatifs ! (Compilateur Fortran IV sur un IBM 360). Il avait fallu plonger dans le "dump" pour voir que ça venait de l'optimisation...
TheFrenchLeaf
J'ai testé l'option O1, rien ne change...
Le problème semble venir des instructions de resize sur les vector que j'ai besoin d'appeler souvent.
Le scope ou se joue le relentissement fait beaucoup jouer la mémoire (accés tres sparse de la mémoire et demande d'allocation désallocation).
Quand j'essai de minimiser les cycles allocations dé-sallocation les temps décole en 32 bits.
Juste pour voir je vais tester avec le DougLea memory allocator.
J'ai testé l'option O1, rien ne change...
Le problème semble venir des instructions de resize sur les vector
que j'ai besoin d'appeler souvent.
Le scope ou se joue le relentissement fait beaucoup jouer la mémoire
(accés tres sparse de la mémoire et demande d'allocation
désallocation).
Quand j'essai de minimiser les cycles allocations dé-sallocation les
temps décole en 32 bits.
Juste pour voir je vais tester avec le DougLea memory allocator.
Le problème semble venir des instructions de resize sur les vector que j'ai besoin d'appeler souvent.
Le scope ou se joue le relentissement fait beaucoup jouer la mémoire (accés tres sparse de la mémoire et demande d'allocation désallocation).
Quand j'essai de minimiser les cycles allocations dé-sallocation les temps décole en 32 bits.
Juste pour voir je vais tester avec le DougLea memory allocator.
James Kanze
On Jul 3, 9:18 am, TheFrenchLeaf wrote:
On 2 juil, 23:34, Fabien LE LEZ wrote:
Note : Les options de compilation sont les options par défaut.
Je ne connais pas la situation avec VC++ 64 bits---je n'ai que la version gratuite de VC++, qui ne support que le 32 bits. Mais au moins avec le 32 bits, les options par défaut comprenent un certain nombre de vérifications (ce qu'on a avec le mode débogguage avec g++). Vérifie par exemple qu'il n'y a pas de -D_DEBUG, si tu fais une utilisation extensive de la STL.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 3, 9:18 am, TheFrenchLeaf <pmou...@gmail.com> wrote:
On 2 juil, 23:34, Fabien LE LEZ <grams...@gramster.com> wrote:
Note : Les options de compilation sont les options par défaut.
Je ne connais pas la situation avec VC++ 64 bits---je n'ai que
la version gratuite de VC++, qui ne support que le 32 bits. Mais
au moins avec le 32 bits, les options par défaut comprenent un
certain nombre de vérifications (ce qu'on a avec le mode
débogguage avec g++). Vérifie par exemple qu'il n'y a pas de
-D_DEBUG, si tu fais une utilisation extensive de la STL.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Note : Les options de compilation sont les options par défaut.
Je ne connais pas la situation avec VC++ 64 bits---je n'ai que la version gratuite de VC++, qui ne support que le 32 bits. Mais au moins avec le 32 bits, les options par défaut comprenent un certain nombre de vérifications (ce qu'on a avec le mode débogguage avec g++). Vérifie par exemple qu'il n'y a pas de -D_DEBUG, si tu fais une utilisation extensive de la STL.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain SF
James Kanze a écrit :
On Jul 3, 9:18 am, TheFrenchLeaf wrote:
On 2 juil, 23:34, Fabien LE LEZ wrote:
Note : Les options de compilation sont les options par défaut.
Je ne connais pas la situation avec VC++ 64 bits
"par défaut" ne signifie pas "les pires" mais seulement "proposées par défaut", tant en 32 qu'un 64 bits, ces options /par défaut/ sont optimales pour la plupart des projets - ie niveau 'O2' en mode release (!) car bien sur en mode debug quasi toutes les optims sont désactivées.
Sylvain.
James Kanze a écrit :
On Jul 3, 9:18 am, TheFrenchLeaf <pmou...@gmail.com> wrote:
On 2 juil, 23:34, Fabien LE LEZ <grams...@gramster.com> wrote:
Note : Les options de compilation sont les options par défaut.
Je ne connais pas la situation avec VC++ 64 bits
"par défaut" ne signifie pas "les pires" mais seulement
"proposées par défaut", tant en 32 qu'un 64 bits, ces
options /par défaut/ sont optimales pour la plupart des
projets - ie niveau 'O2' en mode release (!) car bien sur
en mode debug quasi toutes les optims sont désactivées.
Note : Les options de compilation sont les options par défaut.
Je ne connais pas la situation avec VC++ 64 bits
"par défaut" ne signifie pas "les pires" mais seulement "proposées par défaut", tant en 32 qu'un 64 bits, ces options /par défaut/ sont optimales pour la plupart des projets - ie niveau 'O2' en mode release (!) car bien sur en mode debug quasi toutes les optims sont désactivées.
Sylvain.
James Kanze
On Jul 3, 5:47 pm, Sylvain SF wrote:
James Kanze a écrit :
> On Jul 3, 9:18 am, TheFrenchLeaf wrote: >> On 2 juil, 23:34, Fabien LE LEZ wrote:
>> Note : Les options de compilation sont les options par défaut.
> Je ne connais pas la situation avec VC++ 64 bits
"par défaut" ne signifie pas "les pires" mais seulement "proposées par défaut", tant en 32 qu'un 64 bits, ces options /par défaut/ sont optimales pour la plupart des projets - ie niveau 'O2' en mode release (!) car bien sur en mode debug quasi toutes les optims sont désactivées.
Je n'ai jamais dit « les pires ». A priori, tous les contrôles possibles doivent être activés par defaut, puisque dans la vaste majorité des programmes, la correction et la robustesse sont plus importantes que la vitesse (qui est typiquement limitée par la bande passante des entrées/sorties, plutôt que par les temps d'exécution CPU).
Dans la pratique, malheureusement, les options par défaut des compilateurs sont rarement utilisables. Avec les options par défaut de VC++, par exemple, j'ai un message d'avertissement (« C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc ») si j'utilise la bibiothèque standard, par exemple. En revanche, les contrôles sur l'utilisation des itérateurs sont bien activés (ce qui est bien). De même si j'utilise mes options habituelles pour l'optimisation : « -DNOMINMAX -D_CRT_SECURE_NO_DEPRECATE -vmg -GR -Gy -EHs -Zc:forScope,wchar_t -J -nologo -MD -Ox -Gs ». Ou si je remplace -Ox avec -O2. Si en revanche, j'ajoute l'option « -D_SECURE_SCL=0 », je n'ai plus les vérifications, au moins dans le petit programme d'essai que je viens d'écrire.
Ceci toujours avec le compilateur de la version gratuite de Visual Studio 9, donc en 32 bits. Je ne sais pas comment ça se passe avec d'autres versions, mais je pourrais imaginer que si pour une raison ou une autre, la compilation 64 bits définit _SECURE_SCL à 0, mais celle de 32 bits à 1 (ou ne la définit pas), la différence de performances sera notable.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 3, 5:47 pm, Sylvain SF <sylv...@boiteaspam.info> wrote:
James Kanze a écrit :
> On Jul 3, 9:18 am, TheFrenchLeaf <pmou...@gmail.com> wrote:
>> On 2 juil, 23:34, Fabien LE LEZ <grams...@gramster.com> wrote:
>> Note : Les options de compilation sont les options par défaut.
> Je ne connais pas la situation avec VC++ 64 bits
"par défaut" ne signifie pas "les pires" mais seulement
"proposées par défaut", tant en 32 qu'un 64 bits, ces options
/par défaut/ sont optimales pour la plupart des projets - ie
niveau 'O2' en mode release (!) car bien sur en mode debug
quasi toutes les optims sont désactivées.
Je n'ai jamais dit « les pires ». A priori, tous les contrôles
possibles doivent être activés par defaut, puisque dans la vaste
majorité des programmes, la correction et la robustesse sont
plus importantes que la vitesse (qui est typiquement limitée par
la bande passante des entrées/sorties, plutôt que par les temps
d'exécution CPU).
Dans la pratique, malheureusement, les options par défaut des
compilateurs sont rarement utilisables. Avec les options par
défaut de VC++, par exemple, j'ai un message d'avertissement
(« C++ exception handler used, but unwind semantics are not
enabled. Specify /EHsc ») si j'utilise la bibiothèque standard,
par exemple. En revanche, les contrôles sur l'utilisation des
itérateurs sont bien activés (ce qui est bien). De même si
j'utilise mes options habituelles pour l'optimisation :
« -DNOMINMAX -D_CRT_SECURE_NO_DEPRECATE -vmg -GR -Gy -EHs
-Zc:forScope,wchar_t -J -nologo -MD -Ox -Gs ». Ou si je
remplace -Ox avec -O2. Si en revanche, j'ajoute l'option
« -D_SECURE_SCL=0 », je n'ai plus les vérifications, au moins
dans le petit programme d'essai que je viens d'écrire.
Ceci toujours avec le compilateur de la version gratuite de
Visual Studio 9, donc en 32 bits. Je ne sais pas comment ça se
passe avec d'autres versions, mais je pourrais imaginer que si
pour une raison ou une autre, la compilation 64 bits définit
_SECURE_SCL à 0, mais celle de 32 bits à 1 (ou ne la définit
pas), la différence de performances sera notable.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
> On Jul 3, 9:18 am, TheFrenchLeaf wrote: >> On 2 juil, 23:34, Fabien LE LEZ wrote:
>> Note : Les options de compilation sont les options par défaut.
> Je ne connais pas la situation avec VC++ 64 bits
"par défaut" ne signifie pas "les pires" mais seulement "proposées par défaut", tant en 32 qu'un 64 bits, ces options /par défaut/ sont optimales pour la plupart des projets - ie niveau 'O2' en mode release (!) car bien sur en mode debug quasi toutes les optims sont désactivées.
Je n'ai jamais dit « les pires ». A priori, tous les contrôles possibles doivent être activés par defaut, puisque dans la vaste majorité des programmes, la correction et la robustesse sont plus importantes que la vitesse (qui est typiquement limitée par la bande passante des entrées/sorties, plutôt que par les temps d'exécution CPU).
Dans la pratique, malheureusement, les options par défaut des compilateurs sont rarement utilisables. Avec les options par défaut de VC++, par exemple, j'ai un message d'avertissement (« C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc ») si j'utilise la bibiothèque standard, par exemple. En revanche, les contrôles sur l'utilisation des itérateurs sont bien activés (ce qui est bien). De même si j'utilise mes options habituelles pour l'optimisation : « -DNOMINMAX -D_CRT_SECURE_NO_DEPRECATE -vmg -GR -Gy -EHs -Zc:forScope,wchar_t -J -nologo -MD -Ox -Gs ». Ou si je remplace -Ox avec -O2. Si en revanche, j'ajoute l'option « -D_SECURE_SCL=0 », je n'ai plus les vérifications, au moins dans le petit programme d'essai que je viens d'écrire.
Ceci toujours avec le compilateur de la version gratuite de Visual Studio 9, donc en 32 bits. Je ne sais pas comment ça se passe avec d'autres versions, mais je pourrais imaginer que si pour une raison ou une autre, la compilation 64 bits définit _SECURE_SCL à 0, mais celle de 32 bits à 1 (ou ne la définit pas), la différence de performances sera notable.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
