|
From: Marco C. <ma...@in...> - 2004-07-29 09:03:01
|
Dear all,
I am experiencing a problem with C++ STL data structures.
If I run the code below and I add some time checkers I notice that the
first for-loop is executed slower than all the successive passages on
the loop. Example:
g++ -O3 prova.cpp
0.85
0.64
0.64
0.64
0.63
0.63
g++ -O0 prova.cpp
5.61
5.4
5.39
5.39
5.4
5.41
I assume this is due to the fact that STL use memory pool. This would
also explain the reason why if I run valgrind on the program I detect
memory leackage:
==17834== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==17834== malloc/free: in use at exit: 101211944 bytes in 145 blocks.
==17834== malloc/free: 151 allocs, 6 frees, 101355944 bytes allocated.
==17834==
==17834== searching for pointers to 145 not-freed blocks.
==17834== checked 84661520 bytes.
==17834==
==17834== 101211944 bytes in 145 blocks are still reachable in loss
record 1 of
1
==17834== at 0x4002F202: operator new(unsigned)
(vg_replace_malloc.c:162)
==17834== by 0x402C600A: std::__new_alloc::allocate(unsigned)
(stl_alloc.h:10
8)
==17834== by 0x402C5D62: std::__default_alloc_template<true,
0>::_S_chunk_all
oc(unsigned, int&) (stl_alloc.h:506)
==17834== by 0x402C5BAE: std::__default_alloc_template<true,
0>::_S_refill(un
signed) (stl_alloc.h:550)
==17834==
==17834== LEAK SUMMARY:
==17834== definitely lost: 0 bytes in 0 blocks.
==17834== possibly lost: 0 bytes in 0 blocks.
==17834== still reachable: 101211944 bytes in 145 blocks.
==17834== suppressed: 0 bytes in 0 blocks.
Until here therefore nothing really strange. The problem I have is in
another more exstensive code. There, I make a similar use of the STL
data structures even though the data I handle are much larger: >> 100 MB
(I use a machine with 1 GB RAM).
In this case I obtain an opposite behaviour. The first passage in the
loop is the faster with respect to the others. Valgrind gives me the
same response as above (but this time with much larger size of
Do you have any explanation why this is happening? An idea would be to
try to check how much memory inside the pool is actually allocated and
deallocated everytime the STL data structures are created and
destroyed. But I do not know how to do this. Could you help me?
Thank you in advance,
Marco
------------------------------------
#include <vector>
#include <set>
using namespace std;
typedef unsigned int Vertex;
typedef set<Vertex> VertexSet;
class Pippo {
public:
Pippo(size_t size) {
adjacency_set.resize(size);
};
~Pippo() {};
vector< VertexSet > adjacency_set;
};
int main( int argc, char** argv ) {
Vertex num_of_vertices = 2000;
for (int i = 0; i < 6; i++)
{
Pippo A(num_of_vertices);
for (Vertex i=0;i<num_of_vertices;i++)
for (Vertex j=0;j<num_of_vertices;j++)
A.adjacency_set[i].insert(j);
}
return 1;
}
----------------------------------------
---
I use:
Debian GNU/Linux
g++ (GCC) 3.3.4 (Debian 1:3.3.4-4)
valgrind-2.1.0
|
|
From: Scott T. S. <sc...@ge...> - 2004-07-29 16:50:25
|
On Thu, 2004-07-29 at 01:23, Marco Chiarandini wrote: > Dear all, > > I am experiencing a problem with C++ STL data structures. > > Until here therefore nothing really strange. The problem I have is in > another more exstensive code. There, I make a similar use of the STL > data structures even though the data I handle are much larger: >> 100 MB > (I use a machine with 1 GB RAM). > > In this case I obtain an opposite behaviour. The first passage in the > loop is the faster with respect to the others. Valgrind gives me the > same response as above (but this time with much larger size of it might be because on the first iteration, you get cache locality (since things are being allocated in order), but in subsequent iterations, they aren't (since the order of STL allocations is the reverse of the order they were freed). Scott |
|
From: Elijah P N. <ne...@ma...> - 2004-07-29 17:07:49
|
On Thu, 2004-07-29 at 10:23 +0200, Marco Chiarandini wrote: > I am experiencing a problem with C++ STL data structures. <snip> > I assume this is due to the fact that STL use memory pool. This would > also explain the reason why if I run valgrind on the program I detect > memory leackage: > > ==17834== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > ==17834== malloc/free: in use at exit: 101211944 bytes in 145 blocks. > ==17834== malloc/free: 151 allocs, 6 frees, 101355944 bytes allocated. > ==17834== > ==17834== searching for pointers to 145 not-freed blocks. > ==17834== checked 84661520 bytes. > ==17834== > ==17834== 101211944 bytes in 145 blocks are still reachable in loss > record 1 of > 1 <snip> > An idea would be to > try to check how much memory inside the pool is actually allocated and > deallocated everytime the STL data structures are created and > destroyed. But I do not know how to do this. Could you help me? It'd be better to just export GLIBCPP_FORCE_NEW=1 in your environment (assuming gcc 3.2.2 or later) before running. For more info (or if you have an earlier version of gcc), see FAQ 4.3 (which can be found at http://valgrind.kde.org/faq.html) Hope this helps, Elijah |
|
From: Marco C. <ma...@in...> - 2004-07-29 17:14:11
|
> > > An idea would be to > > try to check how much memory inside the pool is actually allocated and > > deallocated everytime the STL data structures are created and > > destroyed. But I do not know how to do this. Could you help me? > > It'd be better to just export GLIBCPP_FORCE_NEW=1 in your environment > (assuming gcc 3.2.2 or later) before running. For more info (or if you > have an earlier version of gcc), see FAQ 4.3 (which can be found at > http://valgrind.kde.org/faq.html) I tried this with the brief code posted and now it happens that the first passage in the loop is the fastest with respect to all the others. Which is exactly what happens with my extended code, but not what I want. I would like that there be no difference between the first passage and all the othres. I run valgrind without memory pool and now there is no memory leackage at all in both codes (the reduced posted and the extended I use). Which is then the reason because the first passage is different in performance with respect to the others? Thanks, Marco |