Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #110513 > unrolled thread

Assignment Versus Equality

Back to article view | Back to comp.lang.python

Contents

  Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-26 00:36 -0700
    Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-26 11:48 +0100
      Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-26 23:21 +1000
        Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-26 07:26 -0700
          Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-26 11:31 -0400
        Re: Assignment Versus Equality Christopher Reimer <christopher_reimer@icloud.com> - 2016-06-26 11:47 -0700
        Re: Assignment Versus Equality Michael Torrie <torriem@gmail.com> - 2016-06-26 15:28 -0600
        Re: Assignment Versus Equality Bob Gailer <bgailer@gmail.com> - 2016-06-27 08:22 -0400
          Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 05:48 -0700
            Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-27 23:28 +1000
              Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-27 16:58 +0300
              Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 07:23 -0700
                Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-28 11:05 +1000
                  Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 21:31 -0700
                    Re: Assignment Versus Equality Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-28 15:42 +1000
                      Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-28 16:04 +1000
                        Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 09:12 +0300
                          Re: Assignment Versus Equality Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-28 11:04 +0300
                      Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 23:09 -0700
                        Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 00:12 -0700
                          Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-28 17:26 +1000
                            Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 01:49 -0700
                              Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-28 20:34 +1000
                                Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 17:42 -0700
                    Re: Assignment Versus Equality Random832 <random832@fastmail.com> - 2016-06-28 10:13 -0400
                      Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 19:39 +0300
                        Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 19:41 +0300
                        Re: Assignment Versus Equality Random832 <random832@fastmail.com> - 2016-06-28 13:19 -0400
                        Re: Assignment Versus Equality Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-28 12:27 -0600
                          Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 22:40 +0300
                            Re: Assignment Versus Equality Gene Heskett <gheskett@shentel.net> - 2016-06-28 16:59 -0400
                        Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-30 12:29 +1200
                          Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-30 12:50 +1000
                          Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-30 09:22 +0300
                      Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-29 12:27 +1000
                        Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 20:52 -0700
                          Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 21:03 -0700
                        Re: Assignment Versus Equality Random832 <random832@fastmail.com> - 2016-06-29 00:52 -0400
                Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-27 18:14 -0700
              Re: Assignment Versus Equality Gene Heskett <gheskett@shentel.net> - 2016-06-27 11:21 -0400
            Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-27 20:04 -0400
      Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-26 11:21 -0400
        Re: Assignment Versus Equality Cousin Stanley <HooDunnit@didly42KahZidly.net> - 2016-06-26 08:47 -0700
          Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-26 16:56 +0100
            Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-27 11:38 +1200
            Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-27 07:30 -0400
              Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-28 18:17 +1200
            Re: Assignment Versus Equality Grant Edwards <grant.b.edwards@gmail.com> - 2016-06-27 13:59 +0000
              Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-27 17:09 +0300
                Re: Assignment Versus Equality sohcahtoa82@gmail.com - 2016-06-27 17:33 -0700
                  Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 07:25 +0300
                    Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 23:54 -0700
              Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 07:10 -0700
                Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-29 12:35 +1000
                  Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 14:19 +1000
                    Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 21:51 -0700
                      Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 15:07 +1000
                        Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 22:55 -0700
                          Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 16:26 +1000
                            Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 23:33 -0700
                              Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 23:37 -0700
                      Re: Assignment Versus Equality Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-29 15:26 +1000
                        Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 22:51 -0700
                          Re: Assignment Versus Equality Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-29 16:45 +1000
                            Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-29 01:07 -0700
                            Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 18:09 +1000
                              Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-29 22:36 +1000
                                Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 14:24 +0100
                                  Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 23:35 +1000
                                    Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 15:47 +0100
                                Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 23:34 +1000
                        Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 10:49 +0100
                          Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-29 02:56 -0700
                            Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 11:10 +0100
                  Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-29 03:24 -0700
              Re: Assignment Versus Equality Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2016-06-27 16:48 +0200
                Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 22:00 -0700
              Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-28 11:34 +1000
            Re: Assignment Versus Equality MRAB <python@mrabarnett.plus.com> - 2016-06-27 16:27 +0100
              Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-27 14:56 -0700
              Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-27 15:45 -0700
                Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-28 00:08 +0100
                  Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-27 20:11 -0400
                    Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-28 11:35 +0100
                  Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-28 18:59 +1200
              Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-28 11:28 +1000
            Re: Assignment Versus Equality Grant Edwards <grant.b.edwards@gmail.com> - 2016-06-27 15:42 +0000
        Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-26 19:11 +0300
      Re: Assignment Versus Equality MRAB <python@mrabarnett.plus.com> - 2016-06-26 16:41 +0100
        Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-26 17:08 +0100
      Re: Assignment Versus Equality Christopher Reimer <christopher_reimer@icloud.com> - 2016-06-26 11:53 -0700
        Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-27 11:41 +1200
      Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-27 11:22 +1200
        Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-27 00:39 +0100
          Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-28 18:15 +1200

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#110757

On Wednesday, June 29, 2016 at 12:03:30 PM UTC+5:30, Rustom Mody wrote:
> On Wednesday, June 29, 2016 at 11:57:03 AM UTC+5:30, Chris Angelico wrote:
> > On Wed, Jun 29, 2016 at 3:55 PM, Rustom Mody wrote:
> > >> The transparent shift from machine-word to bignum is what no longer
> > >> exists. Both Py2 and Py3 will store large integers as bignums; Py2 has
> > >> two separate data types (int and long), with ints generally
> > >> outperforming longs, but Py3 simply has one (called int, but
> > >> functionally like Py2's long), and does everything with bignums.
> > >> There's no longer a boundary - instead, everything gets the "bignum
> > >> tax". How steep is that tax? I'm not sure, but microbenchmarking shows
> > >> that there definitely is one. How bad is it in real-world code? No
> > >> idea.
> > >>
> > >> ChrisA
> > >
> > > New to me -- thanks.
> > > I thought it did an FSR type covert machine word → BigInt conversion under the hood.
> > > Tax is one question
> > > Justification for this change is another
> > 
> > CPython doesn't currently do anything like that, but it would be
> > perfectly possible to do it invisibly, and thus stay entirely within
> > the language spec. I'm not aware of any Python implementation that
> > does this, but it wouldn't surprise me if PyPy has some magic like
> > that. It's PyPy's kind of thing.
> > 
> > It's also entirely possible that a future CPython will have this kind
> > of optimization too. It all depends on someone doing the
> > implementation work and then proving that it's worth the complexity.
> > 
> > ChrisA
> 
> Huh? I though I was just describing python2's behavior:
> 
> $ python
> Python 2.7.11+ (default, Apr 17 2016, 14:00:29) 
> [GCC 5.3.1 20160413] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> x=2
> >>> type(x)
> <type 'int'>
> >>> y=x ** 80
> >>> y
> 1208925819614629174706176L
> >>> type(y)
> <type 'long'>

Um ok I see the ...L there at the end of 2 ** 80
So its not exactly 'under the hood'

[toc] | [prev] | [next] | [standalone]

#110751

On Wednesday 29 June 2016 14:51, Lawrence D’Oliveiro wrote:

> On Wednesday, June 29, 2016 at 4:20:24 PM UTC+12, Chris Angelico wrote:
>>> https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-
stupid/
>> 
>> """It would also be reasonable to assume that any sane language
>> runtime would have integers transparently degrade to BIGNUMs, making
>> the choice of accuracy over speed, but of course that almost never
>> happens..."""
>> 
>> Python 2 did this, but Python 3 doesn't.
> 
> Huh?


Chris is referring to the fact that in Python 2, there were two distinct 
integer types, int and long. Originally they were entirely independent, and int 
overflow would give you an exception:

# Python 1.5
>>> type(2147483647)         
<type 'int'>
>>> 2147483647 + 1
Traceback (innermost last):
  File "<stdin>", line 1, in ?
OverflowError: integer addition

To do BIGNUM arithmetic, you needed to explicitly specify at least one argument 
was a long:

>>> 2147483647 + 1L
2147483648L



but from about 2.4 or thereabouts, Python would automatically promote ints to 
longs when a calculation got too big:

# Python 2.7, 32-bit build
py> type(2147483647)
<type 'int'>
py> type(2147483647 + 1)
<type 'long'>


which is the behaviour JMZ is referring to.

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.

In principle Python might use native 32 or 64 bit ints for small values and 
secretly promote them to BIGNUMs when needed, but as far as I know no 
implementation of Python currently does this.




-- 
Steve

[toc] | [prev] | [next] | [standalone]

#110752

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.

[toc] | [prev] | [next] | [standalone]

#110758

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



-- 
Steve

[toc] | [prev] | [next] | [standalone]

#110759

On Wednesday, June 29, 2016 at 6:46:04 PM UTC+12, Steven D'Aprano 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

Here is what I tried:

    ldo@theon:python_try> python2 int_speed_test.py
    2 ** 6 is 2 ** 6: True
    1000000 iterations of “a = 2 ** 6 // 2 ** 4” took 0.0624719s = 6.24719e-08s/iteration
    2 ** 9 is 2 ** 9: False
    1000000 iterations of “a = 2 ** 9 // 2 ** 6” took 0.0506701s = 5.06701e-08s/iteration
    2 ** 20 is 2 ** 20: False
    1000000 iterations of “a = 2 ** 20 // 2 ** 12” took 0.0441589s = 4.41589e-08s/iteration
    2 ** 64 is 2 ** 64: False
    1000000 iterations of “a = 2 ** 64 // 2 ** 32” took 0.138092s = 1.38092e-07s/iteration
    2 ** 96 is 2 ** 96: False
    1000000 iterations of “a = 2 ** 96 // 2 ** 64” took 0.1142s = 1.142e-07s/iteration
    ldo@theon:python_try> python3 int_speed_test.py
    2 ** 6 is 2 ** 6: True
    1000000 iterations of “a = 2 ** 6 // 2 ** 4” took 0.0230309s = 2.30309e-08s/iteration
    2 ** 9 is 2 ** 9: False
    1000000 iterations of “a = 2 ** 9 // 2 ** 6” took 0.0231234s = 2.31234e-08s/iteration
    2 ** 20 is 2 ** 20: False
    1000000 iterations of “a = 2 ** 20 // 2 ** 12” took 0.020053s = 2.0053e-08s/iteration
    2 ** 64 is 2 ** 64: False
    1000000 iterations of “a = 2 ** 64 // 2 ** 32” took 0.0182259s = 1.82259e-08s/iteration
    2 ** 96 is 2 ** 96: False
    1000000 iterations of “a = 2 ** 96 // 2 ** 64” took 0.0173797s = 1.73797e-08s/iteration

As you can see, Python 3 is actually *faster* than Python 2, particularly with smaller-magnitude integers.

[toc] | [prev] | [next] | [standalone]

#110760

On Wed, Jun 29, 2016 at 4:45 PM, Steven D'Aprano
<steve+comp.lang.python@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. (For example: You're
creating and disposing of large numbers of objects, so the performance
of object creation could affect things hugely.) To make it somewhat
fairer, add long integer performance to the mix. Starting by redoing
your test:

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
rosuav@sikorsky:~$ python3.4 -m timeit -s "n = 0" "for i in
range(10000): n += i"
1000 loops, best of 3: 328 usec per loop
rosuav@sikorsky:~$ python3.4 -m timeit -s "n = 1<<100" "for i in
range(10000): n += i"
1000 loops, best of 3: 337 usec per loop
rosuav@sikorsky:~$ python3.5 -m timeit -s "n = 0" "for i in
range(10000): n += i"
1000 loops, best of 3: 369 usec per loop
rosuav@sikorsky:~$ python3.5 -m timeit -s "n = 1<<100" "for i in
range(10000): n += i"
1000 loops, best of 3: 356 usec per loop
rosuav@sikorsky:~$ python3.6 -m timeit -s "n = 0" "for i in
range(10000): n += i"
1000 loops, best of 3: 339 usec per loop
rosuav@sikorsky:~$ python3.6 -m timeit -s "n = 1<<100" "for i in
range(10000): n += i"
1000 loops, best of 3: 343 usec per loop

(On this system, python3.4 and python3.5 are Debian-shipped builds of
CPython, and python3.6 is one I compiled from hg today. There's no
visible variance between them, but just in case. I don't have a
python3.3 on here for a fair comparison with your numbers, sorry.)

The way I read this, Python 2.7 is noticeably slower with bignums, but
visibly faster with machine words. Python 3, on the other hand, has
consistent performance whether the numbers fit within a machine word
or not - which is to be expected, since it uses bignums for all
integers. PyPy's performance shows an even more dramatic gap:

rosuav@sikorsky:~$ pypy -m timeit -s "n = 0" "for i in xrange(10000): n += i"
100000 loops, best of 3: 7.59 usec per loop
rosuav@sikorsky:~$ pypy -m timeit -s "n = 1<<100" "for i in
xrange(10000): n += i"
10000 loops, best of 3: 119 usec per loop
rosuav@sikorsky:~$ pypy --version
Python 2.7.10 (5.1.2+dfsg-1, May 17 2016, 18:03:30)
[PyPy 5.1.2 with GCC 5.3.1 20160509]

Sadly, Debian doesn't ship a pypy3 yet, so for consistency, I picked
up the latest available pypy2 and pypy3 from pypy.org.

rosuav@sikorsky:~/tmp$ pypy2-v5.3.1-linux64/bin/pypy -m timeit -s "n =
0" "for i in xrange(10000): n += i"
100000 loops, best of 3: 7.58 usec per loop
rosuav@sikorsky:~/tmp$ pypy2-v5.3.1-linux64/bin/pypy -m timeit -s "n =
1<<100" "for i in xrange(10000): n += i"
10000 loops, best of 3: 115 usec per loop
rosuav@sikorsky:~/tmp$ pypy3.3-v5.2.0-alpha1-linux64/bin/pypy3 -m
timeit -s "n = 0" "for i in range(10000): n += i"
100000 loops, best of 3: 7.56 usec per loop
rosuav@sikorsky:~/tmp$ pypy3.3-v5.2.0-alpha1-linux64/bin/pypy3 -m
timeit -s "n = 1<<100" "for i in range(10000): n += i"
10000 loops, best of 3: 115 usec per loop

Performance comparable to each other (and to the Debian-shipped one,
which is nice - as Adam Savage said, I love consistent data!), and
drastically different between machine words and bignums. So it looks
like PyPy *does* have some sort of optimization going on here, without
ever violating the language spec.

ChrisA

[toc] | [prev] | [next] | [standalone]

#110774

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.python@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.

[toc] | [prev] | [next] | [standalone]

#110776

On 29/06/2016 13:36, Steven D'Aprano wrote:
> On Wed, 29 Jun 2016 06:09 pm, Chris Angelico wrote:

>> 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.

> 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 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.

I think there are too many things going on in CPython that would 
dominate matters beyond the actual integer arithmetic.

I used this little benchmark:

def fn():
     n=0
     for i in range(1000000):
         n+=i

for k in range(100):
     fn()

With CPython, Python 2 took 21 seconds (20 with xrange), while Python 3 
was 12.3 seconds (fastest times).

I then ran the equivalent code under my own non-Python interpreter (but 
a version using 100% C to keep the test fair), and it was 2.3 seconds.

(That interpreter keeps 64-bit integers and bigints separate. The 64-bit 
integers are also value-types, not reference-counted objects.)

When I tried optimising versions, then PyPy took 7 seconds, while mine 
took 0.5 seconds.

Testing the same code as C, then unoptimised it was 0.4 seconds, and 
optimised, 0.3 seconds (but n was declared 'volatile' to stop the loop 
being eliminated completely).

So the actual work involved takes 0.3 seconds. That means Python 3 is 
spending 12.0 seconds dealing with overheads. The extra ones of dealing 
with bigints would get lost in there!

(If I test that same code using an explicit bigint for n, then it's a 
different story. It's too complicated to test for C, but it will likely 
be a lot more than 0.3 seconds. And my bigint library is hopelessly 
slow, taking some 35 seconds.

So from that point of view, Python is doing a good job of managing a 
12-second time using a composite integer/bigint type.

However, the vast majority of integer code /can be done within 64 bits/. 
Within 32 bits probably. But like I said, it's possible that other 
overheads come into play than just the ones of using bigints, which I 
would imagine are streamlined.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110779

On Wed, Jun 29, 2016 at 11:24 PM, BartC <bc@freeuk.com> wrote:
> I used this little benchmark:
>
> def fn():
>     n=0
>     for i in range(1000000):
>         n+=i
>
> for k in range(100):
>     fn()

Add, up the top:

try: range = xrange
except NameError: pass

Otherwise, your Py2 tests are constructing a million-element list,
which is a little unfair.

ChrisA

[toc] | [prev] | [next] | [standalone]

#110781

On 29/06/2016 14:35, Chris Angelico wrote:
> On Wed, Jun 29, 2016 at 11:24 PM, BartC <bc@freeuk.com> wrote:
>> I used this little benchmark:
>>
>> def fn():
>>     n=0
>>     for i in range(1000000):
>>         n+=i
>>
>> for k in range(100):
>>     fn()
>
> Add, up the top:
>
> try: range = xrange
> except NameError: pass
>
> Otherwise, your Py2 tests are constructing a million-element list,
> which is a little unfair.

It made little difference (21 seconds instead of 20 seconds).

But that was on Windows. I remember that Python was much more sluggish 
on Windows than under Ubuntu on the same machine. (Maybe the Windows 
version was 32-bits or something.)

Trying it on Ubuntu, Py2 takes 6 seconds (using xrange otherwise it's 9 
seconds) , while pypy (2.7) manages 0.35 seconds.

pypy normally excels with such loops, but I recall also that it had some 
trouble with this particular benchmark, which this version must have fixed.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#110763

On 29/06/2016 06:26, 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.
>
> In principle Python might use native 32 or 64 bit ints for small values and
> secretly promote them to BIGNUMs when needed, but as far as I know no
> implementation of Python currently does this.

Presumably the implementation of BIGNUMs would already do something like 
this: a number that fits into 64 bits would only use 64 bits. The 
overheads of dealing with both small BIGNUMs and big ones, or a mix, 
might be lost in the other overheads of CPython.

But I remember when playing with my tokeniser benchmarks earlier this 
year that switching from dealing with strings, to integers, didn't make 
things much faster (I think they actually made it slower sometimes).

Even if Python has extremely efficient string handling, we know that 
low-level string ops normally take longer than low-level integer ops.

So maybe small-integer handling already had enough overhead that 
implementing them as small BIGNUMs didn't make much difference, but it 
simplified the language.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110764

On Wednesday, June 29, 2016 at 9:49:23 PM UTC+12, BartC wrote:
> Even if Python has extremely efficient string handling, we know that 
> low-level string ops normally take longer than low-level integer ops.

Maybe part of the general principle that, on modern machines, memory is cheap, but accessing memory is expensive?

[toc] | [prev] | [next] | [standalone]

#110766

On 29/06/2016 10:56, Lawrence D’Oliveiro wrote:
> On Wednesday, June 29, 2016 at 9:49:23 PM UTC+12, BartC wrote:
>> Even if Python has extremely efficient string handling, we know that
>> low-level string ops normally take longer than low-level integer ops.
>
> Maybe part of the general principle that, on modern machines, memory is cheap, but accessing memory is expensive?
>

No, it's just fewer instructions. If you do the equivalent of a==b where 
both are integers, it might be a couple of instructions in native code.

If both are strings, even of one character each (say the code is 
choosing to compare "A" with "B" instead of ord("A") with ord("B"), then 
it's a /lot/ more than two instructions.

(With Python there's the side-issue of actually getting the integer 
values. Having to call ord() doesn't help the case for using integers.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110768

On Wednesday, June 29, 2016 at 8:06:10 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 28 Jun 2016 12:10 am, Rustom Mody wrote:
> 
> > Analogy: Python's bool as 1½-class because bool came into python a good
> > decade after python and breaking old code is a bigger issue than fixing
> > control constructs to be bool-strict
> 
> That analogy fails because Python bools being implemented as ints is not a
> bug to be fixed, but a useful feature.
> 
> There are downsides, of course, but there are also benefits. It comes down
> to a matter of personal preference whether you think that bools should be
> abstract True/False values or concrete 1/0 values. Neither decision is
> clearly wrong, it's a matter of what you value.
> 
> Whereas some decisions are just dumb:
> 
> https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/

Answered in "Operator Precedence/Boolean" thread where this is more relevant

[toc] | [prev] | [next] | [standalone]

#110593

Grant Edwards <grant.b.edwards@gmail.com> writes:

> On 2016-06-26, BartC <bc@freeuk.com> wrote:
>
>> (Note, for those who don't know (old) Fortran, that spaces and tabs are 
>> not significant. So those dots are needed, otherwise "a eq b" would be 
>> parsed as "aeqb".)
>
> I've always been baffled by that.
> Were there other languages that did something similar?

Probably a lot at that time.

> Why would a language designer think it a good idea?

Because when you punch characters one by one on a card, you quickly get
bored with less-than-useful spaces.

> Did the poor sod who wrote the compiler think it was a good idea?

I don't know, but he has a good excuse: he was one of the first to ever
write a compiler (see https://en.wikipedia.org/wiki/Compiler, the
section on History).

You just called John Backus a "poor sod". Think again.

-- Alain.

[toc] | [prev] | [next] | [standalone]

#110645

On Monday, June 27, 2016 at 8:19:05 PM UTC+5:30, Alain Ketterlin wrote:
> Grant Edwards writes:
> > Did the poor sod who wrote the compiler think it was a good idea?
> 
> I don't know, but he has a good excuse: he was one of the first to ever
> write a compiler (see https://en.wikipedia.org/wiki/Compiler, the
> section on History).
> 
> You just called John Backus a "poor sod". Think again.

The irony is bigger than you are conveying
1957: Backus made Fortran
20 years later: [1977] He won the Turing award, citation explicitly mentioning
his creation of Fortran.
His Turing award lecture 
makes a demand for an alternative functional language (first usage of FP that 
I know) and lambasts traditional imperative programming language.
http://worrydream.com/refs/Backus-CanProgrammingBeLiberated.pdf

However in addition to lambasting current languages in general he owns up to 
his own contribution to the imperative-programming-goofup:

| I refer to conventional languages as "von Neumann languages" to take note of 
| their origin and style, I do not, of course, blame the great mathematician for
| their complexity. In fact, some might say that I bear some responsibility for 
| that problem.

I conjecture that it was Backus' clarion call to think more broadly about
paradigms and not merely about syntax details that prompted the next Turing
talk: Floyd's title (1978) *is* Paradigms of Programming though he did not use 
the word quite as we do today

Likewise Backus' call to dump the imperative 'word-at-a-time' model and look
to APL to inspiration probably made it possible for an outlier like Iverson to
win the Turing award in 79

All these taken together have inched CS slowly away from the imperative paradigm:
This and other titbits of history: http://blog.languager.org/2015/04/cs-history-1.html

In short for someone in 2016 to laugh at Backus for 1957 mistakes that he had
already realized and crossed over in 1977, and yet continue to use the 
imperative paradigm ie the 57-mistake... well the joke is in the opposite direction

[toc] | [prev] | [next] | [standalone]

#110630

On Mon, 27 Jun 2016 11:59 pm, Grant Edwards wrote:

> On 2016-06-26, BartC <bc@freeuk.com> wrote:
> 
>> (Note, for those who don't know (old) Fortran, that spaces and tabs are
>> not significant. So those dots are needed, otherwise "a eq b" would be
>> parsed as "aeqb".)
> 
> I've always been baffled by that.
> 
> Were there other languages that did something similar?
> 
> Why would a language designer think it a good idea?
> 
> Did the poor sod who wrote the compiler think it was a good idea?

I don't know if it was a deliberate design decision or not, but I don't
believe that it survived very many releases of the Fortran standard.

Remember that Fortran was THE first high-level language. Its creator, John
Backus, was breaking new ground and doing things that had never been done
before[1], so the things that we take for granted about high-level
programming languages were still being invented. If early Fortran got a few
things wrong, we shouldn't be surprised.

Also the earliest Fortran code was not expected to be typed into a computer.
It was expected to be entered via punched cards, which eliminates the need
for spaces.



[1] Almost. He has previously created a high-level assembly language,
Speedcoding, for IBM, which can be considered the predecessor of Fortran.

-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#110596

On 2016-06-27 14:59, Grant Edwards wrote:
> On 2016-06-26, BartC <bc@freeuk.com> wrote:
>
>> (Note, for those who don't know (old) Fortran, that spaces and tabs are
>> not significant. So those dots are needed, otherwise "a eq b" would be
>> parsed as "aeqb".)
>
> I've always been baffled by that.
>
> Were there other languages that did something similar?
>
Algol 60 and Algog 68.

> Why would a language designer think it a good idea?
>
It let you have identifiers like "grand total"; there was no need for 
camel case or underscores to separate the parts of the name.

> Did the poor sod who wrote the compiler think it was a good idea?
>

[toc] | [prev] | [next] | [standalone]

#110612

On Tuesday, June 28, 2016 at 3:27:40 AM UTC+12, MRAB wrote:
>
> On 2016-06-27 14:59, Grant Edwards wrote:
>>
>> Were there other languages that did something similar?
>>
> Algol 60 and Algog 68.

Algol 68 was actually slightly different. There were two separate alphabets: one used for names of constants, variables, routines and labels, where spaces were ignored, and a different one used for type names (called “modes”) and reserved words, where spaces were significant.

The convention was to use lowercase for the former and uppercase for the latter.

Example here <http://www.codecodex.com/wiki/Perform_simple_mathematical_operations_on_two_matrices#Algol_68>.

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web