On Aug 11, 2019, at 19:01, malin...@163.com 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 -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2LGS3O2BPQFCDJB22RXYM6YMEITWF3RS/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to