Différence de temps d'execution 32/64 bits

Le
TheFrenchLeaf
Bonjour,

J'explique le problème recontré :
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 (à peu pres les memes
temps en 32 et 64 bits).

Pensez vous qu'il s'agit d'un problème lié à la STL ? (Comme le
problème n'est rencontré que sur des machines 32 bits).
J'ai testé sur des machines windows purement 32 bits et les timings
sont lent aussi.

Merci d'avance d'engager la discussion.
Cordialement,
Pierre
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fabien LE LEZ
Le #19684731
On Thu, 2 Jul 2009 08:37:27 -0700 (PDT), TheFrenchLeaf

Lorsque je le lance en mode 32 bits il est beaucoup plus lent qu'en
mode 64.



Quelles sont les options de compilation utilisées ?
Fabien LE LEZ
Le #19685561
TheFrenchLeaf
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.
TheFrenchLeaf
Le #19686331
On 2 juil, 23:34, Fabien LE LEZ
TheFrenchLeaf
>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
Le #19686721
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
Le #19686921
Je regarde la avec AMD CodeAnalyst, mais je ne sais pas si je vais
voir ce qui bloque.
Wykaaa
Le #19688471
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...
TheFrenchLeaf
Le #19688771
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.
James Kanze
Le #19689141
On Jul 3, 9:18 am, TheFrenchLeaf
On 2 juil, 23:34, Fabien LE LEZ


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
Le #19689251
James Kanze a écrit :
On Jul 3, 9:18 am, TheFrenchLeaf
On 2 juil, 23:34, Fabien LE LEZ


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
Le #19692641
On Jul 3, 5:47 pm, Sylvain SF
James Kanze a écrit :



> On Jul 3, 9:18 am, TheFrenchLeaf >> On 2 juil, 23:34, Fabien LE LEZ


>> 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
Publicité
Poster une réponse
Anonyme