From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22762 invoked by alias); 23 Jan 2004 12:48:37 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 22751 invoked by alias); 23 Jan 2004 12:48:36 -0000 Date: Fri, 23 Jan 2004 12:48:00 -0000 Message-ID: <20040123124836.22750.qmail@sources.redhat.com> From: "devison at pacificit dot co dot nz" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040123001452.13823.devison@pacificit.co.nz> References: <20040123001452.13823.devison@pacificit.co.nz> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/13823] Significant performance issue with std::map on multiple threads on dual processor - possibly default allocator X-Bugzilla-Reason: CC X-SW-Source: 2004-01/txt/msg02916.txt.bz2 List-Id: ------- 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