On Aug 11, 2019, at 19:01, [email protected] wrote:
>
> The idea is mixing `PyLongObject` with `Python 2's PyIntObject`
> implementation.
>
> For example, on a 64-bit platform, if (an integer >=-9223372036854775808 and
> <=9223372036854775807), PyLongObject uses a native C type `signed long` to
> represent it.
>
> People mostly use +-* operations, maybe using native int is faster, even
> including the cost of overflow check.
I’m assuming you don’t know C and/or CPython internals well enough to try it
out yourself, and that’s fine. But If you want to get someone else motivated
enough to try, you should at least provide some evidence that it’s potentially
worth it, beyond the fact that someone who doesn’t know the internals thinks
_maybe_ it’ll be faster.
Have you benchmarked 2.7 vs. 3.7 adding various sizes of integers? (From a
quick test with Pythonista, 3.6 seems to actually be _faster_ if the total is
under 1<<30, although it does get slower beyond that, and especially between
1<<60 and 1<<63.) Or looked up the history from when PyIntObject was removed in
3.0? (There must have been lots of discussion on the -dev or py3k lists about
performance before deciding to do it, especially so soon after all the work to
make int/long interoperate seamlessly for later 2.x.) Or looked through the
implementation as far as you can understand it to spot things that look slow?
(longintrepr.h isn’t that complicated; longobject.c is pretty hairy, but at
least it’s well-commented.)
By the way, I suspect you wouldn’t want two separate structures, but rather
just replace the int32 *digits with a union { int32 *digits; sintptr_t
smallnum; }, and size 1 or -1 means you use smallnum instead of digits.
Although I’m not sure how you’d do your “convert to present format for other
operations or detected overflow” thing (and presumably for mixed operations,
like adding a small int to a big one) that way, but I think you’re better off
just building the array of digits for the temporary rather than a whole int
object anyway.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/2LGS3O2BPQFCDJB22RXYM6YMEITWF3RS/
Code of Conduct: http://python.org/psf/codeofconduct/