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

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

Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1")

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

Contents

  Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Andreas Löscher <andreas.loescher@s2005.tu-chemnitz.de> - 2011-08-21 19:27 +0200
    Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 10:48 -0700
      Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 11:03 -0700
    Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Christian Heimes <lists@cheimes.de> - 2011-08-21 20:24 +0200
      Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Roy Smith <roy@panix.com> - 2011-08-21 14:52 -0400
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Andreas Löscher <andreas.loescher@s2005.tu-chemnitz.de> - 2011-08-22 01:17 +0200
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Chris Angelico <rosuav@gmail.com> - 2011-08-22 00:37 +0100
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Terry Reedy <tjreedy@udel.edu> - 2011-08-21 19:38 -0400
            Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Andreas Löscher <andreas.loescher@s2005.tu-chemnitz.de> - 2011-08-22 02:00 +0200
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Seebs <usenet-nospam@seebs.net> - 2011-08-22 05:33 +0000
    Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Terry Reedy <tjreedy@udel.edu> - 2011-08-21 15:39 -0400
      Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 12:53 -0700
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 12:55 -0700
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 12:55 -0700
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-22 11:12 +1000
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") "Richard D. Moores" <rdmoores@gmail.com> - 2011-08-22 02:55 -0700
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Emile van Sebille <emile@fenx.com> - 2011-08-22 09:35 -0700
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Emile van Sebille <emile@fenx.com> - 2011-08-22 10:22 -0700
      Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 13:04 -0700
      Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 12:53 -0700
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Andreas Löscher <andreas.loescher@s2005.tu-chemnitz.de> - 2011-08-22 01:25 +0200
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Chris Angelico <rosuav@gmail.com> - 2011-08-22 00:41 +0100
            Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-22 11:16 +1000
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Christian Heimes <lists@cheimes.de> - 2011-08-22 04:04 +0200
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Terry Reedy <tjreedy@udel.edu> - 2011-08-21 22:11 -0400
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Stephen Hansen <me+list/python@ixokai.io> - 2011-08-21 19:08 -0700
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-22 14:14 +1000
            Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Stephen Hansen <me+list/python@ixokai.io> - 2011-08-21 21:37 -0700
            Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Stephen Hansen <me+list/python@ixokai.io> - 2011-08-21 21:49 -0700
    Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") casevh <casevh@gmail.com> - 2011-08-21 21:14 -0700

Page 2 of 2 — ← Prev page 1 [2]

#11969

Am Sonntag, den 21.08.2011, 12:53 -0700 schrieb Laurent:
> > With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with 
> > floats (0.0 and 1.0), 6%
> 
> For floats it is understandable. But for integers, seriously, 4% is a lot. I would never have thought an interpreter would have differences like this in syntax for something as fundamental as adding 1.

It's not as bad as you think. The addition of two integers is a cheap
task (in terms of computation power). If you have two way's to to it,
every little think (jumps in the code etc. ) will have a larger impact
on the execution time than on an expensive operation.

But every improvement on your algorithm will easily result in a
significant shorter execution time than replaceing a+=1 with a=a+1 will
ever do. :-)

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

#11972

2011/8/22 Andreas Löscher <andreas.loescher@s2005.tu-chemnitz.de>:
> But every improvement on your algorithm will easily result in a
> significant shorter execution time than replaceing a+=1 with a=a+1 will
> ever do. :-)
>

Agreed. If Python needed a faster alternative to "a=a+1", then I would
recommend an "a.inc()" call or something; some way to avoid looking up
the value of 1. (An equivalent to C's ++a operation, if you like.) But
I think you'd be hard-pressed to find any situation where improving
the speed of incrementing will be significant, that wouldn't be better
served by algorithmic improvements (even just using "for a in
range()") or dropping to C.

ChrisA

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

#11980

Chris Angelico wrote:

> 2011/8/22 Andreas Löscher <andreas.loescher@s2005.tu-chemnitz.de>:
>> But every improvement on your algorithm will easily result in a
>> significant shorter execution time than replaceing a+=1 with a=a+1 will
>> ever do. :-)
>>
> 
> Agreed. If Python needed a faster alternative to "a=a+1", then I would
> recommend an "a.inc()" call or something; some way to avoid looking up
> the value of 1.

Keep in mind that ints in Python are objects, not memory locations, and can
be shared. If you are hoping for an in-place increment, I invite you to
consider the following code and try to predict what it would do:

a = 42
b = a
b.inc()
print(a)



-- 
Steven

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

#11983

Am 22.08.2011 01:25, schrieb Andreas Löscher:
> It's not as bad as you think. The addition of two integers is a cheap
> task (in terms of computation power). If you have two way's to to it,
> every little think (jumps in the code etc. ) will have a larger impact
> on the execution time than on an expensive operation.
> 
> But every improvement on your algorithm will easily result in a
> significant shorter execution time than replaceing a+=1 with a=a+1 will
> ever do. :-)

You can learn an important lesson here. Since Python is a high level
language without a JIT (yet) integer operations are much slower than in
C or other low level languages. In general it's not a problem for most
people. However if your algorithm is speed bound to integer operations
or has a tight inner for loop than you can gain a considerable amount of
speedup with C code. Reference counting and Python object creation need
several CPU cycles. Also a good algorithm and a modern C compiler can
make use of SIMD instructions, too.

If you ever feel the need to implement something fast e.g. an encryption
algorithm then you'd better off with a C implementation. Cython is my
favourite tool for the job.

Christian

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

#11986

On 8/21/2011 7:41 PM, Chris Angelico wrote:

> Agreed. If Python needed a faster alternative to "a=a+1", then I would
> recommend an "a.inc()" call or something

But looking up the method name, creating a bound method wrapper, and 
making the call would probably be slower than the syntax;-).

-- 
Terry Jan Reedy

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

#11984

[Multipart message — attachments visible in raw view] — view raw

On 8/21/11 12:53 PM, Laurent wrote:
> 
>> With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with 
>> floats (0.0 and 1.0), 6%
> 
> For floats it is understandable. But for integers, seriously, 4% is a lot. I would never have thought an interpreter would have differences like this in syntax for something as fundamental as adding 1.

Its, seriously, not even kind of a lot at all. Percentages without
context are meaningless: its 4% slower, sure -- but that is 4% of an
incredibly small probably constant-time amount of time.

Picking "i += 1" over "i = i + 1" based on one being 4% slower is sorta
kinda crazy. The difference in speed is probably related to churn and
cache as much as anything else (its not as consistent on my machine, for
example): or the ceval loop doing a few more case-tests between them as
others have mentioned. All in all, if 4% of a nanomicrofraction of a
chunk of time is that meaningful, you're probably best served not using
Python. :)

That said: my advice is always to avoid += like a plague. It is magic
and impossible to predict without intimate knowledge of exactly what's
on the left-side.

   i += 1
   n += x

Those two things look very similar, but they may do -completely-
different things depending on just what "n" is.

It may or may not do something that is like:

    n = n + x

Or, it may do something that's more akin to

    n.extend(x)
    n = n

Those aren't even kind of equivalent actions. And things get more
complicated if 'n' is say, n[0] (especially if something goes wrong
between the extend and the rebinding).

Python's usually all explicit and pretty well-defined in how its basic
syntax and behaviors operate, and you usually don't really have to know
details about how a data-type works to predict exactly what it's doing:
in fact, its often beneficial to not pay too much attention to such
details, and just assume the data type will work approximately as you'd
expect. That way people can slip something-something to you and wink and
say of /course/ its a dict, darling. Try it, you'll like it, okay? This
sorta thing is encouraged, but it kinda depends on trusting objects to
behave a certain way and for things to be predictable in both how they
work and how they fail.

With "i = i + 1", I know that generally speaking, my "i" is being
assigned a new object and that's that, no matter what type "i" is.
(Okay: I do know that you could modify __add__ to do something
underhanded here, tweaking internal state and then returning self.
People going out of their way to behave unpredictably is not my
objection: supposedly easy and straight-forward normal Python-fu being
inherently unpredictable is).

For example: I just /know/ that it doesn't matter who or what may have
their own binding to that object before I go and increment it, they
won't be affected and everything just will work fine. With augmented
assignment, I can't be sure of that. Now, while I admit, you generally
do have to keep track in your head of which of your data-types are
mutable vs immutable and take care with sharing mutables, the fact that
"n += x" is described and generally thought of as merely syntactical
sugar for:

   n = n + x

... lets one easily think that this should be entirely safe, even with
mutable objects, because if += were merely syntactical sugar, it would
be. But its not! Because += is wiggly. It can do more then one entirely
different kind of behavior.

Anyways. </rant> I've been kinda annoyed at augmented assignment for
years now :P

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/

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

#11989

On Mon, 22 Aug 2011 12:08 pm Stephen Hansen wrote:

> Picking "i += 1" over "i = i + 1" based on one being 4% slower is sorta
> kinda crazy. The difference in speed is probably related to churn and
> cache as much as anything else (its not as consistent on my machine, for
> example): or the ceval loop doing a few more case-tests between them as
> others have mentioned. All in all, if 4% of a nanomicrofraction of a
> chunk of time is that meaningful, you're probably best served not using
> Python. :)

Agreed.

But...

> That said: my advice is always to avoid += like a plague. It is magic
> and impossible to predict without intimate knowledge of exactly what's
> on the left-side.
> 
>    i += 1
>    n += x
> 
> Those two things look very similar, but they may do -completely-
> different things depending on just what "n" is.


Technically, the *exact same criticism* can be applied to:

n = n + x

since either n or x could override __add__ or __radd__ and do anything it
bloody well likes. Including in-place modification of *either* argument
(where possible).


[...]
> With "i = i + 1", I know that generally speaking, my "i" is being
> assigned a new object and that's that, no matter what type "i" is.
> (Okay: I do know that you could modify __add__ to do something
> underhanded here, tweaking internal state and then returning self.

What makes you think that's underhanded?

To my mind, __add__ modifying self as a side-effect is unusual, but apart
from breaking the general rule of thumb to avoid side-effects, not
particularly evil. (But I would accept this is a code smell.)


> People going out of their way to behave unpredictably is not my
> objection: supposedly easy and straight-forward normal Python-fu being
> inherently unpredictable is).
> 
> For example: I just /know/ that it doesn't matter who or what may have
> their own binding to that object before I go and increment it, they
> won't be affected and everything just will work fine. 

But you can't /know/ that at all, unless you know that the object
isn't "underhanded" (however you define that!). And given some arbitrary
object, how can you know that?



-- 
Steven

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

#11991

[Multipart message — attachments visible in raw view] — view raw

On 8/21/11 9:14 PM, Steven D'Aprano wrote:
>> That said: my advice is always to avoid += like a plague. It is magic
>> and impossible to predict without intimate knowledge of exactly what's
>> on the left-side.
>>
>>    i += 1
>>    n += x
>>
>> Those two things look very similar, but they may do -completely-
>> different things depending on just what "n" is.
> 
> Technically, the *exact same criticism* can be applied to:
> 
> n = n + x
> 
> since either n or x could override __add__ or __radd__ and do anything it
> bloody well likes. Including in-place modification of *either* argument
> (where possible).

I know: I addressed that. :P See, you know I addressed that, because:

> [...]
>> With "i = i + 1", I know that generally speaking, my "i" is being
>> assigned a new object and that's that, no matter what type "i" is.
>> (Okay: I do know that you could modify __add__ to do something
>> underhanded here, tweaking internal state and then returning self.
> 
> What makes you think that's underhanded?

You quoted me addressing that very fact, and responded! :)

Its underhanded outside of narrow, well-defined situations such as ORM's
and the like where they're doing interesting and novel things with the
object model.

Underhanded doesn't mean there's no reason one should ever do it, but
its very much an unusual thing and objects that do things like that
should NOT freely interact with general Python objects: very surprising
behavior will result.

> To my mind, __add__ modifying self as a side-effect is unusual, but apart
> from breaking the general rule of thumb to avoid side-effects, not
> particularly evil. (But I would accept this is a code smell.)

I didn't really say its evil, just that its underhanded: that's like,
sketchy, not evil. :)

There's good reasons to do it on occasion, but if an object does
something like that then that is a very special kind of object and when
using it, you need to be very aware of its unusual semantics.

Having objects like that is fine.

However, for the /language/ to have unusual (and unpredictable, from
something of a distance at least) semantics, rubs me very much the wrong
way.

>> People going out of their way to behave unpredictably is not my
>> objection: supposedly easy and straight-forward normal Python-fu being
>> inherently unpredictable is).
>>
>> For example: I just /know/ that it doesn't matter who or what may have
>> their own binding to that object before I go and increment it, they
>> won't be affected and everything just will work fine. 
> 
> But you can't /know/ that at all, unless you know that the object
> isn't "underhanded" (however you define that!). And given some arbitrary
> object, how can you know that?

I CAN know it with sufficient certainty that I can rely on it, and if I
get messed up on it-- its never happened yet-- then I can fire someone
or get a new library, after staring at an odd traceback and scratching
my head for a minute.

Python has very soft rules, I know that. Objects /can/ do all kinds of
crazy things. I'm okay with that.

But I can rely on certain behaviors being consistent: the basic behavior
of the language is very straight-forward. It has hooks where you can do
lots of Special stuff, and if objects are Special, they're described as
Special.

ORM's have a lot of Special objects, for example. That's fine: when
messing with ORM objects, I know I have to take care with the operators
I use against them, because I know I'm not using a /usual/ Python
object. SQLAlchemy for example. This is not a criticism of SQLAlchemy:
having magic objects lets it construct SQL in ways that are vastly
easier then if they stuck to more regularly behaving objects.

But, += is Python itself adding an unpredictable behavior into the core
language, with its own base types behaving

The *exact same criticism* can NOT be applied to

    n = n + x

Because my criticism isn't about one choosing to do crazy stuff with the
object model. I've never advocated Python be strict about rules.

But for Python, all by itself, with nothing but built-in and basic
types, to have a situation where:

    a = a + b
    a += b

... does two very distinctly different actions, even if in many or
even most circumstances the end-result is probably the same and probably
fine, is my criticism.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/

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

#11992

[Multipart message — attachments visible in raw view] — view raw

On 8/21/11 9:37 PM, Stephen Hansen wrote:
> But, += is Python itself adding an unpredictable behavior into the core
> language, with its own base types behaving

... very differently to fundamental, basic appearing operators.

Editing fail on my part.

Similarly:

> But for Python, all by itself, with nothing but built-in and basic
> types, to have a situation where:
> 
>     a = a + b
>     a += b

... would be clearer if the second example were "x += y".

> ... does two very distinctly different actions, even if in many or
> even most circumstances the end-result is probably the same and probably
> fine, is my criticism.
> 

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/

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

#11990

On Aug 21, 10:27 am, Andreas Löscher <andreas.loesc...@s2005.tu-
chemnitz.de> wrote:
>
> from Python/ceval.c:
>
> 1316            case BINARY_ADD:
> 1317                w = POP();
> 1318                v = TOP();
> 1319                if (PyInt_CheckExact(v) && PyInt_CheckExact(w)) {
> 1320                    /* INLINE: int + int */
> 1321                    register long a, b, i;
> 1322                    a = PyInt_AS_LONG(v);
> 1323                    b = PyInt_AS_LONG(w);
> 1324                    /* cast to avoid undefined behaviour
> 1325                       on overflow */
> 1326                    i = (long)((unsigned long)a + b);
> 1327                    if ((i^a) < 0 && (i^b) < 0)
> 1328                        goto slow_add;
> 1329                    x = PyInt_FromLong(i);
> 1330                }
> 1331                else if (PyString_CheckExact(v) &&
> 1332                         PyString_CheckExact(w)) {
> 1333                    x = string_concatenate(v, w, f, next_instr);
> 1334                    /* string_concatenate consumed the ref to v */
> 1335                    goto skip_decref_vx;
> 1336                }
> 1337                else {
> 1338                  slow_add:
> 1339                    x = PyNumber_Add(v, w);
> 1340                }
> 1341                Py_DECREF(v);
> 1342              skip_decref_vx:
> 1343                Py_DECREF(w);
> 1344                SET_TOP(x);
> 1345                if (x != NULL) continue;
> 1346                break;
>
> 1532            case INPLACE_ADD:
> 1533                w = POP();
> 1534                v = TOP();
> 1535                if (PyInt_CheckExact(v) && PyInt_CheckExact(w)) {
> 1536                    /* INLINE: int + int */
> 1537                    register long a, b, i;
> 1538                    a = PyInt_AS_LONG(v);
> 1539                    b = PyInt_AS_LONG(w);
> 1540                    i = a + b;
> 1541                    if ((i^a) < 0 && (i^b) < 0)
> 1542                        goto slow_iadd;
> 1543                    x = PyInt_FromLong(i);
> 1544                }
> 1545                else if (PyString_CheckExact(v) &&
> 1546                         PyString_CheckExact(w)) {
> 1547                    x = string_concatenate(v, w, f, next_instr);
> 1548                    /* string_concatenate consumed the ref to v */
> 1549                    goto skip_decref_v;
> 1550                }
> 1551                else {
> 1552                  slow_iadd:
> 1553                    x = PyNumber_InPlaceAdd(v, w);
> 1554                }
> 1555                Py_DECREF(v);
> 1556              skip_decref_v:
> 1557                Py_DECREF(w);
> 1558                SET_TOP(x);
> 1559                if (x != NULL) continue;
> 1560                break;
>
> As for using Integers, the first case (line 1319 and 1535) are true and
> there is no difference in Code. However, Python uses a huge switch-case
> construct to execute it's opcodes and INPLACE_ADD cames after
> BINARY_ADD, hence the difference in speed.

That fragment of cevel.c is from a 2.x version. Python 2.x supports
both a PyInt and PyLong type and the cevel loop optimized the PyInt
case only. On my system, I could not measure a difference between
binary and inplace addition.

Python 3.x behaves differently:

        TARGET(BINARY_ADD)
            w = POP();
            v = TOP();
            if (PyUnicode_CheckExact(v) &&
                     PyUnicode_CheckExact(w)) {
                x = unicode_concatenate(v, w, f, next_instr);
                /* unicode_concatenate consumed the ref to v */
                goto skip_decref_vx;
            }
            else {
                x = PyNumber_Add(v, w);
            }
            Py_DECREF(v);
          skip_decref_vx:
            Py_DECREF(w);
            SET_TOP(x);
            if (x != NULL) DISPATCH();
            break;

        TARGET(INPLACE_ADD)
            w = POP();
            v = TOP();
            if (PyUnicode_CheckExact(v) &&
                     PyUnicode_CheckExact(w)) {
                x = unicode_concatenate(v, w, f, next_instr);
                /* unicode_concatenate consumed the ref to v */
                goto skip_decref_v;
            }
            else {
                x = PyNumber_InPlaceAdd(v, w);
            }
            Py_DECREF(v);
          skip_decref_v:
            Py_DECREF(w);
            SET_TOP(x);
            if (x != NULL) DISPATCH();
            break;

cevel just calls PyNumber_Add or PyNumber_InPlaceAdd. If you look at
the code for PyNumber_InPlaceAdd (in abstract.c), it calls an internal
function binary_iop1 with pointers to nb_inplace_add and nb_add.
binary_iop1 then checks if nb_inplace_add exists. The PyLong type does
not implement nb_inplace_add so the check fails and binary_iop1 used
nb_add.

In recent version of gmpy and gmpy2, I implemented the nb_inplace_add
function and performance (for the gmpy.mpz type) is much better for
the in-place addition.

For the adventuresome, gmpy2 implements a mutable integer type called
xmpz. It isn't much faster until the values are so large that the
memory copy times become significant. (Some old gmpy documentation
implies that operations with mutable integers should be much faster.
With agressive caching of deleted objects, the object creation
overhead is very low. So the big win for mutable integers is reduced
to avoiding memory copies.)

casevh

>
> To be clear, this is nothing you should consider when writing fast code.
> Complexity wise they both are the same.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web