Thanks all! So to summarize:

- 15-bit digits are still very much in use, and deprecating the option would likely be premature at this point
- the main users are old 32-bit (x86), which it's difficult to care about too much, and new 32-bit (principally ARM microarchitectures), which we *do* care about

So my first suspicion is just downright wrong. In particular, the decade-old logic that chooses 15-bit digits whenever SIZEOF_VOID_P < 8 is still in place (albeit with a recent modification for WebAssembly).

For the second suspicion, that "There are few machines where using 15-bit digits is faster than using 30-bit digits.", we need more data.

It looks as though the next step would be to run some integer-intensive benchmarks on 32-bitĀ ARM, with both --enable-big-digits=15 and --enable-big-digits=30. If those show a win (or at least, not a significant loss) for 30-bit digits, then there's a case for at least making 30-bit digits the default, which would be a first step towards eventually droppingĀ that support.

GPS: I'm not immediately seeing the ABI issue. If you're able to dig up more information on that, I'd be interested to see it.

Mark


On Fri, Dec 31, 2021 at 3:33 AM Tim Peters <tim.peters@gmail.com> wrote:
>> The reason for digits being a multiple of 5 bits should be revisited vs
>> its original intent

> I added that. The only intent was to make it easier to implement
> bigint exponentiation easily ...

That said, I see the comments in longintrepr.h note a stronger constraint:

"""
the marshal code currently expects that PyLong_SHIFT is a multiple of 15
"""

But that's doubtless also shallow.