6 ms·

They're working on JIT, which could really improve on PyPy (not that PyPy isn't great). It also supports WASM as a first class platform (as much as you can with

by jjice 5y ago

They're working on JIT, which could really improve on PyPy (not that PyPy isn't great). It also supports WASM as a first class platform (as much as you can without standard library modules that interact with the OS). I also just like seeing another non-CPython implementation. Not game changing for the Python world, but I think it's pretty neat.

chrisseaton 5y ago
> They're working on JIT, which could really improve on PyPy Have they got a big new compiler idea?
- __s 5y ago
  https://github.com/RustPython/RustPython/tree/main/jit https://github.com/RustPython/RustPython/tree/main/jit Pretty sparse. Uses cranelift tho, which is what Firefox is using for wasm For comparison, here's a complete JIT-for-befunge using cranelift: https://github.com/serprex/Befunge/blob/master/barfs/src/jit.rs https://github.com/serprex/Befunge/blob/master/barfs/src/jit... Rust is seeing ~5x improvement in compile time using cranelift for debug builds instead of llvm. Cranelift is much better suited as a jit library than llvm is. Bit of a pain postgres went the llvm route
  - orra 5y ago
    > Cranelift is much better suited as a jit library than llvm is. Unladen Swallow is seared in my mind. It was a failed project, back in 2009, to improve the speed of CPython by using LLVM as a JIT.
    - aardvark179 5y ago
      Was it really LLVM that was the problem, or the fact that there’s a lot more to making a dynamic language fast than compiling individual methods?
      - chrisseaton 5y ago
        Exactly. LLVM and Cranelift are essentially code generation backends when you’re applying them for dynamic languages. You need an entire actual custom compiler in front of them to get good code out of them.
      - orra 5y ago
        Sure, making a dynamic language fast is not easy. However, back then people thought LLVM was a magic wand. It wasn't. There were several problems. First, the Unladen Swallow team (IIRC) spent a lot of time fixing bugs in LLVM. Second, LLVM isn't fast at compiling code, at least not for a JIT. This is legitimately surprising, because the official LLVM Tutorial implements a JIT. Third, LLVM used to stand for Low Level Virtual Machine. I don't know when it stopped standing for that; clearly it hasn't for a long time. But with “Virtual Machine” in the title, you can see why people might have thought it would be suitable for implementing a dynamic language. cf. GraalVM these days.
  - skrtskrt 5y ago
    Sorry my limited understanding here, does having a JIT making having a REPL easier/more possible? I have only developed in Python professionally, and when I play around in Go and Rust, I really miss the ability to sketch things out in an IPython session.
    - __s 5y ago
      JIT can be considered an optimization. If you F12 in your browser you have a javascript REPL, no need to know about JIT or not CPython doesn't have a JIT, it has an interpreter. So it spends a lot of time in this loop: https://github.com/python/cpython/blob/main/Python/ceval.c https://github.com/python/cpython/blob/main/Python/ceval.c But you still have a repl with pypy. The downsides of JIT is that compiling bytecode to assembly can take up time (hurting startup performance, but that can be mitigated by not applying jit aggressively) & some programs have very dynamic behavior which the JIT has to eventually give up on (& go back to interpreting) or run off some pathological performance cliff where it takes up a bunch of memory & runs 10x slower than interpreter Ruby 3 introduced a jit to their reference implementation
    - oldsecondhand 5y ago
      JIT will have no effect on "user" experience, it's all about performance. (Compiles the parts that run often.)
nerdponx 5y ago
Interesting that we now have four performance-focused alternative implementations of Python: PyPy, GraalPython, Pyston, and now RustPython. There are also Jython and IronPython, although I don't know how successful/popular or actively-maintained those implementations are. Someone recently pointed out on IRC that Python is transitioning away from a language with "one implementation, and the implementation is the spec" to "one preferred implementation with an informal spec, but many alternative implementations". Now that PyPy v7.3.7 seems to support 3.8 without any issues that I've encountered, I'd strongly consider evaluating it for use in production code. It might be interesting to run some async webserver + data processing benchmarks or something across the various implementations. Maybe a good benchmark would be measuring total throughput on something like "process/sanitize some user-provided text file, then serve a prediction from a PyTorch model".
- tekknolagi 5y ago
  There's also Skybison and Cinder, but I'm biased since I worked on both.
  - nerdponx 5y ago
    I should have remembered Skybison/Cinder, it was posted on here not long ago. Heck, I probably should have mentioned Stackless too, which apparently is still being actively developed.
- agravier 5y ago
  Numerical computation libraries: numpy, scipy, ML libraries like sklearn, pytorch, and bindings for tensorflow, xgboost and many more must all work without any hiccup before data science and AI teams will consider switching away from CPython.
  - KeplerBoy 5y ago
    Those teams still wouldn't switch because they wouldn't gain any performance from switching. After all CPython is just calling highly optimized, already compiled C, Fortran or Accelerator specific (CUDA, ROCm, TPU) code as far as they are concerned.

by jjice 5y ago

chrisseaton 5y ago

> They're working on JIT, which could really improve on PyPy Have they got a big new compiler idea?

__s 5y ago
https://github.com/RustPython/RustPython/tree/main/jit https://github.com/RustPython/RustPython/tree/main/jit Pretty sparse. Uses cranelift tho, which is what Firefox is using for wasm For comparison, here's a complete JIT-for-befunge using cranelift: https://github.com/serprex/Befunge/blob/master/barfs/src/jit.rs https://github.com/serprex/Befunge/blob/master/barfs/src/jit... Rust is seeing ~5x improvement in compile time using cranelift for debug builds instead of llvm. Cranelift is much better suited as a jit library than llvm is. Bit of a pain postgres went the llvm route
- orra 5y ago
  > Cranelift is much better suited as a jit library than llvm is. Unladen Swallow is seared in my mind. It was a failed project, back in 2009, to improve the speed of CPython by using LLVM as a JIT.
  - aardvark179 5y ago
    Was it really LLVM that was the problem, or the fact that there’s a lot more to making a dynamic language fast than compiling individual methods?
    - chrisseaton 5y ago
      Exactly. LLVM and Cranelift are essentially code generation backends when you’re applying them for dynamic languages. You need an entire actual custom compiler in front of them to get good code out of them.
    - orra 5y ago
      Sure, making a dynamic language fast is not easy. However, back then people thought LLVM was a magic wand. It wasn't. There were several problems. First, the Unladen Swallow team (IIRC) spent a lot of time fixing bugs in LLVM. Second, LLVM isn't fast at compiling code, at least not for a JIT. This is legitimately surprising, because the official LLVM Tutorial implements a JIT. Third, LLVM used to stand for Low Level Virtual Machine. I don't know when it stopped standing for that; clearly it hasn't for a long time. But with “Virtual Machine” in the title, you can see why people might have thought it would be suitable for implementing a dynamic language. cf. GraalVM these days.
- skrtskrt 5y ago
  Sorry my limited understanding here, does having a JIT making having a REPL easier/more possible? I have only developed in Python professionally, and when I play around in Go and Rust, I really miss the ability to sketch things out in an IPython session.
  - __s 5y ago
    JIT can be considered an optimization. If you F12 in your browser you have a javascript REPL, no need to know about JIT or not CPython doesn't have a JIT, it has an interpreter. So it spends a lot of time in this loop: https://github.com/python/cpython/blob/main/Python/ceval.c https://github.com/python/cpython/blob/main/Python/ceval.c But you still have a repl with pypy. The downsides of JIT is that compiling bytecode to assembly can take up time (hurting startup performance, but that can be mitigated by not applying jit aggressively) & some programs have very dynamic behavior which the JIT has to eventually give up on (& go back to interpreting) or run off some pathological performance cliff where it takes up a bunch of memory & runs 10x slower than interpreter Ruby 3 introduced a jit to their reference implementation
  - oldsecondhand 5y ago
    JIT will have no effect on "user" experience, it's all about performance. (Compiles the parts that run often.)

nerdponx 5y ago

Interesting that we now have four performance-focused alternative implementations of Python: PyPy, GraalPython, Pyston, and now RustPython. There are also Jython and IronPython, although I don't know how successful/popular or actively-maintained those implementations are. Someone recently pointed out on IRC that Python is transitioning away from a language with "one implementation, and the implementation is the spec" to "one preferred implementation with an informal spec, but many alternative implementations". Now that PyPy v7.3.7 seems to support 3.8 without any issues that I've encountered, I'd strongly consider evaluating it for use in production code. It might be interesting to run some async webserver + data processing benchmarks or something across the various implementations. Maybe a good benchmark would be measuring total throughput on something like "process/sanitize some user-provided text file, then serve a prediction from a PyTorch model".

tekknolagi 5y ago
There's also Skybison and Cinder, but I'm biased since I worked on both.
- nerdponx 5y ago
  I should have remembered Skybison/Cinder, it was posted on here not long ago. Heck, I probably should have mentioned Stackless too, which apparently is still being actively developed.
agravier 5y ago
Numerical computation libraries: numpy, scipy, ML libraries like sklearn, pytorch, and bindings for tensorflow, xgboost and many more must all work without any hiccup before data science and AI teams will consider switching away from CPython.
- KeplerBoy 5y ago
  Those teams still wouldn't switch because they wouldn't gain any performance from switching. After all CPython is just calling highly optimized, already compiled C, Fortran or Accelerator specific (CUDA, ROCm, TPU) code as far as they are concerned.