3 ms·

Having a JIT is not a magic bullet. The reason so many different JITs for Python have been developed, yet none have seen widespread adoption is that Python's se

Having a JIT is not a magic bullet. The reason so many different JITs for Python have been developed, yet none have seen widespread adoption is that Python's semantics are anathema to optimizing compilers. Julia was designed specifically to have language semantics that would make compiler optimizations as easy as possible without sacrificing usability. Bolting an efficient, all-language compiler onto Python post-hoc is essentially impossible without fundamental changes to the language.

gugagore 3y ago
I would like to understand why JavaScript semantics have allowed for a lot of performance, but Python semantics hasn't.
- eigenspace 3y ago
  I'm actually not very experienced with JavaScript, but my understanding is that it comes down to that Python's foreign function interface is tightly bound up with the implementation details of CPython. This means that unless you want to lose access to the whole Python ecosystem, your JIT compiler needs to jump through an impossible series of hoops to support existing libraries As far as I understand, in practice, JavaScript code relies less on foreign function interfaces to code that's written in other languages (because you can't reliably do that in a browser). This point makes it so that important JavaScript packages tend to be written in JavaScript, whereas important Python packages tend to be written in C or Fortran or Rust or whatever. If a JIT compiler for Javascript changes how FFI works, then that's less big of a deal. Again though, not very knowledgable about JavaScript, so if someone wants to come and correct me, or offer additional context, I'd be very appreciative.
pjmlp 3y ago
The usual argument from those that never saw Common Lisp, Smalltalk and SELF JITs, languages that are even more dynamic than Python, with constructs that can change the meaning of object instances across all application space and image, and their actual structure is dynamically constructed via metaclasses, much more powerful than what Python metaclasses can do. It is getting tired by now.
- eigenspace 3y ago
  Please don't assume that I've never used languages like Common Lisp or Smalltalk because it's not true. I'm well aware that you can optimize code in a highly dynamic language (I'm mainly a julia programmer afterall). The problem with Python isn't dynamism, it's the way the dynamism was baked into the language, and the very leaky way it affects the language semantics.
  - pjmlp 3y ago
    I did not assume, just it keeps being a common argument, when those languages go beyond Python and yet offer very capable JITs. As mentioned, imagine having something like the Smalltalk becomes:, where in a flip second, all occurrences of type A turn into B, across the whole application, including already JITed. Or stopping the application at any given moment, recode something, hit continue, and the application carries on, as if it was the original implementation to start with. Or given they were full workstation OSes, apply such dynamism to the kernel level code.
    - eigenspace 3y ago
      Let me ask you this: Do you think that the is a reason there's no widespread whole-language, high performance JIT compiler for Python despite there being so much interest in such a compiler? Do you think that people just haven't tried hard enough?
      - pjmlp 3y ago
        It requires Xerox PARC money to keep it going, and not many companies are that interested. Facebook was interested into doing the work for PHP. Shopify is interested into doing the work for Ruby. Google was interested for a moment, but then instead of spending money on Unladen Swallow, they decided to port Python code into Go instead. NVidia is interested, but only to the point it is a JIT for CUDA workflows. Now finally Microsoft and Facebook, seem to be willing to invest into Python, so lets see if this time how long they will care. Interest alone doesn't make it happen, money, people and management willing to wait, make it happen. GraalVM would never have happened, if Sun or Oracle had killed MaximeVM after almost a decade of research work.

gugagore 3y ago

I would like to understand why JavaScript semantics have allowed for a lot of performance, but Python semantics hasn't.

eigenspace 3y ago
I'm actually not very experienced with JavaScript, but my understanding is that it comes down to that Python's foreign function interface is tightly bound up with the implementation details of CPython. This means that unless you want to lose access to the whole Python ecosystem, your JIT compiler needs to jump through an impossible series of hoops to support existing libraries As far as I understand, in practice, JavaScript code relies less on foreign function interfaces to code that's written in other languages (because you can't reliably do that in a browser). This point makes it so that important JavaScript packages tend to be written in JavaScript, whereas important Python packages tend to be written in C or Fortran or Rust or whatever. If a JIT compiler for Javascript changes how FFI works, then that's less big of a deal. Again though, not very knowledgable about JavaScript, so if someone wants to come and correct me, or offer additional context, I'd be very appreciative.

pjmlp 3y ago

The usual argument from those that never saw Common Lisp, Smalltalk and SELF JITs, languages that are even more dynamic than Python, with constructs that can change the meaning of object instances across all application space and image, and their actual structure is dynamically constructed via metaclasses, much more powerful than what Python metaclasses can do. It is getting tired by now.

eigenspace 3y ago
Please don't assume that I've never used languages like Common Lisp or Smalltalk because it's not true. I'm well aware that you can optimize code in a highly dynamic language (I'm mainly a julia programmer afterall). The problem with Python isn't dynamism, it's the way the dynamism was baked into the language, and the very leaky way it affects the language semantics.
- pjmlp 3y ago
  I did not assume, just it keeps being a common argument, when those languages go beyond Python and yet offer very capable JITs. As mentioned, imagine having something like the Smalltalk becomes:, where in a flip second, all occurrences of type A turn into B, across the whole application, including already JITed. Or stopping the application at any given moment, recode something, hit continue, and the application carries on, as if it was the original implementation to start with. Or given they were full workstation OSes, apply such dynamism to the kernel level code.
  - eigenspace 3y ago
    Let me ask you this: Do you think that the is a reason there's no widespread whole-language, high performance JIT compiler for Python despite there being so much interest in such a compiler? Do you think that people just haven't tried hard enough?
    - pjmlp 3y ago
      It requires Xerox PARC money to keep it going, and not many companies are that interested. Facebook was interested into doing the work for PHP. Shopify is interested into doing the work for Ruby. Google was interested for a moment, but then instead of spending money on Unladen Swallow, they decided to port Python code into Go instead. NVidia is interested, but only to the point it is a JIT for CUDA workflows. Now finally Microsoft and Facebook, seem to be willing to invest into Python, so lets see if this time how long they will care. Interest alone doesn't make it happen, money, people and management willing to wait, make it happen. GraalVM would never have happened, if Sun or Oracle had killed MaximeVM after almost a decade of research work.