9 ms·

I did some work on a Python JIT in the path. The two biggest challenges were: - Python is much, much, more dynamic than Javascript. You can override just about

by rudi-c 7y ago

I did some work on a Python JIT in the path. The two biggest challenges were: - Python is much, much, more dynamic than Javascript. You can override just about anything in Python, including the meaning of accessing a property. You have overloaded operators (with pretty complex resolution rules), metaclasses, and more. And they're all used extensively. There's some Javascript equivalents to those things, but either there are fewer deoptimization cases or are features that aren't commonly used in practice (e.g. Proxy objects). - Python has a ton of important libraries implemented as C extensions. These libraries tend to depend on undefined behavior of the CPython interpreter (e.g. destruction order which is more deterministic with ref counting) or do things that happen to work but are clearly not supposed to be done (e.g. defining a full Python object as a static variable). I guess also economic incentives, there hasn't been an incentive for anybody to staff a 50 person project to build a Python JIT given that it's cheaper to rewrite some or all of the application in C/C++/Rust/Go whereas that's not an option in Javascriptland.

oweiler 7y ago
> I guess also economic incentives, there hasn't been an incentive for anybody to staff a 50 person project to build a Python JIT given that it's cheaper to rewrite some or all of the application in C/C++/Rust/Go whereas that's not an option in Javascriptland. Ask Dropbox https://github.com/dropbox/pyston https://github.com/dropbox/pyston
- jsnell 7y ago
  Right, let's ask Dropbox: https://blog.pyston.org/2017/01/31/pyston-0-6-1-released-and-future-plans/ https://blog.pyston.org/2017/01/31/pyston-0-6-1-released-and... (And after that blog post, there are no commits in the github repo you linked to).
  - aswanson 7y ago
    Yeah, I was excited when they announced this effort. Sad they 86ed it.
ufo 7y ago
I completely agree with you and I'd argue that #2 and #3 are the two biggest reasons. It is easy to forget the colossal amount of engineering resources that browser vendors have spent creating and rewriting their Javascript engines. And due to the nature of how their JITs work, all that work is tied down to the specific Javascript environment they were written for. (For example, you can't really reuse the v8 codebase to create a Python JIT) And in Python's case a lot of the appeal of the language rests on the extensive library ecosystem, which has a significant number of extensions written in C. Generally speaking JIT compilers aren't very good at optimizing code that spends a lot of time inside or interacting with C extensions, even if we ignore the significant issues you mentioned regarding undefined behavior.
- Ajedi32 7y ago
  > For example, you can't really reuse the v8 codebase to create a Python JIT Actually, come to think of it... V8 also runs WASM right? Right now I think WASM is missing a few features (like garbage collection) which Python would need to be efficiently compiled to WASM, but once those are solved...
  - bakery2k 7y ago
    I don't think its possible to efficiently compile a dynamically-typed language like Python to statically-typed WASM.
    - buu700 7y ago
      Thought experiment: what about transpiling Python to JS? https://github.com/QQuick/Transcrypt https://github.com/QQuick/Transcrypt looks like a nice implementation, but their readme just talks about deployment to browsers — I'm curious about outside of the browser whether Transcrypt + Node might be more efficient than CPython. (Not even just CPython, but really any dynamic language implementation.) And then of course wasm could still be used for C extensions.
    - mixmastamyk 7y ago
      Not random code, but specifically written with type checking should be doable. There was an asm,js subset for example.
bakery2k 7y ago
> And they're all used extensively. That's the key. MicroPython is significantly less dynamic than full Python, and would be much easier (but still not easy) to write a fast JIT for. Unfortunately such a JIT wouldn't be very useful - MicroPython won't run much code that hasn't been written specifically for it. Without the dynamic features, MicroPython is essentially a different language from regular Python.
munificent 7y ago
I think you have the first three points — dynamism, C extensions, and economics — right on the money. The fourth point I would add is that Python has a huge standard library. That's a very large surface area, all of which ends up needing optimization effort to get good performance across a wide variety of programs.
viklove 7y ago
> You can override just about anything in Python, including the meaning of accessing a property. Can't you do this in JS as well?
- tynorf 7y ago
  As far as I know, JS does not have the equivalent of Python's descriptor protocol[0]. This is notably different from setter/getter methods. [0]: https://docs.python.org/3/howto/descriptor.html https://docs.python.org/3/howto/descriptor.html
MaxBarraclough 7y ago
> You can override just about anything in Python, including the meaning of accessing a property JavaScript has getters that do the same [0]. You can even redefine 'undefined' depending on version and mode [1]. Is operator overloading really that much 'worse' in Python? [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://stackoverflow.com/a/8783528/ https://stackoverflow.com/a/8783528/

by rudi-c 7y ago

oweiler 7y ago

> I guess also economic incentives, there hasn't been an incentive for anybody to staff a 50 person project to build a Python JIT given that it's cheaper to rewrite some or all of the application in C/C++/Rust/Go whereas that's not an option in Javascriptland. Ask Dropbox https://github.com/dropbox/pyston https://github.com/dropbox/pyston

jsnell 7y ago
Right, let's ask Dropbox: https://blog.pyston.org/2017/01/31/pyston-0-6-1-released-and-future-plans/ https://blog.pyston.org/2017/01/31/pyston-0-6-1-released-and... (And after that blog post, there are no commits in the github repo you linked to).
- aswanson 7y ago
  Yeah, I was excited when they announced this effort. Sad they 86ed it.

ufo 7y ago

I completely agree with you and I'd argue that #2 and #3 are the two biggest reasons. It is easy to forget the colossal amount of engineering resources that browser vendors have spent creating and rewriting their Javascript engines. And due to the nature of how their JITs work, all that work is tied down to the specific Javascript environment they were written for. (For example, you can't really reuse the v8 codebase to create a Python JIT) And in Python's case a lot of the appeal of the language rests on the extensive library ecosystem, which has a significant number of extensions written in C. Generally speaking JIT compilers aren't very good at optimizing code that spends a lot of time inside or interacting with C extensions, even if we ignore the significant issues you mentioned regarding undefined behavior.

Ajedi32 7y ago
> For example, you can't really reuse the v8 codebase to create a Python JIT Actually, come to think of it... V8 also runs WASM right? Right now I think WASM is missing a few features (like garbage collection) which Python would need to be efficiently compiled to WASM, but once those are solved...
- bakery2k 7y ago
  I don't think its possible to efficiently compile a dynamically-typed language like Python to statically-typed WASM.
  - buu700 7y ago
    Thought experiment: what about transpiling Python to JS? https://github.com/QQuick/Transcrypt https://github.com/QQuick/Transcrypt looks like a nice implementation, but their readme just talks about deployment to browsers — I'm curious about outside of the browser whether Transcrypt + Node might be more efficient than CPython. (Not even just CPython, but really any dynamic language implementation.) And then of course wasm could still be used for C extensions.
  - mixmastamyk 7y ago
    Not random code, but specifically written with type checking should be doable. There was an asm,js subset for example.

bakery2k 7y ago

> And they're all used extensively. That's the key. MicroPython is significantly less dynamic than full Python, and would be much easier (but still not easy) to write a fast JIT for. Unfortunately such a JIT wouldn't be very useful - MicroPython won't run much code that hasn't been written specifically for it. Without the dynamic features, MicroPython is essentially a different language from regular Python.

munificent 7y ago

I think you have the first three points — dynamism, C extensions, and economics — right on the money. The fourth point I would add is that Python has a huge standard library. That's a very large surface area, all of which ends up needing optimization effort to get good performance across a wide variety of programs.

viklove 7y ago

> You can override just about anything in Python, including the meaning of accessing a property. Can't you do this in JS as well?

tynorf 7y ago
As far as I know, JS does not have the equivalent of Python's descriptor protocol[0]. This is notably different from setter/getter methods. [0]: https://docs.python.org/3/howto/descriptor.html https://docs.python.org/3/howto/descriptor.html

MaxBarraclough 7y ago

> You can override just about anything in Python, including the meaning of accessing a property JavaScript has getters that do the same [0]. You can even redefine 'undefined' depending on version and mode [1]. Is operator overloading really that much 'worse' in Python? [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://stackoverflow.com/a/8783528/ https://stackoverflow.com/a/8783528/