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

On Thu, 2 Jul 2009 08:37:27 -0700 (PDT), TheFrenchLeaf
<thefrenchleaf@gmail.com>:

>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 ?

TheFrenchLeaf <thefrenchleaf@gmail.com>:

>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.

On 2 juil, 23:34, Fabien LE LEZ <grams...@gramster.com> wrote:
> TheFrenchLeaf <thefrenchl...@gmail.com>:
>
> >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.

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).

Je regarde la avec AMD CodeAnalyst, mais je ne sais pas si je vais
voir ce qui bloque.

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 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.

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

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.

Sylvain.

Merci à tous pour vos surggestions et réponses.

On 6 juil, 10:00, TheFrenchLeaf <pmou...@gmail.com> wrote:
> Merci à tous pour vos surggestions et réponses.

I have done some additional test. And it seems that when I call resize
(0) or clear() in loop on std::vector<pointer> it took a lot of time.
the basic algo is like that :

{
vector<truc> A;

for()
{
A.reserve( nCount );
for()
{
forfor()
{
A.push_back( truc ) ;
}
}
A.resize(0); //it keep the allocated memory but reset size to 0
(I'm right)
}
}

But the strangest thing if I done the following (the code run faster
that the previous version (but the memory allocation de/allocation is
more important):

{
for()
{
vector<truc> A;
A.reserve( nCount );
for()
{
forfor()
{
A.push_back( truc ) ;
}
}
A.resize(0); //it keep the allocated memory but reset size to 0
(I'm right)
}
}

I'm trying the -D_SECURE_SCL=0 option.

Juste pour finir la discussion.

Le bottleneck qui apparait est en fait dans le cache miss L2.
Il semblerait que mon programme introduise bcp de lecture distante en
mémoire et soit donc lent en 32 bits et plus rapide en 64 bits....