4 ms·

I went in thinking this would be data-oriented in the ECS sense, ie., the way that modern games are designed to optimize class structure for cache lines. Howev

I went in thinking this would be data-oriented in the ECS sense, ie., the way that modern games are designed to optimize class structure for cache lines. However it's about the limitations of python's computational model (ie., how it imposes large constant factors on most operations, due to pointer indirection). And how numpy solves that in one case (homogenous arrays). I was hoping it would include a discussion on the julia solution: a sort of partial static-typing, where type information is use to generate optimised code. It should be possible for python to follow a similar route: an (optional?) compilation pass which uses type information to eliminate pointer indirection (, etc.). However I'm not sure how much resistance the actual object model of the VM poses: would you, in effect, just be compiling to a different VM? The present cpython approach to optimization is hacky and specific, eg., sum( a * a for a in range(10) ) is faster than any equivalent loop/etc. approach, because `sum()` has a manually coded fast-path within its implementation.

mlthoughts2018 6y ago
Cython offers the type of targeted compilation options you suggest. Also numba offers them in a more opinionated way that requires less overhead than Cython. These are both long standard tools in scientific Python.
- mjburgess 6y ago
  My hope is that there's some easy, non-trivial, improvements in just basic type awareness, eg., xs: List[Int] = list(range(10)) total : Int = 0 should permit an optimised, for x in xs: total += 1 (almost?) as fast as the equivalent sum. Python hasn't had typing for long enough for this thought to have percolated deeply, ie., I believe at the moment it is just unconsidered rather than infeasible. I suspect that there's a few cases that can be hard coded into the VM that will make a big difference. eg., namedtuple/dataclass, List[String], Dict[String, String], etc.,
  - mlthoughts2018 6y ago
    Unfortunately what you suggest just isn’t conceptually possible (by design) in Python, and would require removing many of the language features that make Python successful for a wide set of use cases. Type hinting (eg List[Int]) has no control over the actual byte layout, it’s just purely metadata. Nothing stops someone from changing xs[4] to be some complex object in your example, regardless of the type hint, so at a pure CPython level it’s fundamentally impossible to benefit from static typing & optimization purely on the basis of type hinting. This is why Cython and numba play that role. They change the location of type metadata - it’s not mere runtime metadata, rather it is compile-time static type annotation in the real sense, for either ahead of time compilation (Cython) or just in time compilation (numba).
    - mjburgess 6y ago
      I'm not convinced. The compiler can emit different byte-code. The proposal includes adding a compiler-aware phase to processing type "hints" (here now, actual static types). If you type code "xs: List[Int]" and try to change xs[4], the compiler (phase) would have to reject your code. This isn't "removing features" as typing is optional. And as long as a lists in "successfully compiled python program" express the same API, it doesnt matter that their implementations differ.
      - mlthoughts2018 6y ago
        > “ If you type code "xs: List[Int]" and try to change xs[4], the compiler (phase) would have to reject your code.” This just can’t work - because lists are mutable, so code that mutates them must be valid and permitted by any such compiler. Similarly, values are dynamically typed, so the value of the assignment might be an int or might not, and it cannot be decided until runtime (and this inability to prove at compile time can’t cause the program to fail to compile, it’s Python). Additionally, Python only has infinite precision ints, so it would be quite hard to get anything useful out of this, unless you wholesale switch to using ctypes or something, but then just use Cython and it will be way easier. I’m not convinced this could ever be anything more than a super limited toy.

mlthoughts2018 6y ago

Cython offers the type of targeted compilation options you suggest. Also numba offers them in a more opinionated way that requires less overhead than Cython. These are both long standard tools in scientific Python.

mjburgess 6y ago
My hope is that there's some easy, non-trivial, improvements in just basic type awareness, eg., xs: List[Int] = list(range(10)) total : Int = 0 should permit an optimised, for x in xs: total += 1 (almost?) as fast as the equivalent sum. Python hasn't had typing for long enough for this thought to have percolated deeply, ie., I believe at the moment it is just unconsidered rather than infeasible. I suspect that there's a few cases that can be hard coded into the VM that will make a big difference. eg., namedtuple/dataclass, List[String], Dict[String, String], etc.,
- mlthoughts2018 6y ago
  Unfortunately what you suggest just isn’t conceptually possible (by design) in Python, and would require removing many of the language features that make Python successful for a wide set of use cases. Type hinting (eg List[Int]) has no control over the actual byte layout, it’s just purely metadata. Nothing stops someone from changing xs[4] to be some complex object in your example, regardless of the type hint, so at a pure CPython level it’s fundamentally impossible to benefit from static typing & optimization purely on the basis of type hinting. This is why Cython and numba play that role. They change the location of type metadata - it’s not mere runtime metadata, rather it is compile-time static type annotation in the real sense, for either ahead of time compilation (Cython) or just in time compilation (numba).
  - mjburgess 6y ago
    I'm not convinced. The compiler can emit different byte-code. The proposal includes adding a compiler-aware phase to processing type "hints" (here now, actual static types). If you type code "xs: List[Int]" and try to change xs[4], the compiler (phase) would have to reject your code. This isn't "removing features" as typing is optional. And as long as a lists in "successfully compiled python program" express the same API, it doesnt matter that their implementations differ.
    - mlthoughts2018 6y ago
      > “ If you type code "xs: List[Int]" and try to change xs[4], the compiler (phase) would have to reject your code.” This just can’t work - because lists are mutable, so code that mutates them must be valid and permitted by any such compiler. Similarly, values are dynamically typed, so the value of the assignment might be an int or might not, and it cannot be decided until runtime (and this inability to prove at compile time can’t cause the program to fail to compile, it’s Python). Additionally, Python only has infinite precision ints, so it would be quite hard to get anything useful out of this, unless you wholesale switch to using ctypes or something, but then just use Cython and it will be way easier. I’m not convinced this could ever be anything more than a super limited toy.