On Thu, Dec 30, 2021 at 12:42 PM Gregory P. Smith <g...@krypto.org> wrote:
> > On Thu, Dec 30, 2021 at 4:47 AM Mark Dickinson <dicki...@gmail.com> wrote: > >> tl;dr: I'd like to deprecate and eventually remove the option to use >> 15-bit digits in the PyLong implementation. Before doing so, I'd like to >> find out whether there's anyone still using 15-bit PyLong digits, and if >> so, why they're doing so. >> >> History: the use of 30-bit digits in PyLong was introduced for Python 3.1 >> and Python 2.7, to improve performance of int (Python 3) / long (Python 2) >> arithmetic. At that time, we retained the option to use 15-bit digits, for >> two reasons: >> >> - (1) use of 30-bit digits required C99 features (uint64_t and friends) >> at a time when we hadn't yet committed to requiring C99 >> - (2) it wasn't clear whether 30-bit digits would be a performance win on >> 32-bit operating systems >> >> Twelve years later, reason (1) no longer applies, and I suspect that: >> >> - No-one is deliberately using the 15-bit digit option. >> - There are few machines where using 15-bit digits is faster than using >> 30-bit digits. >> >> But I don't have solid data on either of these suspicions, hence this >> post. >> >> Removing the 15-bit digit option would simplify the code (there's >> significant mental effort required to ensure we don't break things for >> 15-bit builds when modifying Objects/longobject.c, and 15-bit builds don't >> appear to be exercised by the buildbots), remove a hidden compatibility >> trap (see b.p.o. issue 35037), widen the applicability of the various fast >> paths for arithmetic operations, and allow for some minor fast-path >> small-integer optimisations based on the fact that we'd be able to assume >> that presence of *two* extra bits in the C integer type rather than just >> one. As an example of the latter: if `a` and `b` are PyLongs that fit in a >> single digit, then with 15-bit digits and a 16-bit `digit` and `sdigit` >> type, `a + b` can't currently safely (i.e., without undefined behaviour >> from overflow) be computed with the C type `sdigit`. With 30-bit digits and >> a 32-bit `digit` and `sdigit` type, `a + b` is safe. >> >> Mark >> > > tying the thread together: this is https://bugs.python.org/issue45569 > > Check 32-bit builds. When I pushed for the 30-bit digit implementation, I > wanted it for all builds but if I recall correctly it *might* have > changed the minimum structure size for PyLong which could've been an ABI > issue? double check that. 32-bit is still important. Raspbian. rpi, rpi > zero, and first rev rpi2 are 32-bit arm architectures so even with 64-bit > raspbian on the horizon, that won't be the norm. and for those, memory > matters so a 32-bit userspace on 64-bit capable hardware is still preferred > for small pointer sizes on the majority which have <=4GiB ram. > > I believe performance was the other concern, 30-bit happens to perform > great on 32-bit x86 as it has 32*32->64 multiply hardware. Most 32-bit > architectures do not AFAIK, making 30 bit digit multiplies less efficient. > And 32-bit x86 was clearly on its way out by the time we adopted 30-bit so > it was simpler to just not do it on that dying snowflake of a platform. > (test it on raspbian - it's the one that matters) > > Regardless of possible issues to work out, I'd love us to have a simpler > 30-bit only implementation. > > Granted, modern 64-bit hardware often has 64*64->128 bit multiply hardware > so you can imagine going beyond 30 and winding up in complexity land > again. at least the extra bits would be >=2 at that point. The reason for > digits being a multiple of 5 bits should be revisited vs its original > intent and current state of the art "bignum optimized for mostly small > numbers" at some point as well. > > -gps > > Historical context of adding the 30-bit support (also driven primarily by Mark, no surprise!) in late 2008 early 2009: https://bugs.python.org/issue4258 (and https://codereview.appspot.com/14105) -gps
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PRL7TJWUDYAMBQKVDLAIKD2OS2VOQPMQ/ Code of Conduct: http://python.org/psf/codeofconduct/
