Re: Performance of int/long in Python 3
On Tuesday, March 26, 2013 6:00:43 PM UTC-6, Ned Deily wrote: In article kit1kg$g2u$1...@ger.gmane.org, Mark Lawrence breamore...@yahoo.co.uk wrote: But you are an idiot. I repeat the friendly reminder I posted a few weeks ago and I'll be a little less oblique: please avoid gratuitous personal attacks here. It reflects badly on the group and especially on those people making them. We can disagree strongly about technical opinions without resorting to such. [..] +1, thank you for posting that. -- http://mail.python.org/mailman/listinfo/python-list
Performance of int/long in Python 3
The Python 3 merge of int and long has effectively penalized small-number arithmetic by removing an optimization. As we've seen from PEP 393 strings (jmf aside), there can be huge benefits from having a single type with multiple representations internally. Is there value in making the int type have a machine-word optimization in the same way? The cost is clear. Compare these methods for calculating the sum of all numbers up to 65535, which stays under 2^31: def range_sum(n): return sum(range(n+1)) def forloop(n): tot=0 for i in range(n+1): tot+=i return tot def forloop_offset(n): tot=1000 for i in range(n+1): tot+=i return tot-1000 import timeit import sys print(sys.version) print(inline: %d%sum(range(65536))) print(timeit.timeit(sum(range(65536)),number=1000)) for func in ['range_sum','forloop','forloop_offset']: print(%s: %r%(func,(globals()[func](65535 print(timeit.timeit(func+(65535),from __main__ import +func,number=1000)) Windows XP: C:\python26\python inttime.py 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] inline: 2147450880 2.36770455463 range_sum: 2147450880 2.61778550067 forloop: 2147450880 7.91409131608 forloop_offset: 2147450880L 23.3116954809 C:\python33\python inttime.py 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] inline: 2147450880 5.25038713020789 range_sum: 2147450880 5.412975112758745 forloop: 2147450880 17.875799577879313 forloop_offset: 2147450880 19.31672544974291 Debian Wheezy: rosuav@sikorsky:~$ python inttime.py 2.7.3 (default, Jan 2 2013, 13:56:14) [GCC 4.7.2] inline: 2147450880 1.92763710022 range_sum: 2147450880 1.93409109116 forloop: 2147450880 5.14633893967 forloop_offset: 2147450880 5.13459300995 rosuav@sikorsky:~$ python3 inttime.py 3.2.3 (default, Feb 20 2013, 14:44:27) [GCC 4.7.2] inline: 2147450880 2.884124994277954 range_sum: 2147450880 2.6586129665374756 forloop: 2147450880 7.660192012786865 forloop_offset: 2147450880 8.11817193031311 On 2.6/2.7, there's a massive penalty for switching to longs; on 3.2/3.3, the two for-loop versions are nearly identical in time. (Side point: I'm often seeing that 3.2 on Linux is marginally faster calling my range_sum function than doing the same thing inline. I do not understand this. If anyone can explain what's going on there, I'm all ears!) Python 3's int is faster than Python 2's long, but slower than Python 2's int. So the question really is, would a two-form representation be beneficial, and if so, is it worth the coding trouble? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On 03/25/2013 02:51 PM, Chris Angelico wrote: Python 3's int is faster than Python 2's long, but slower than Python 2's int. So the question really is, would a two-form representation be beneficial, and if so, is it worth the coding trouble? I'm inclined to say it's not worth the trouble. If you're working with numbers, and speed is an issue, you really should be using one of the numeric or scientific packages out there. -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On Mon, Mar 25, 2013 at 4:35 PM, Cousin Stanley cousinstan...@gmail.comwrote: Chris Angelico wrote: The Python 3 merge of int and long has effectively penalized small-number arithmetic by removing an optimization. The cost is clear. I thought I heard that Python 3.x will use machine words for small integers, and automatically coerce internally to a 2.x long as needed. Either way, it's better to have a small performance cost to avoid problems when computers move from 32 to 64 bit words, or 64 bit to 128 bit words. With 3.x int's, you don't have to worry about a new crop of CPU's breaking your code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
Chris Angelico wrote: The Python 3 merge of int and long has effectively penalized small-number arithmetic by removing an optimization. The cost is clear. The cost isn't quite as clear under Debian Wheezy here Stanley C. Kitching Debian Wheezy python inline range_sum forloop forloop_offset 2.7.3 3.1359 3.0725 9.0778 15.6475 3.2.3 2.8226 2.807413.47624 13.6430 # - Chris Angelico Debian Wheezy python inline range_sum forloop forloop_offset 2.7.3 1.9276 1.9341 5.1463 5.1346 3.2.3 2.8841 2.6586 7.6602 8.1182 -- Stanley C. Kitching Human Being Phoenix, Arizona -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On Mon, 25 Mar 2013 16:16:05 -0700, Ethan Furman wrote: On 03/25/2013 02:51 PM, Chris Angelico wrote: Python 3's int is faster than Python 2's long, but slower than Python 2's int. So the question really is, would a two-form representation be beneficial, and if so, is it worth the coding trouble? I'm inclined to say it's not worth the trouble. If you're working with numbers, and speed is an issue, you really should be using one of the numeric or scientific packages out there. Or PyPy, which will probably optimize it just fine. Also, speaking as somebody who remembers a time when ints where not automatically promoted to longs (introduced in, Python 2.2, I think?) let me say that having a single unified int type is *fantastic*, and managing ints/longs by hand is a right royal PITA. What I would like to see though is a module where I can import fixed- width signed and unsigned integers that behave like in C, complete with overflow, for writing code that matches the same behaviour as other languages. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On Tue, Mar 26, 2013 at 11:17 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Also, speaking as somebody who remembers a time when ints where not automatically promoted to longs (introduced in, Python 2.2, I think?) let me say that having a single unified int type is *fantastic*, and managing ints/longs by hand is a right royal PITA. Oh, I absolutely agree! I'm just looking at performance here, but definitely the int/long unification is a Good Thing. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On 26 March 2013 00:17, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Mon, 25 Mar 2013 16:16:05 -0700, Ethan Furman wrote: [snip] If you're working with numbers, and speed is an issue, you really should be using one of the numeric or scientific packages out there. [snip] What I would like to see though is a module where I can import fixed- width signed and unsigned integers that behave like in C, complete with overflow, for writing code that matches the same behaviour as other languages. Numpy can do this: import numpy a = numpy.array([0], numpy.uint32) a array([0], dtype=uint32) a[0] = -1 a array([4294967295], dtype=uint32) Unfortunately it doesn't work with numpy scalars, so to use this without the index syntax you'd need a wrapper class. Also it uses Python style floor rounding rather than truncation as in C (actually I seem to remember discovering that in C this is implementation defined). Presumably ctypes has something like this as well. Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
In article 5150e900$0$29998$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Also, speaking as somebody who remembers a time when ints where not automatically promoted to longs (introduced in, Python 2.2, I think?) let me say that having a single unified int type is *fantastic*, And incredibly useful when solving Project Euler problems :-) [I remember when strings didn't have methods] -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On Mon, 25 Mar 2013 20:55:03 -0400, Roy Smith wrote: In article 5150e900$0$29998$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Also, speaking as somebody who remembers a time when ints where not automatically promoted to longs (introduced in, Python 2.2, I think?) let me say that having a single unified int type is *fantastic*, And incredibly useful when solving Project Euler problems :-) [I remember when strings didn't have methods] No string methods? You were lucky. When I were a lad, you couldn't even use delimiters for strings. b string Parsing error: file stdin, line 1: b string ^ Unhandled exception: run-time error: syntax error Python 0.9.1. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
