Gregory Smith <gregsm...@users.sourceforge.net> added the comment: Actually, my view for 3.x is this: I do agree hugely with the 'top level' decision to only have one type that handles everything, and obviously the easiest way to get there is to just use the existing long type. However, though the rad-2^15 implementation of the 'long' type was a fine thing for the 2.x python where it's only used for relatively unusual cases, I think it's too inefficient to use as the primary integer type, so I'm wondering if there's a plan to replace it with something more efficient (thus rendering this particular issue irrelevant).
I did spend some time delving into python internals years ago, but haven't really looked into 3.x, so bear with me. I am aware of the following 'speed tweaks' in Python 2.x integers, aren't these lost now? (1) integers all same size, allocated from linked-list pool instead of from malloc (2) 'add' and 'sub' byte codes do special check in interpreter core to see if ints being added, and will go direct to PyInt_FromLong where possible It would seem to me that a more suitable implementation would be to store numbers as 32*k-bit 2's complement integers; I've used this in C++ libraries. Compared to the rad-15 sign/magnitude approach, it may seem trickier to do carries but in practice it's not that big a deal. It also basically assumes you have a decently fast 64-bit operation to do multiplies and divides with, which I think is now reasonable. This implementation will be much easier to optimize for the (now) extremely common case where numbers fit into 32 bits. It could also be possible to store 'wee' integers in a special pool and only use malloc for larger ones. I know there's a lot of code in that module, virtually all of which would be affected by this. But isn't this type now a big performance factor in 3.x? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1087418> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
