[Bug libstdc++/13823] Significant performance issue with std::map on multiple threads on dual processor - possibly default allocator

[devison at pacificit dot co dot nz]

------- Additional Comments From devison at pacificit dot co dot nz  2004-01-23 12:48 -------
Subject: Re:  Significant performance issue with std::map
 on multiple threads on dual processor - possibly default allocator


> Please apply this patch and rerun your test (it would also be great if
> you could tell us whether your real application code sees major
> improvement using this allocator with an MP machine; I know that might
> be a little more work)...


Hi Loren,

well, the patch improved things significantly on the test.  For example:
one thread, one cpu:   17.4s
two threads, one cpu:  35.0s
two threads, two cpus: 29.5s

So now, it seems that when the two threads are running the performance is
only slightly lower on two cpus than on one.  ie this is about 4 times
faster than the previous version.  Of course, it is still unfortunate that
it is *slower* with an extra cpu.

I've been working to integrate this into my application to test it properly,
and it has been a real hassle!  Luckily I use typedefs for every container
class type, but still have 20 std::set types, 58 std::map types, 13
std::hash_map types, 97 std::vector types and 8 std::deque types.  I've used
the "template typdef" technique described in:
http://www.gotw.ca/gotw/079.htm  so at least I can now change which
allocator is used in one place.

I also make extensive use of std::string which also (of course) uses the
allocator.   Redefining a new string type using the mt_allocator has been a
major hassle.  I'm using lots of other libraries that return and accept
ordinary std::strings, and of course the two strings aren't interchangeable.
Also I've started defining new instantiations of basic_ostringstream rather
than using ostringstream, etc.

There's got to be a better way!

any ideas...?

thanks,
Dan






-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13823