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