Good PR. Since this code is ahotspot where every instruction matters, I found a way to shave off a few more instructions. This doesn't have to block the PR, but it's something we could consider in a follow-up optimization.

_Py_bit_length() doesn't need to checkif (x != 0) in this context.

Look at the GCC/Clang path:

We don't need to checkif (x != 0) becausex == Py_MAX(minsize, PyDict_MINSIZE) - 1 is guaranteed nonzero, so we end up paying a compare+branch there for no reason. Likewise, we don't need to checkif (_BitScanReverse(&msb, x)) in the MSVC branch:

If the tradeoff is worth it, we can create a_Py_bit_length_nonzero() that is optimized for the guarantee thatx > 0. With your go-ahead, I could file an issue for that. I only bring this up because yousuggested earlier thatPy_MAX()'s conditional logic almost made it inferior to bitwise operations simply due to the overhead of extra instructions on arm64 and amd64.

_Py_bit_length is inline function. compiler optimize away unnecessary 0 comparison.

I had suggested avoiding Py_MAX because it can not be eliminated statically.

Thanks@methane for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

Sorry,@methane, I could not cleanly backport this to3.13 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker 92337f666e8a076a68305a8d6dc8bc9c095000e9 3.13

GH-133861 is a backport of this pull request to the3.14 branch.

GH-133862 is a backport of this pull request to the3.13 branch.

⚠️⚠️⚠️ Buildbot failure⚠️⚠️⚠️

Hi! The buildbotPPC64LE RHEL8 3.14 (tier-2) has failed when building commit5c9f0ae.

What do you need to do:

1. Don't panic.
2. Checkthe buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/1688/builds/8) and take a look at the build logs.
4. Check if the failure is related to this commit (5c9f0ae) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/1688/builds/8

Failed tests:

• test.test_multiprocessing_spawn.test_processes

Failed subtests:

• test_interrupt - test.test_multiprocessing_spawn.test_processes.WithProcessesTestProcess.test_interrupt

Summary of the results of the build (if available):

==

Traceback (most recent call last):  File"/home/buildbot/buildarea/3.14.cstratak-RHEL8-ppc64le/build/Lib/test/_test_multiprocessing.py", line578, intest_interruptself.assertEqual(exitcode,1)~~~~~~~~~~~~~~~~^^^^^^^^^^^^^AssertionError:-2 != 1Traceback (most recent call last):  File"<string>", line1, in<module>from multiprocessing.spawnimport spawn_main; spawn_main(tracker_fd=5,pipe_handle=9)~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.14.cstratak-RHEL8-ppc64le/build/Lib/multiprocessing/spawn.py", line122, inspawn_main    exitcode= _main(fd, parent_sentinel)  File"/home/buildbot/buildarea/3.14.cstratak-RHEL8-ppc64le/build/Lib/multiprocessing/spawn.py", line132, in_mainself= reduction.pickle.load(from_parent)  File"/home/buildbot/buildarea/3.14.cstratak-RHEL8-ppc64le/build/Lib/test/test_multiprocessing_spawn/test_processes.py", line2, in<module>from test._test_multiprocessingimport install_tests_in_module_dict  File"/home/buildbot/buildarea/3.14.cstratak-RHEL8-ppc64le/build/Lib/test/_test_multiprocessing.py", line2766, in<module>classSayWhenError(ValueError):passKeyboardInterruptFAILTraceback (most recent call last):  File"<string>", line1, in<module>from multiprocessing.spawnimport spawn_main; spawn_main(tracker_fd=6,pipe_handle=8)~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.14.cstratak-RHEL8-ppc64le/build/Lib/multiprocessing/spawn.py", line122, inspawn_main    exitcode= _main(fd, parent_sentinel)  File"/home/buildbot/buildarea/3.14.cstratak-RHEL8-ppc64le/build/Lib/multiprocessing/spawn.py", line132, in_mainself= reduction.pickle.load(from_parent)  File"/home/buildbot/buildarea/3.14.cstratak-RHEL8-ppc64le/build/Lib/test/test_multiprocessing_spawn/test_processes.py", line2, in<module>from test._test_multiprocessingimport install_tests_in_module_dict  File"<frozen importlib._bootstrap>", line1371, in_find_and_load  File"<frozen importlib._bootstrap>", line1342, in_find_and_load_unlocked  File"<frozen importlib._bootstrap>", line938, in_load_unlocked  File"<frozen importlib._bootstrap_external>", line758, inexec_module  File"<frozen importlib._bootstrap_external>", line891, inget_code  File"<frozen importlib._bootstrap_external>", line514, in_compile_bytecodeKeyboardInterruptFAIL

I had suggested avoiding Py_MAX because it can not be eliminated statically.

@methane Sorry for misunderstanding, I just couldn't find the comment anymore where you said that. I think it's gone.

_Py_bit_length is inline function. compiler optimize away unnecessary 0 comparison.

You're right about most modern compilers, but not all of them. I tested the no-zero-check concept on MSVC x86, a Tier 1 platform, and it does actually shave a few assembly instructions.

Notice the conditional je is present after the bsr:

_calculate_log2_keysize PROC        mov     eax, 8        cmp     DWORD PTR _minsize$[esp-4], eax        cmovg   eax, DWORD PTR _minsize$[esp-4]        dec     eax        bsr     eax, eax        je      SHORT $LN4@calculate_        inc     eax        ret     0$LN4@calculate_:        xor     al, al        ret     0_calculate_log2_keysize ENDP

But not here:

_calculate_log2_keysize_nonzero PROC        mov     ecx, 8        cmp     DWORD PTR _minsize$[esp-4], ecx        cmovg   ecx, DWORD PTR _minsize$[esp-4]        dec     ecx        bsr     eax, ecx        inc     al        ret     0_calculate_log2_keysize_nonzero ENDP

You can see it for yourselfhere. Yeah, it's "only" a je + unused branch, but it's unexpectedly running on everydictresize on 32-bit Windows for no reason, so I thought I'd tell you.

You're right about most modern compilers, but not all of them. I tested the no-zero-check concept on MSVC x86, a Tier 1 platform, and it does actually shave a few assembly instructions.

We don't use_Py_bit_length on MSVC. We have nonzero specialization for it already.

You're right about most modern compilers, but not all of them. I tested the no-zero-check concept on MSVC x86, a Tier 1 platform, and it does actually shave a few assembly instructions.

We don't use_Py_bit_length on MSVC. We have nonzero specialization for it already.

Sorry, I was wrong. We use _Py_bit_length on x86-32.
But I don't feel enough attraction of it. Tier 1 doesn't mean 100% effort for optimization and dictresize is not hot as dict lookup.

That's understandable.