On Wed, 29 Jun 2016 06:09 pm, Chris Angelico wrote: > On Wed, Jun 29, 2016 at 4:45 PM, Steven D'Aprano > <steve+comp.lang.pyt...@pearwood.info> wrote: >> On Wednesday 29 June 2016 15:51, Lawrence D’Oliveiro wrote: >> >>> On Wednesday, June 29, 2016 at 5:26:46 PM UTC+12, Steven D'Aprano wrote: >>>> BUT in Python 3, the distinction between int and long is gone by >>>> dropping int and renaming long as "int". So all Python ints are >>>> BIGNUMs. >>> >>> I don’t understand what the problem is with this. Is there supposed to >>> be some issue with performance? Because I can’t see it. >> >> If there is a performance hit, it's probably pretty small. It may have >> been bigger back in Python 3.0 or 3.1. >> >> [steve@ando ~]$ python2.7 -m timeit -s "n = 0" "for i in xrange(10000): n >> [+= i" >> 100 loops, best of 3: 1.87 msec per loop >> >> [steve@ando ~]$ python3.3 -m timeit -s "n = 0" "for i in range(10000): n >> [+= i" >> 1000 loops, best of 3: 1.89 msec per loop >> >> >> Although setting debugging options does make it pretty slow: >> >> [steve@ando ~]$ python/python-dev/3.6/python -m timeit -s "n = 0" "for i >> [in >> range(10000): n += i" >> 100 loops, best of 3: 13.7 msec per loop > > That's not necessarily fair - you're comparing two quite different > Python interpreters, so there might be something entirely different > that counteracts the integer performance.
Um, the two code snippets do the same thing. Comparing two different versions of the same interpreter is *precisely* what I intended to do: - is CPython using boxed native ints faster than CPython using boxed BigNums, post unification? No, my test doesn't precisely compare performance of boxed native ints versus boxed BigNums for the same version, but I don't care about that. I care about whether the Python interpeter is slower at int arithmetic since unifying int and long, and my test shows that it isn't. > (For example: You're > creating and disposing of large numbers of objects, so the performance > of object creation could affect things hugely.) Sure. But in real life code, you're likely to be creating and disposing of large numbers of objects. And both versions create and dispose of the same objects, so the test is fair to both versions. > To make it somewhat > fairer, add long integer performance to the mix. Starting by redoing > your test: Why? That's irrelevant. The comparison I'm looking at is whether arithmetic was faster using boxed native ints in older versions. In other words, has there been a performance regression between 2.7 and 3.3? For int arithmetic, the answer is No. I can make guesses and predictions about why there is no performance regression: - native ints were amazingly fast in Python 2.7, and BigNums in Python 3.3 are virtually as fast; - native ints were horribly slow in Python 2.7, and changing to BigNums is no slower; - native ints were amazingly fast in Python 2.7, and BigNums in Python 3.3 are horribly slow, BUT object creation and disposal was horribly slow in 2.7 and is amazingly fast in 3.3, so overall it works out about equal; - int arithmetic is so fast in Python 2.7, and xrange() so slow, that what I actually measured was just the cost of calling xrange, and by mere coincidence it happened to be almost exactly the same speed as bignum arithmetic in 3.3. But frankly, I don't really care that much. I'm not so much interested in micro-benchmarking individual features of the interpreter as caring about the overall performance, and for that, I think my test was reasonable and fair. > rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 0" "for i in > xrange(10000): n += i" > 10000 loops, best of 3: 192 usec per loop > rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 1<<100" "for i in > xrange(10000): n += i" > 1000 loops, best of 3: 478 usec per loop Now *that's* an unfair benchmark, because we know that BigNums get slower as they get bigger. A BigNum with 30+ digits is not going to perform like a BigNum with 8 digits. The right test here would be: python2.7 -m timeit -s "n = 0L" "for i in xrange(10000): n += i" On my machine, I get these figures: [steve@ando ~]$ python2.7 -m timeit -s "n = 0" "for i in xrange(10000): n += i" 1000 loops, best of 3: 2.25 msec per loop [steve@ando ~]$ python2.7 -m timeit -s "n = 0L" "for i in xrange(10000): n += i" 100 loops, best of 3: 2.33 msec per loop which suggests that even in 2.7, the performance difference between native ints and BigNums was negligible for smallish numbers. But of course if we use huge BigNums, they're more expensive: [steve@ando ~]$ python2.7 -m timeit -s "n = 1 << 100" "for i in xrange(10000): n += i" 100 loops, best of 3: 2.44 msec per loop although apparently not *that* much more expensive on my machine. Let's try something bigger: [steve@ando ~]$ python2.7 -m timeit -s "n = 1 << 1000" "for i in xrange(10000): n += i" 100 loops, best of 3: 4.23 msec per loop Now you can see the cost of really BigNums. But still, that's about 300 digits, so not too shabby. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
