On 5/23/06, Sean Reifschneider <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
