This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients crusaderky, hongweipeng, rhettinger, serhiy.storchaka, steven.daprano, tim.peters
Date 2019-09-12.22:23:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1568327003.55.0.246162760027.issue38105@roundup.psfhosted.org>
In-reply-to
Content
A more principled change would be to replace instances of this:

    i = (i*5 + perturb + 1) & mask;

with this:

    i = (i*5 + (perturb << 1) + 1) & mask;

The latter spelling has no fixed points.  That's easy to see:  `(perturb << 1) + 1` is necessarily odd, and then `i*5 + ODD` is even when `i` is odd, and vice versa.

I had hoped that the time for a new shift could overlap with the multiply latency, but no such luck.  At least Visual Studio didn't multiply to begin with:  it first computes `i*4 + perturb` cheaply with a single LEA instruction, then adds 1 (INC), then adds in `i` again.

I expect it would be able to fold in a "free" shifted add of perturb with another LEA, so the latter spelling isn't necessarily more expensive.  But I'm generally loathe to increase operation counts relying on clever compilers to exploit processor-specific tricks.
History
Date User Action Args
2019-09-12 22:23:23tim.peterssetrecipients: + tim.peters, rhettinger, steven.daprano, serhiy.storchaka, hongweipeng, crusaderky
2019-09-12 22:23:23tim.peterssetmessageid: <1568327003.55.0.246162760027.issue38105@roundup.psfhosted.org>
2019-09-12 22:23:23tim.peterslinkissue38105 messages
2019-09-12 22:23:23tim.peterscreate