Patch for hash-split bug when building perl using Accflags=-DPERL_PERTURB_KEYS_DISABLED #16661
Comments
From 11000@gmx.de0001-fixed-no-hashsplit-bug-when-copiled-with-accflags-DP.patchFrom 461113acafe116f85fee7c30a6a54647edf141be Mon Sep 17 00:00:00 2001
From: fnp <fnordpole@gmail.com>
Date: Mon, 20 Aug 2018 23:38:29 +0200
Subject: [PATCH] fixed no-hashsplit bug when copiled with
accflags=-DPERL_PERTURB_KEYS_DISABLED
---
hv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hv.c b/hv.c
index d3d02d1046..7c33fc19c4 100644
--- a/hv.c
+++ b/hv.c
@@ -834,13 +834,13 @@ Perl_hv_common(pTHX_ HV *hv, SV *keysv, const char *key, STRLEN klen,
HeKEY_hek(entry) = save_hek_flags(key, klen, hash, flags);
HeVAL(entry) = val;
+ in_collision = *oentry != NULL;
#ifdef PERL_HASH_RANDOMIZE_KEYS
/* This logic semi-randomizes the insert order in a bucket.
* Either we insert into the top, or the slot below the top,
* making it harder to see if there is a collision. We also
* reset the iterator randomizer if there is one.
*/
- in_collision = *oentry != NULL;
if ( *oentry && PL_HASH_RAND_BITS_ENABLED) {
PL_hash_rand_bits++;
PL_hash_rand_bits= ROTL_UV(PL_hash_rand_bits,1);
--
2.17.1
|
From @jkeenanOn Mon, 20 Aug 2018 23:42:55 GMT, 11000@gmx.de wrote:
Shouldn't the 2nd switch you mention be: PERL_HASH_RANDOMIZE_KEYS -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @jkeenanOn Mon, 20 Aug 2018 23:42:55 GMT, 11000@gmx.de wrote:
1. I tried to build Perl 5 blead by adding your switch to my regular configuration syntax: ##### I get this previously unseen compile-time warning: ##### Then 'make' appeared to grind to a halt at: ##### I did not attempt to proceed to 'make test'. 2. I created a branch and applied your patch to the branch: smoke-me/jkeenan/133459-perturb I configured and built perl as I normally do. 'make test_harness' PASS. 3. In the patch branched, I added your switch to my regular configuration command. I got the same compile-time warning as mentioned above, but 'make' did not appear to hang. However, I got failures in three tests: ##### Output attached. -- |
From @jkeenan# Failed test 56 - each() after insert produces warnings at op/each.t line 276 Test Summary Report op/each.t (Wstat: 0 Tests: 59 Failed: 1) |
From fnordpole@gmail.comThats right! Thank you! It should be PERL_HASH_RANDOMIZE_KEYS of course :) On Wed, Aug 22, 2018 at 5:23 PM, James E Keenan via RT <
|
From fnordpole@gmail.comThank you for looking into this! Looks good. This is exactly what i Regarding the compile time warning: I also observed the warning of The other warnings about usused variables though - i don't know where they Regarding the failed tests: I can also confirm some tests are failing when ------- exerpt from hv.h ------ #if defined(PERL_PERTURB_KEYS_DISABLED) On Wed, Aug 22, 2018 at 11:07 PM, James E Keenan via RT <
|
From @demerphqIs it possible you could explain why you are building like this and which Yves On Fri, 24 Aug 2018, 17:08 fnordpole@gmail.com, <fnordpole@gmail.com> wrote:
|
From fnordpole@gmail.comI design ASICs and run lots of simulations of electrical circuits. The When i have fetched the data from a database, i build a tree of nested Some average numbers: The tree depth is up to around 20 layers and a hash So i analyzed my code using nytprof (a lot of time goes into IO of course) I have seen that you have put forth a lot of effort into making the hash My custom built perl however lives in a completely offline laboratory and Regarding the hash-function itself: I would love to try out other Regards, On Fri, Aug 24, 2018 at 5:46 PM, demerphq <demerphq@gmail.com> wrote:
|
From @demerphqOn Fri, 24 Aug 2018 at 23:00, fnordpole@gmail.com <fnordpole@gmail.com> wrote:
Interesting, thank you for the explanation. Could you give me some FWIW, I doubt removing the key perturbance will change much of If really fast hash operations are really going to make your algorithm Yves |
From fnordpole@gmail.comYves, thank you for your suggestions! I bulit 4 versions of perl and varied the 1) default (no switches at all) I created a benchmark script that runs a typical workload and profiled it These are the results 1) default (no switches at all) 2) PERL_PERTURB_KEYS_DISABLED 3) SBOX32_MAX_LEN=12 4) SBOX32_MAX_LEN=48 My conclusion is: FYI: The key-length is on average around 16 characters. (stringified Thank you again Yves, for providing help. I really appreciated this little Regards, On Sat, Aug 25, 2018 at 8:27 AM, demerphq <demerphq@gmail.com> wrote:
|
From @demerphqOn Sat, 25 Aug 2018, 18:53 fnordpole@gmail.com, <fnordpole@gmail.com> wrote:
Very interesting results. Thank you very much. I just wanted to say I was not actually suggesting you move entirely away So for instance you say that your keys are floats, when perl hashes these A carefully designed XS module on the other hand would likely use some form Having said that it can take some artistry to actually make using XS like An example of the work you might avoid by doing this is the fact that Perl makes a set of tradeoffs with things like hashes, trading speed for Cheers |
From fnordpole@gmail.comYves, thank you for your further comments and for pointing out the XS approach! Regards, On Sun, Aug 26, 2018 at 12:52 PM, demerphq <demerphq@gmail.com> wrote:
|
Migrated from rt.perl.org#133459 (status was 'open')
Searchable as RT133459$
The text was updated successfully, but these errors were encountered: