This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/13823] Significant performance issue with std::map on multiple threads on dual processor - possibly default allocator
- From: "devison at pacificit dot co dot nz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 23 Jan 2004 05:31:26 -0000
- Subject: [Bug libstdc++/13823] Significant performance issue with std::map on multiple threads on dual processor - possibly default allocator
- References: <20040123001452.13823.devison@pacificit.co.nz>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From devison at pacificit dot co dot nz 2004-01-23 05:31 -------
Subject: Re: Significant performance issue with std::map
on multiple threads on dual processor - possibly default allocator
Hi,
I obtained the latest ext/mt_allocator.h file from cvs, and reran the test
using it. Otherwise I'm still using the gcc 3.3.2 headers. BTW, I needed
to make one addition to make it compile:
namespace __gnu_cxx { using std::__throw_bad_alloc; }
On my machine, it showed an improvement of around 30%, which is good, but is
still running into a significant bottleneck. (Still 4 times slower than on
a single cpu).
Has anyone seen other results?
By the way, while this example program is a little perverse, I was getting a
similar performance hit in my application in which I was trying to speed
things up with a second calculation thread. The calculations I am doing
require creating tables of temporary results.
thanks,
Dan
----- Original Message -----
From: "ljrittle at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: <devison@pacificit.co.nz>
Sent: Friday, January 23, 2004 4:58 PM
Subject: [Bug libstdc++/13823] Significant performance issue with std::map
on multiple threads on dual processor - possibly default allocator
>
> ------- Additional Comments From ljrittle at gcc dot gnu dot org
2004-01-23 03:58 -------
> Try this (we might change the default allocator to make it work better for
MP
> at the next major library revision --- ABI change, but 3.4 will support
this
> allocator
> with very good performance for people that wish to tune their
application):
>
> #include <iostream>
> #include <map>
> #include <ext/mt_allocator.h>
>
> void *calc(void *n)
> {
> std::map<int, int, std::less<const int>,
> __gnu_cxx::__mt_alloc< std::pair<const int, int> > > m;
>
> for (unsigned i = 0; i < 100000; ++i)
> m[i] = i;
>
> return 0;
> }
>
> int main(int argc, char *argv[])
> {
> int n = argc == 2 ? std::max(atoi(argv[1]), 1) : 2;
>
> pthread_t id[n];
>
> for (int i = 0; i < n; ++i)
> pthread_create(&id[i], 0, calc, new int(i));
>
> for (int i = 0; i < n; ++i)
> pthread_join(id[i], 0);
>
> return 0;
> }
>
> --
> What |Removed |Added
> --------------------------------------------------------------------------
--
> Status|NEW |SUSPENDED
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13823
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13823