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

[FranÃois Dumont <frs dot dumont at gmail dot com>]

    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