Front page | perl.perl5.porters |
Postings from November 2012
---------------------------------------- > Date: Thu, 1 Nov 2012 08:45:01 +0100 > Subject: Re: Eliminating the "rehash" mechanism for 5.18 > From: demerphq@gmail.com > To: bulk88@hotmail.com > CC: perl5-porters@perl.org; nick@ccl4.org; rjbs@manxome.org > > On 1 November 2012 08:23, bulk 88 <bulk88@hotmail.com> 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. http://www.cpantesters.org/distro/E/Example-XS-FasterHashes.html > > > 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 welcomeThread Previous | Thread Next