Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Chris Angelico <rosuav@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Assignment Versus Equality
Date: Wed, 29 Jun 2016 23:34:48 +1000
Lines: 40
Message-ID: <mailman.107.1467207299.2358.python-list@python.org>
References: <8a53c069-ca13-47bf-a24e-d2393a018b22@googlegroups.com> <nkobtu$gaq$1@dont-email.me> <l8svmbdf95jh54nmal5h3130cgmhreo3ot@4ax.com> <mailman.4.1466954526.2358.python-list@python.org> <nkotei$dk9$1@dont-email.me> <nkotv4$fif$1@dont-email.me> <nkrbgb$oc5$1@ger.gmane.org> <mailman.32.1467035992.2358.python-list@python.org> <4e72d24b-07b4-484c-83f8-a1fecc727f8c@googlegroups.com> <5773340f$0$1616$c3e8da3$5496439d@news.astraweb.com> <CAPTjJmqyR2POEe8ng6n-3-ih66JF9aXi1iq2Fhu6pxhR-7KV4w@mail.gmail.com> <mailman.96.1467174006.2358.python-list@python.org> <34aa9c69-cdd5-437c-a32b-9a706ef6d9c0@googlegroups.com> <57735c0a$0$2864$c3e8da3$76491128@news.astraweb.com> <311c9890-8588-45f1-85a3-478e18268508@googlegroups.com> <57736ea1$0$2933$c3e8da3$76491128@news.astraweb.com> <CAPTjJmoHtZpx2RCVdGo7A6VYESG-8z-7NCTy5i+ugK1kjbpJZQ@mail.gmail.com> <mailman.100.1467187791.2358.python-list@python.org> <5773c0b5$0$1608$c3e8da3$5496439d@news.astraweb.com> <CAPTjJmpeELKyVw9=fbkru69zdC5+VXJnNUdGws8-ecT3fNhcLg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <5773c0b5$0$1608$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:110778

On Wed, Jun 29, 2016 at 10:36 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> 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.

On its own, perhaps. But then I do the exact same tests on Python 3,
and the numbers are virtually identical - suggesting that the bignum
slowdown isn't all that significant at all. But in case you're
worried, I'll do it your way too:

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: 476 usec per loop
rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 0L" "for i in
xrange(10000): n += i"
1000 loops, best of 3: 476 usec per loop

So, once again, my system shows that there's a definite slowdown from
using bignums - and it's the same whether I start with 1<<100 or 0L.
(In this particular run, absolutely precisely the same, but other runs
showed numbers like 479 and 486.) What's different about your system
that you see short ints as performing exactly the same as long ints?
Obviously you're running on a slower computer than mine (you're seeing
msec values compared to my usec), but that shouldn't be significant.
Is there a massive architectural difference?

rosuav@sikorsky:~$ uname -a
Linux sikorsky 4.6.0-1-amd64 #1 SMP Debian 4.6.1-1 (2016-06-06) x86_64 GNU/Linux

ChrisA