http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #12 from Dennis Lubert plasmahh at gmx dot net 2012-07-26
12:30:00 UTC ---
I can confirm that now the reserve works as I would expect it (causing no
further rehashes). However the amount of rehashes done in the testcase is still
155
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #13 from François Dumont fdumont at gcc dot gnu.org 2012-07-26
12:31:56 UTC ---
Author: fdumont
Date: Thu Jul 26 12:31:50 2012
New Revision: 189889
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189889
Log:
2012-07-26 François
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-26
17:36:28 UTC ---
In any case, please add the testcase showing 4.5s vs 1.5s.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #15 from likan_999.student at sina dot com 2012-07-26 22:10:21 UTC
---
Tried the patch and just as Dennis Lubert pointed out, the number of rehashes
is not decreased. Is there any plan to fix this issue?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #16 from Chip Salzenberg chip at pobox dot com 2012-07-26
22:50:17 UTC ---
In my tests, with this patch, 4.7.1 is about 10% slower than 4.6 ... a vast
improvement but certainly not parity.
./bench46 1.75s user 0.82s system 99% cpu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-26
22:55:15 UTC ---
Because of more rehashing, unrelated to reserve, I suppose?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-25
09:56:15 UTC ---
A patch is available here:
http://gcc.gnu.org/ml/libstdc++/2012-07/msg00051.html
Submitter and interested people can give it a try before it goes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #11 from François Dumont fdumont at gcc dot gnu.org 2012-07-25
19:32:53 UTC ---
Author: fdumont
Date: Wed Jul 25 19:32:48 2012
New Revision: 189863
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189863
Log:
2012-07-25 François
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
Dennis Lubert plasmahh at gmx dot net changed:
What|Removed |Added
CC||plasmahh at gmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #9 from François Dumont fdumont at gcc dot gnu.org 2012-07-24
20:15:10 UTC ---
I confirm that the reserve method is broken. I had correctly handle the size
hint that can be given through the hashtable constructor, I set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
François Dumont fdumont at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #1 from likan_999.student at sina dot com 2012-07-23 23:08:07 UTC
---
Created attachment 27861
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27861
Profiling using google-perftools
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #2 from likan_999.student at sina dot com 2012-07-23 23:09:43 UTC
---
Created attachment 27862
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27862
Profiling of gcc-4.6.2 using google-perftools
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-23
23:23:27 UTC ---
I wonder, anyway, if the apparent slow down is just an artifact caused by a
different handling of the load factor in the reworked unordered containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #5 from likan_999.student at sina dot com 2012-07-24 00:17:10 UTC
---
@Paolo Carlini: can you talk more about how to experiment with max_load_factor?
As long as I use the same max_load_factor for 4.6 and 4.7, I can still see the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-24
00:29:38 UTC ---
In some cases 4.6.x was handling max_load_factor incorrectly. Thus, the idea
isn't comparing 4.6.x to 4.7.x with the same max_load_factor (I don't think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #7 from likan_999.student at sina dot com 2012-07-24 00:42:57 UTC
---
@Paolo Carlini: the problem is, with different max_load_factor in range
[0.2-5], the *best* result of 4.7.1 is still 2x slower than the *worst* of
4.6.2.
I
18 matches
Mail list logo
