Again: STL map and pthread performance problem on Linux/GCC

[Alexander Kotelnikov]

Hello.

I faced the same problem which arose before
Message-ID: <[email protected]>
http://groups.google.com/group/comp...daa3/4fecba3342fe8d09?tvc=2&q=STL+map+threads

In short: can't gain any use of second, third etc processors when
std::map is used concurrently in multiple threads.

None of advices from that one year old thread (hoard,
GLIBCPP_FORCE_NEW, GLIBCXX_FORCE_NEW) help. I tried g++ 3.3, 3.4 and
4.1, also tried stlport instead of gcc's SGI-derived STL. All
experiments showed more or less poor results.

Is there a good way to run a multi-threaded program using stl::map on
SMP machine?

BTW I tested mostly on Linux and a bit on Solaris/SPARC with g++ 3.4
and 4.0 with SGI STL only.

Thanks,

 

[Alf P. Steinbach]

* Alexander Kotelnikov:

Hello.

I faced the same problem which arose before
Message-ID: <[email protected]>
http://groups.google.com/group/comp...daa3/4fecba3342fe8d09?tvc=2&q=STL+map+threads

In short: can't gain any use of second, third etc processors when
std::map is used concurrently in multiple threads.

None of advices from that one year old thread (hoard,
GLIBCPP_FORCE_NEW, GLIBCXX_FORCE_NEW) help. I tried g++ 3.3, 3.4 and
4.1, also tried stlport instead of gcc's SGI-derived STL. All
experiments showed more or less poor results.

Is there a good way to run a multi-threaded program using stl::map on
SMP machine?

BTW I tested mostly on Linux and a bit on Solaris/SPARC with g++ 3.4
and 4.0 with SGI STL only.

Thanks,

Well, the first code example presented in that thread ;-) was extremely UB.

Presumably you're using some more reliable code.

One problem is that standard library classes by default use the same
memory allocator, so that with a decent multi-thread support runtime
library you get /serialization/ of the internal calls to new and delete.
To fix that you need to provide a custom allocator (template
parameter), using one heap per thread, and if you share pointers between
threads, using some smart pointer with custom deallocation so that it
deallocates from the right heap for that pointer. Don't know whether
Boost provides a heap manager; as I recall there's one in Loki, though,
which perhaps can be adapted if it doesn't support multiple heaps out of
the box.

 

[Alexander Kotelnikov]

APS>
APS> Well, the first code example presented in that thread ;-) was extremely UB.
APS>
APS> Presumably you're using some more reliable code.
APS>
APS> One problem is that standard library classes by default use the same
APS> memory allocator

Actually, the reason, why it is so is pretty clear, the real question
was: there is no ready solution?

BTW I tried __mt_alloc, may be I've done something wrong, but it is
even worse then the default allocator.

 

[Mathias Gaunard]

I faced the same problem which arose before
Message-ID: <[email protected]>
http://groups.google.com/group/comp...daa3/4fecba3342fe8d09?tvc=2&q=STL+map+threads

I know this is unrelated to your problem but why are you using a string
as a key when what you need is an int?

 

[Alexander Kotelnikov]

MG>
MG>
MG> I know this is unrelated to your problem but why are you using a
MG> string as a key when what you need is an int?

In my case I use my own class a the key.

 

[Mathias Gaunard]

In my case I use my own class a the key.

Maybe you should learn how to make good testcases then.
It should be minimal and not add unneeded stuff in regard to the problem.

 

[Alexander Kotelnikov]

AK>
AK> BTW I tried __mt_alloc, may be I've done something wrong, but it is
AK> even worse then the default allocator.

Sorry. __mt_alloc helps. Not too much, but better than nothing.

 

[Mathias Gaunard]

None of advices from that one year old thread (hoard,

You have to actually specify a custom allocator if you want to use
std::map with hoard.
Linking with hoard isn't enough, it just replaces malloc.