[Python-Dev] Changing python int to "long long".

[Guido van Rossum]

On 5/23/06, Sean Reifschneider <jafo-python-dev at tummy.com> wrote:
> We've been discussing the possibility of converting the Python int type to
> long long (from long).  I played around with it some, and it's going to be
> a huge change that probably will break most C extensions until.  However,
> as uncletimmy says, "Python is so stinking slow" that it probably won't
> make much of a negative impact on the performance.

Based on the stability picture alone I think this must wait for 2.6.

> The reason we're looking at this at Need for Speed is that EWT has a lot of
> code that uses ints between the 32 and 64 bit range.  It'd be a hard change
> to make to convert to long long for regular ints.  I'm going to speak with
> John and Runar today about if we can make just a long long extension type
> and live with it not integrating with other type coercion as well as an int
> would.

Actually it should be able to integrate almost perfectly given that
2.5 has __index__.

> The big deal right now is on 32 bit platforms, giving the 64-bits for int.
> However, it will also be a win for 64-bit platforms for ints that fall
> between 64 and 128 bits.

But who needs those? And who says that long long is 128 bits on a
64-bit machine? (At least on Windows 64, long is still 32 bit, so I
expect long long to be 64 bit there.)

> So, I ran pybench on a half-arsed conversion of ints to long long, and only
> lost around 1.11% over all.  However, for simple math I got a solid 25%
> speed-up (n = ((((i << 33) * 2) + 1) / 3) - 2), and for 1<<35 I got a 34%
> speed up, compared with them getting converted to Python longs.
>
> For ints that will fit entirely within 32-bits, I'm seeing around 11% worse
> performance when going to 64-bit types.
>
> This is all on the 2.5 trunk.
>
> My conclusion is that it's probably enough of a performance drop that we
> can't just do it wholesale.  It has a big gain for ints within 32 and 64
> on 32-bit platforms, but for <32-bit ints it's going to be pretty bad.
> Within the next few years many platforms, particularly performance-critical
> ones, will probably be 64 bit anyway, so fewer people will probably be able
> to see an advantage to it.

Indeed. I say EWT can solve the problem much cheaper by using 64-bit
hardware, compared to the cost imposed on the rest of the world.

> The ideal would probably be to have another int type and up-convert to a
> long long, THEN go to arbitrary precision, but that's a pretty big change.
> Less big than converting the int to long long though.  The easiest would be
> to make an extension that has long long, if that will work for speeding up
> applications like EWT has.  I'll follow up with them on this.
>
> Any thoughts on this?

In 2.6, I'd be okay with standardizing int on 64 bits everywhere (I
don't think bothering with 128 bits on 64-bit platforms is worth it).
In 2.5, I think we should leave this alone.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)