5 ms·

mypyc is cool and all, but I can't help thinking about how Node just JITs everything automatically without the need for any special steps like this.

chrisseaton 4y ago
That's not Node - that's V8. And it's possible to do the same thing for Python - there's nothing magic about JavaScript compared to Python - it's just a lot of engineering work to do it, which is beyond what this project's scope is. PyPy does it, but not inside standard Python.
- peterkelly 4y ago
  I'm well aware of V8 and pypy. I also really like Python as a language, especially with mypy. It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). There is a really important (if not "magic") difference between JavaScript and Python. JS has always (well, since IE added support) been a language with multiple widely-used implementations in the wild, which has prevented the emergence of a third-party package ecosystem which is heavily tied to one particular implementation. Python on the other hand is for a large proportion of the userbase considered CPython, with alternate implementations being second class citizens, despite some truly impressive efforts on the latter. The fact that packages written in JS are not tied to (or at least work best with) a single implementation is also what made it possible for developers of JS engines to experiment with different implementation approaches, including JIT. While I'm not intimately familiar with writing native extension modules for Node (having dabbled only a little), my understanding is the API surface is much narrower than Python, allowing for changes in the engine that avoid breaking APIs. But there is less need for native modules in JS, because of the presence of JIT in all major engines.
  - zzzeek 4y ago
    > It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). this is misleading, if one sees the phrase "interpreter" as that code is represented as syntax-derived trees or other datastructures which are then traversed at runtime to produce results - someone correct me if I'm wrong but this would apply to well known interpreted languages like Perl 5. cPython is a bytecode interpreter, not conceptually unlike the Java VM before JITs were added. It just happens to compile scripts to bytecode on the fly.
    - chrisseaton 4y ago
      Bytecode is just another data structure that you traverse at runtime to produce results. It's a postfix transformation of the AST. It's still an interpreter.
      - an1sotropy 4y ago
        Well, ok, but then isn't a CPU is also just an interpreter, traversing the object code text of compiled code?
        chrisseaton 4y ago
        We don't normally call hardware or firmware implementations an 'interpreter'. Almost all execution techniques include some combination of compilation and interpretation. Even some ASTs include aspects of transformation to construct them from the source code, which we could call a compiler. Native compilers sometimes have to interpret metadata to do things like roll forward for deoptimisation. But most people in the field would describe CPython firmly as an 'interpreter'.
        zzzeek 4y ago
        I call it "bytecode interpreted" to distinguish it from traditional parse-tree interpretation such as Perl 5 and others
- mixmastamyk 4y ago
  Python is a bit more dynamic than JS, which makes it uniquely hard to optimize. There is more improvement to be done however and is being done.
  - chrisseaton 4y ago
    Right, but I think we know how to optimise all these things. It's all solved problems.
    - mixmastamyk 4y ago
      A few things are impossible without changing/subsetting the language. What I was trying to get at.
      - chrisseaton 4y ago
        What things are you thinking of? (Not trying to interrogate you or prove you wrong, but I've got an interest in optimising very difficult meta-programming patterns.)
        mixmastamyk 4y ago
        Nearly everything (or is it everything?) in memory can be modified at runtime. There are no real constants for example. The whole stack top to bottom can be monkeypatched on a whim. This means nothing is guaranteed and so every instruction must do multiple checks to make sure data structures are what is expected at the current moment. This is true of JS as well, but to a lesser extent.
        chrisseaton 4y ago
        > so every instruction must do multiple checks Aren't all the things you mentioned already fixed by deoptimisation? You assume constants cannot be modified, and then get the code that wants to modify constants to do the work of stopping everyone who is assuming a constant value, and modify them that they need to pick up the new value? > To deoptimize means to jump from more optimised code to less optimized code. In practice that usually means to jump from just-in-time compiled machine code back into an interpreter. If we can do this at any point, and if we can perfectly restore the entire state of the interpreter, then we can start to throw away those checks in our optimized code, and instead we can deoptimize when the check would fail. https://chrisseaton.com/truffleruby/deoptimizing/ https://chrisseaton.com/truffleruby/deoptimizing/ I work on a compiler for Ruby, and mutable constants and the ability to monkey patch etc adds literally zero extra checks to optimised code.
BiteCode_dev 4y ago
That's what Microsoft is paying Guido for, for the next versions of python.
- chrisseaton 4y ago
  I think that's not really the plan - they're talking about just basic template compilation, nothing like V8 https://github.com/markshannon/faster-cpython/blob/master/plan.md https://github.com/markshannon/faster-cpython/blob/master/pl....

chrisseaton 4y ago

That's not Node - that's V8. And it's possible to do the same thing for Python - there's nothing magic about JavaScript compared to Python - it's just a lot of engineering work to do it, which is beyond what this project's scope is. PyPy does it, but not inside standard Python.

peterkelly 4y ago
I'm well aware of V8 and pypy. I also really like Python as a language, especially with mypy. It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). There is a really important (if not "magic") difference between JavaScript and Python. JS has always (well, since IE added support) been a language with multiple widely-used implementations in the wild, which has prevented the emergence of a third-party package ecosystem which is heavily tied to one particular implementation. Python on the other hand is for a large proportion of the userbase considered CPython, with alternate implementations being second class citizens, despite some truly impressive efforts on the latter. The fact that packages written in JS are not tied to (or at least work best with) a single implementation is also what made it possible for developers of JS engines to experiment with different implementation approaches, including JIT. While I'm not intimately familiar with writing native extension modules for Node (having dabbled only a little), my understanding is the API surface is much narrower than Python, allowing for changes in the engine that avoid breaking APIs. But there is less need for native modules in JS, because of the presence of JIT in all major engines.
- zzzeek 4y ago
  > It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). this is misleading, if one sees the phrase "interpreter" as that code is represented as syntax-derived trees or other datastructures which are then traversed at runtime to produce results - someone correct me if I'm wrong but this would apply to well known interpreted languages like Perl 5. cPython is a bytecode interpreter, not conceptually unlike the Java VM before JITs were added. It just happens to compile scripts to bytecode on the fly.
  - chrisseaton 4y ago
    Bytecode is just another data structure that you traverse at runtime to produce results. It's a postfix transformation of the AST. It's still an interpreter.
    - an1sotropy 4y ago
      Well, ok, but then isn't a CPU is also just an interpreter, traversing the object code text of compiled code?
      - chrisseaton 4y ago
        We don't normally call hardware or firmware implementations an 'interpreter'. Almost all execution techniques include some combination of compilation and interpretation. Even some ASTs include aspects of transformation to construct them from the source code, which we could call a compiler. Native compilers sometimes have to interpret metadata to do things like roll forward for deoptimisation. But most people in the field would describe CPython firmly as an 'interpreter'.
        zzzeek 4y ago
        I call it "bytecode interpreted" to distinguish it from traditional parse-tree interpretation such as Perl 5 and others
mixmastamyk 4y ago
Python is a bit more dynamic than JS, which makes it uniquely hard to optimize. There is more improvement to be done however and is being done.
- chrisseaton 4y ago
  Right, but I think we know how to optimise all these things. It's all solved problems.
  - mixmastamyk 4y ago
    A few things are impossible without changing/subsetting the language. What I was trying to get at.
    - chrisseaton 4y ago
      What things are you thinking of? (Not trying to interrogate you or prove you wrong, but I've got an interest in optimising very difficult meta-programming patterns.)
      - mixmastamyk 4y ago
        Nearly everything (or is it everything?) in memory can be modified at runtime. There are no real constants for example. The whole stack top to bottom can be monkeypatched on a whim. This means nothing is guaranteed and so every instruction must do multiple checks to make sure data structures are what is expected at the current moment. This is true of JS as well, but to a lesser extent.
        chrisseaton 4y ago
        > so every instruction must do multiple checks Aren't all the things you mentioned already fixed by deoptimisation? You assume constants cannot be modified, and then get the code that wants to modify constants to do the work of stopping everyone who is assuming a constant value, and modify them that they need to pick up the new value? > To deoptimize means to jump from more optimised code to less optimized code. In practice that usually means to jump from just-in-time compiled machine code back into an interpreter. If we can do this at any point, and if we can perfectly restore the entire state of the interpreter, then we can start to throw away those checks in our optimized code, and instead we can deoptimize when the check would fail. https://chrisseaton.com/truffleruby/deoptimizing/ https://chrisseaton.com/truffleruby/deoptimizing/ I work on a compiler for Ruby, and mutable constants and the ability to monkey patch etc adds literally zero extra checks to optimised code.

BiteCode_dev 4y ago

That's what Microsoft is paying Guido for, for the next versions of python.

chrisseaton 4y ago
I think that's not really the plan - they're talking about just basic template compilation, nothing like V8 https://github.com/markshannon/faster-cpython/blob/master/plan.md https://github.com/markshannon/faster-cpython/blob/master/pl....