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

["rittle at latour dot rsch dot comm dot mot dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From rittle at latour dot rsch dot comm dot mot dot com  2004-01-23 20:47 -------
Subject: Re:  Significant performance issue with std::map on
	multiple threads on dual processor - possibly default allocator


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

OK, that is good to see.  I agree with your analysis; it is
unfortunate that some work loads don't scale (with our allocators)...

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

Sorry about that.  All I can say is that reports on whether this
allocator helps real applications will help us decide whether it can
become the new default allocator.

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

You might try selectively changing allocators in your system.  Perhaps
try only changing the containers but not strings.

Regards,
Loren


-- 


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