Python and the need for speed

[bartc]

On 13/04/2017 09:08, Steven D'Aprano wrote:
> On Wed, 12 Apr 2017 16:30:38 -0700, bart4858 wrote:
>
>> (Although I think Python would have difficulty in turning x+=1 into a
>> single opcode, if using normal object references and a shared object
>> model.)
>
> You know, since Python actually exists and isn't just a hypothetical
> language, we can find out what it actually does, not just guess :-)
>
>
>>>> import dis
>>>> code = compile("x += 1", "", "single")
>>>> dis.dis(code)
>   1           0 LOAD_NAME                0 (x)
>               3 LOAD_CONST               0 (1)
>               6 INPLACE_ADD
>               7 STORE_NAME               0 (x)
>              10 LOAD_CONST               1 (None)
>              13 RETURN_VALUE
>
>
> There's an op-code for looking up the name 'x', another to push the
> constant 1 on the stack, an op-code for "INPLACE_ADD", followed by an op-
> code for STORE_NAME again.
>
> In principle, we could replace the LOAD_CONST and INPLACE_ADD with a
> single op-code that combines the two. Whether that would speed anything
> up is another question.
>
> Is it possible to skip the STORE_NAME op-code?

If the starting-point is the existing byte-code of a program, then what 
can be done is more limited.

If the optimiser can generate new byte-codes, then it might be possible 
to add an extra indirection, so that:

   LOAD_NAME     (x)

instead becomes (for example):

   LOAD_NAME_REF    (x)
   INPLACE_ADD_REF

The latter doing all the work (indirectly access x, work out x+1 and 
create a new object for that if necessary, then rebind the original x to 
that new value, because now we have a reference to the name).

This means the byte-code set and the work some of them have to do is 
more complex, but it has been suggested that reducing the number of 
byte-code dispatches can be beneficial.

> If you knew *for sure*
> that the target (x) was a mutable object which implemented += using an in-
> place mutation, then you could, but the only built-in where that applies
> is list so even if you could guarantee x was a list, it hardly seems
> worth the bother.

I think x+=y is most usefully optimised when x and y are numbers. But 
numbers can't be modified in-place, not in general.

-- 
bartc