On my machine, the more realistic code, with an implicit C loop, the_value = sum(the_increment for i in range(total_iters)) gives the same value twice as fast as your explicit Python loop. (I cut total_iters down to 10**7).

Your code is faster due to a number of reasons: - range in Python 3 is implemented in C so it's quite faster and, because your range only goes up to 10 ** 7, the fastest iterator is used: rangeiterobject for which the 'next' function is implemented using native longs instead of CPython PyLongs: rangeiter_next(rangeiterobject *r) from rangeobject.c - my code also does some extra work to output a progress indicator

You might check whether sum uses an in-place accumulator for ints. - you're right, sum actually works with native longs until it overflows or you stop adding PyLongs, then it falls back to PyNumber_Add, check: static PyObject * builtin_sum_impl(PyObject *module, PyObject *iterable, PyObject *start) from bltinmodule.c

The focus of this experiment was inplace adds in general. While, as you've shown, there are ways to write the loop optimally, the benchmark was written as a huge loop just to showcase that there is an improvement using this approach. The performance improvement is a result of not having to allocate/deallocate a PyLong per iteration. A huge Python program with lots of PyLong inplace operations (not just adds, this can be applied to all PyLong inplace operations), regardless of them being in a loop or not, might benefit from such an optimization. Thank you, Catalin

On Thu, 31 Aug 2017 23:35:34 +0000 "Manciu, Catalin Gabriel" wrote:

The focus of this experiment was inplace adds in general. While, as you've shown, there are ways to write the loop optimally, the benchmark was written as a huge loop just to showcase that there is an improvement using this approach. The performance improvement is a result of not having to allocate/deallocate a PyLong per iteration.

A huge Python program with lots of PyLong inplace operations (not just adds, this can be applied to all PyLong inplace operations), regardless of them being in a loop or not, might benefit from such an optimization.

I'm skeptical there are some programs out there that are limited by the speed of PyLong inplace additions. Even if you have a bigint-intensive workload (say public-key cryptography, not that it's specifically a good idea to do so in pure Python), chances are it's spending much of its time in more sophisticated operations such as multiplication, power or division. In other words, while your experiment has intellectual and educational interest, I don't think it shows the path to a useful optimization. Regards Antoine.

2017-09-01 13:05 GMT-07:00 Chris Barker :

On Thu, Aug 31, 2017 at 5:12 PM, Antoine Pitrou wrote:

...

I'm skeptical there are some programs out there that are limited by the speed of PyLong inplace additions.

indeed, but that could be said about any number of operations.

My question is -- how can the interpreter know if it can alter what is supposed to be an immutable in-place? If it's used only internally to a function, the it would be safe, but how to know that?

I believe Catalin's implementation checks if the object's refcount is 1. If that is the case, it is safe to mutate it.

-CHB

--

Christopher Barker, Ph.D. Oceanographer

Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ jelle.zijlstra%40gmail.com

On Sat, Sep 2, 2017 at 6:35 AM, Joe Jevnik via Python-Dev wrote:

Is it true that checking for refcount == 1 is enough? What if a user wrote:

args = (compute_integer(), 5) # give away args to someone int.__iadd__(*args)

here `args[0]` still has refcount=1 because only `args` owns this integer.

This particular example is safe, because the arguments get passed individually - so 'args' has one reference, plus there's one more for the actual function call (what would be 'self' if it were implemented in Python). There may be other examples that are more dangerous, but my suspicion is that the nature of += with anything other than a simple name will defeat the optimization, since the owning collection will retain a reference until __iadd__ returns. ChrisA

The string concat optimization happens in the interpreter dispatch for INPLACE_ADD On Fri, Sep 1, 2017 at 9:10 PM, Greg Ewing wrote:

Chris Angelico wrote:

...

This particular example is safe, because the arguments get passed individually - so 'args' has one reference, plus there's one more for the actual function call

However, that's also true when you use the += operator, so if the optimisation is to trigger at all in any useful case, the refcount threshold needs to be set higher than 1.

Some experiments I did suggest that if you set it high enough for x += y to trigger it, then it will also be triggered in Joe's case.

BTW, isn't there already a similar optimisation somewhere for concatenating strings? Does it still exist? How does it avoid this issue?

-- Greg

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/joe% 40quantopian.com

On Sat, 2 Sep 2017 10:38:05 -0700 Chris Barker wrote:

On Fri, Sep 1, 2017 at 6:16 PM, Joe Jevnik via Python-Dev < python-dev@python.org> wrote:

...

The string concat optimization happens in the interpreter dispatch for INPLACE_ADD

In that case, isn't there a new string being build, all in one line of python? that is, the string the optimization is being created at that point, so the interpreter can know there isn't anything referencing it anywhere else.

You can go to the source and check yourself: https://github.com/python/cpython/blob/master/Python/ceval.c#L5226-L5277 Regards Antoine.