develooper Front page | perl.perl5.porters | Postings from November 2012

RE: Eliminating the "rehash" mechanism for 5.18

Thread Previous | Thread Next
bulk 88
November 1, 2012 01:55
RE: Eliminating the "rehash" mechanism for 5.18
Message ID:

> Date: Thu, 1 Nov 2012 08:45:01 +0100
> Subject: Re: Eliminating the "rehash" mechanism for 5.18
> From:
> To:
> CC:;;
> On 1 November 2012 08:23, bulk 88 <> wrote:
> > I disagree there is a measurable cost to the current implementation of
> > REHASH. If the rehash code is so rare, maybe it should be removed from
> > hv_common and placed in its own func, but looking at the asm, the
> > overhead is so tiny I dont think the rehash code even matters compared
> > to the rest of the design of hv_common. I don't see any performance
> > gains by removing it.
> Yes, I am unable to show any actual performance gains either.
> I still believe the rehash mechanism should be removed to reduce
> complexity in the code and to prevent code from ossifying around a
> given hash order and to ensure that edge case bugs are tickled.
> Changing to a different hash algorithm will break as many tests as
> hash randomization and as I have posted elsewhere there IS a clear
> performance win in doing so. The future may bring further better hash
> functions so I would like to see hash randomization go in to future
> proof ourselves against those changes.
Then that is the real purpose of this thread, not performance issues.
> > In the past I've done benchmarking on pre
> > calculating the hash number to give to hv_common_key_len. I couldn't
> > get a consistent benchmark difference between with and without
> > the hash number when calling hv_common_key_len in a loop. Having
> > the PV in the HEK and the char * given hv_common_key_len be
> > exactly the same gave a measurable improvement for me in the same
> > hv_common_key_len in a loop benchmark situation.
> Can you explain a bit more the latter point?
My experiments with XS hash api, I have more code to add to it
including cutting down the creation time of a new hash with a preset
list of keys by, I think 50%, its not up on CPAN, but it does rely
on newHVhv returning a hash with identical internal layout everytime
it is called from a template hash.
> > For the asm code,
> > masked_flags (stack var reused) was earlier set to HvREHASH(hv)
> > as an optimization by the compiler. The whole overhead in the
> > hash algorithm macro to support rehash is the following. Just
> > a t/f conditional between 2 32 bit read. ebx contains my_perl.
> Thanks for the detailed analysis. It is very interesting.
your welcome 		 	   		  
Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About