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.