bpo-42673 prevent branch misprediction in round_size (used in rehash)

[jneb]

Replace the loop in round_size using bit_length to prevent branch misprediction delays.

https://bugs.python.org/issue42673

[jneb]

The fact that test_asyncio failed on Windows x86 shouldn't have anything to do with this: the change is deep into the core, and if there actually is an error there, many more tests should fail.
Does anybody understand what is going on here?
The actual error is:

FAIL: test_sendfile_close_peer_in_the_middle_of_receiving (test.test_asyncio.test_sendfile.ProactorEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\cpython\cpython\lib\test\test_asyncio\test_sendfile.py", line 458, in test_sendfile_close_peer_in_the_middle_of_receiving
    self.run_loop(
AssertionError: ConnectionError not raised

After forcing a new test, all was OK. There is something fishy with this test ...

[vstinner]

Can you please try _Py_SIZE_ROUND_DOWN() which could be even faster? It uses simple operations:

#define _Py_SIZE_ROUND_DOWN(n, a) ((size_t)(n) & ~(size_t)((a) - 1))

About _Py_bit_length(): it has a special case for 0, but s >= HASHTABLE_MIN_SIZE.

[jneb]

That's brilliant! I didn't know about that macro.
EDITED:
.... but, that macro doesn't do what we want: we want to round up to the nearest power of two, not to a multiple of a given power of two.
I've been wrecking my brain for a quick binary trick to do that, but this is the fastest one I could find.

[vstinner]

For me, this macro is pure black magic... but oops, I picked the wrong macro, I was thinking at: _Py_SIZE_ROUND_UP().

/* Below "a" is a power of 2. */
/* Round down size "n" to be a multiple of "a". */
#define _Py_SIZE_ROUND_DOWN(n, a) ((size_t)(n) & ~(size_t)((a) - 1))

/* Round up size "n" to be a multiple of "a". */
#define _Py_SIZE_ROUND_UP(n, a) (((size_t)(n) + \
        (size_t)((a) - 1)) & ~(size_t)((a) - 1))

[vstinner]

Maybe _Py_SIZE_ROUND_UP() should be rewritten as a static inline function to ensure that (a-1) expression is only computed once.

[vstinner]

Micro-optimisation :-)

Suggested change

	if (s < HASHTABLE_MIN_SIZE)
	if (s <= HASHTABLE_MIN_SIZE)

[jneb]

This actually may make the code slower. The value passed to round_size will almost never be < HASHTABLE_MIN_SIZE, but it sometimes is equal.
The branch prediction will probably be faster if it can assume the condition is always false.

[vstinner]

@serhiy-storchaka: using _Py_SIZE_ROUND_DOWN() avoids the loop and might be faster, no? What do you think?

[serhiy-storchaka]

_Py_SIZE_ROUND_UP() does not have anything in common with this code. It returns the smallest number not less than n which is divisible by a. _Py_SIZE_ROUND_UP(42, 2) -> 42, _Py_SIZE_ROUND_UP(42, 4) -> 44, _Py_SIZE_ROUND_UP(42, 8) -> 48.

[serhiy-storchaka]

_Py_bit_length() works with unsigned long, but the argument of round_size() has type size_t.

[jneb]

That's a good point. So this would fail if the hashtable gets a number of entries that couldn't fit in an unsigned long, which is indeed possible in theory (but only for humongous computers: 8<<32 = 32 GB, for a single hash table. Would be a bit hard to test :-).
I think the best solution would be to fix the macro to handle this case.

[jneb]

_Py_bit_length() works with unsigned long, but the argument of round_size() has type size_t.

When looking at the definition of _Py_bit_length(), I am a afraid to copy it for size_t. What if size_t is equivalent to unsigned long? Or more accurately, what is the safe #if to write to make sure there is no double definition? Something like

#if SIZEOF_SIZE_T > SIZEOF_LONG
(copied code of Py_bit_length, for size_t)
#endif

or is there a better way?
EDITED:
That didn't work. I made a separate _Py_bit_length_size_t routine; I am not happy with the result as it looks ugly to repeat all this source code.

[vstinner]

I would prefer to add a _Py_next_pow2() function which takes a size_t parameter. So we can use more efficient implementation when __builtin_clzl() and _BitScanReverse() are not available. Like:

static inline uint32_t next_pow2(uint32_t x)
{
	x -= 1;
	x |= (x >> 1);
	x |= (x >> 2);
	x |= (x >> 4);
	x |= (x >> 8);
	x |= (x >> 16);
	return x + 1;
}

I suggest to require the argument to be >= 2.

[vstinner]

This code is reference at http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 for example.

[jneb]

So it appears to work now, but I am not completely happy with the way the different types are specified. But at least we can be sure that the optimization is possible and works.
It won't make a very big difference, but the fact that we probably save a mispredicted branch for every hashtable expansion makes me happy.

[jneb]

I would be happy if somebody with more experience will have a good look at this.

[serhiy-storchaka]

I would want to see evidences that the proposed code is faster than the current code.

[ghost]

LGTM

[jneb]

I found exactly the same code in pyobject.c under the name calculate_keysize so this can be replaced by a call to the new routine.
Furthermore, it almost proves that it is the fastest way :-)

[vstinner]

I found exactly the same code in pyobject.c under the name calculate_keysize so this can be replaced by a call to the new routine. Furthermore, it almost proves that it is the fastest way :-)

calculate_keysize() is defined in Objects/dictobject.c. It's called when creating a new dict, when inserting an item in a dict, or when merging two dicts. It might be interesting, but so far, you didn't provide any micro-benchmark.

[serhiy-storchaka]

Similar code is used for dict, set, and other implementations of hashtable (one or two).

[jneb]

The unsigned long version in pycore_bitutils is even more optimized, with a 5 bit lookup; i would suggest to copy that code for the size_t version (as I did), and use it for all locations where rounding up to a two power is used.
I'm a bit nervous to do this myself as I am a core development newbie, and there are so many different types used in this code.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[iritkatriel]

Closing as https://bugs.python.org/issue42673 has been rejected.