3 ms·

If you want to test your theory, you can look at the implementation of those opcodes. Here's INPLACE_ADD: https://github.com/python/cpython/blob/874809ea389e6

If you want to test your theory, you can look at the implementation of those opcodes. Here's INPLACE_ADD: https://github.com/python/cpython/blob/874809ea389e6434787e773a6054a08e0b81f734/Python/ceval.c#L1486 https://github.com/python/cpython/blob/874809ea389e6434787e7... And here's BINARY_ADD: https://github.com/python/cpython/blob/874809ea389e6434787e773a6054a08e0b81f734/Python/ceval.c#L1280 https://github.com/python/cpython/blob/874809ea389e6434787e7... They're almost identical :)

hyperpape 8y ago
Thanks for the links! However: Line 1296 is PyNumber_Add(left, right) Line 1495 is PyNumber_InPlaceAdd(left, right) Those go to: PyNumber_Add https://github.com/python/cpython/blob/874809ea389e6434787e773a6054a08e0b81f734/Objects/abstract.c#L952 https://github.com/python/cpython/blob/874809ea389e6434787e7... PyNumber_InPlaceAdd https://github.com/python/cpython/blob/874809ea389e6434787e773a6054a08e0b81f734/Objects/abstract.c#L1105 https://github.com/python/cpython/blob/874809ea389e6434787e7... And those are different, though I can't tell how it should matter.
- ShroudedNight 8y ago
  > And perhaps the culprit is that INPLACE_ADD requires more work than BINARY ADD It would not surprise me if the culprit was instead: 98 STORE_FAST 2 (a2) 100 LOAD_FAST 3 (c) Due to them being the same amalgamated memory location in practice, with the load hitting the in-flight store. But that's more typical of a POWER performance characteristic than an Intel one...
  - ubernostrum 8y ago
    Here it's worth knowing a bit about how Python manages data. Each CPython VM stack frame has three tuples associated with it: * co_consts is the constant/literal names local to the frame * co_varnames is all other names local to the frame * co_names is the all nonlocal names referenced in the frame Under the hood, Python creates a structure called 'fastlocals' which is basically an array of (pointer to) PyObject, where the PyObject at each index of the array is the value corresponding to the name at the same index of co_varnames. LOAD_FAST and STORE_FAST are extremely simple opcodes; they do a tiny bit of error checking, refcount management (increment on load, decrement on store), and then just manipulate 'fastlocals'. So, for example, 'LOAD_FAST i' consists in its entirety of: 1. Grab the PyObject at fastlocals[i] 2. If it's null, throw an UnboundLocalError 3. Otherwise, increment its refcount and push it to the top of the frame's evaluation stack.

hyperpape 8y ago

Thanks for the links! However: Line 1296 is PyNumber_Add(left, right) Line 1495 is PyNumber_InPlaceAdd(left, right) Those go to: PyNumber_Add https://github.com/python/cpython/blob/874809ea389e6434787e773a6054a08e0b81f734/Objects/abstract.c#L952 https://github.com/python/cpython/blob/874809ea389e6434787e7... PyNumber_InPlaceAdd https://github.com/python/cpython/blob/874809ea389e6434787e773a6054a08e0b81f734/Objects/abstract.c#L1105 https://github.com/python/cpython/blob/874809ea389e6434787e7... And those are different, though I can't tell how it should matter.

ShroudedNight 8y ago
> And perhaps the culprit is that INPLACE_ADD requires more work than BINARY ADD It would not surprise me if the culprit was instead: 98 STORE_FAST 2 (a2) 100 LOAD_FAST 3 (c) Due to them being the same amalgamated memory location in practice, with the load hitting the in-flight store. But that's more typical of a POWER performance characteristic than an Intel one...
- ubernostrum 8y ago
  Here it's worth knowing a bit about how Python manages data. Each CPython VM stack frame has three tuples associated with it: * co_consts is the constant/literal names local to the frame * co_varnames is all other names local to the frame * co_names is the all nonlocal names referenced in the frame Under the hood, Python creates a structure called 'fastlocals' which is basically an array of (pointer to) PyObject, where the PyObject at each index of the array is the value corresponding to the name at the same index of co_varnames. LOAD_FAST and STORE_FAST are extremely simple opcodes; they do a tiny bit of error checking, refcount management (increment on load, decrement on store), and then just manipulate 'fastlocals'. So, for example, 'LOAD_FAST i' consists in its entirety of: 1. Grab the PyObject at fastlocals[i] 2. If it's null, throw an UnboundLocalError 3. Otherwise, increment its refcount and push it to the top of the frame's evaluation stack.