[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2

[François Dumont]

     I hadn't noticed, sorry. The only explanation is the modification 
on the hash policy. Moving the grow factor changed the list of prime 
numbers used while the hashtable grow. Removing shrinking avoid a 
lower_bound call. I am surprised of the impact but I only see this 
explanation.

     Whatever the version without cache has still a small advantage for 
fewer memory so IMO the patch is still relevant.

François


On 11/29/2012 11:01 PM, Paolo Carlini wrote:
> Hi,
>
>> On 11/23/2012 11:24 PM, Paolo Carlini wrote:
>>> Hi,
>>>
>>> On 11/23/2012 10:59 PM, François Dumont wrote:
>>>>  But I think I won't lose my time anymore on this approach and will 
>>>> rather prepare a small patch to change default behavior regarding 
>>>> the hash code. I agree with all your remarks Jonathan so I will use 
>>>> them for the patch.
>>> First thanks a lot for all the time you are spending on this. That 
>>> said, I want to make sure the following is recorded: as far as I can 
>>> see in the current 54075.cc performance testcase (I also ran it 
>>> myself) there isn't much difference between the cached / non-cached 
>>> cases, right? That worries me a lot, because the whole discussion 
>>> about caching, if I remember correctly, started when, basing on some 
>>> preliminary performance numbers:
>>>
>>> http://gcc.gnu.org/ml/libstdc++/2012-11/msg00102.html
>> Well, this test is showing a difference.
>
> Indeed, that's exactly my point: why now the difference is much smaller:
>
> http://gcc.gnu.org/ml/libstdc++/2012-11/msg00124.html
>
> ???
>
> I'd like to understand this, before changing the default policy (I'm 
> of course talking about the std:: containers, not the tr1 version)
>
> Paolo