3 ms·

> I never thought Ruby would have a shipping and production ready JIT before Python. This is entirely predictable - Ruby does not have a big scientific computi

by rfoo 3y ago

> I never thought Ruby would have a shipping and production ready JIT before Python. This is entirely predictable - Ruby does not have a big scientific computing community which happened to depend on every implementation detail of the hosting interpreter.

byroot 3y ago
I don't see how it's relevant given that YJIT didn't cause any compatibility issue whatsoever.
pjmlp 3y ago
Python has a culture that sees writing C libraries as "Python" code, hence why. It is quite common to see "Python" libraries that are just thin bindings layers, they could just as well be "Tcl" libraries for that matter.
- tnecniv 3y ago
  I should start doing numerical work in TCL and see how long it takes for me to get set to the mad house
  - pjmlp 3y ago
    Well, first step is to create bindings to the same libraries Python uses.
    - nerdponx 3y ago
      The problem is that Numpy is not in fact anything close to a thin wrapper around BLAS/LAPACK like people seem to think it is. First of all, it contains a ton of custom C code, which to some extent could be extracted to a separate library in theory, but isn't. Second, a lot of that custom code interacts deeply with the Python C API, which historically was very open-ended. Even getting it to work on another implementation of Python was a challenge that took a long time to reach baseline usability. You could forego Numpy and call out to a library like Eigen, but even then you have a huge amount of work ahead to achieve anything resembling feature parity.
      - pjmlp 3y ago
        Who singled out Numpy? Still, your lengthy explanation only confirms how much C and how little Python, that specific case happens to be.
dejv 3y ago
There are huge apps (such as Shopify) which will safe a lot of money by having more performant BE so they do invest heavily into it. Python workloads, with deep pocketed backers, do spend more time inside GPU or C runtime.
pvg 3y ago
There's a talk from a couple of years ago by one of the YJIT developers that discusses this in some detail and it's more interesting/complicated than that. The whole thing is worth checking out but the specific section starts here https://youtu.be/vucLAqv7qpc?t=937 https://youtu.be/vucLAqv7qpc?t=937

by rfoo 3y ago

byroot 3y ago

I don't see how it's relevant given that YJIT didn't cause any compatibility issue whatsoever.

pjmlp 3y ago

Python has a culture that sees writing C libraries as "Python" code, hence why. It is quite common to see "Python" libraries that are just thin bindings layers, they could just as well be "Tcl" libraries for that matter.

tnecniv 3y ago
I should start doing numerical work in TCL and see how long it takes for me to get set to the mad house
- pjmlp 3y ago
  Well, first step is to create bindings to the same libraries Python uses.
  - nerdponx 3y ago
    The problem is that Numpy is not in fact anything close to a thin wrapper around BLAS/LAPACK like people seem to think it is. First of all, it contains a ton of custom C code, which to some extent could be extracted to a separate library in theory, but isn't. Second, a lot of that custom code interacts deeply with the Python C API, which historically was very open-ended. Even getting it to work on another implementation of Python was a challenge that took a long time to reach baseline usability. You could forego Numpy and call out to a library like Eigen, but even then you have a huge amount of work ahead to achieve anything resembling feature parity.
    - pjmlp 3y ago
      Who singled out Numpy? Still, your lengthy explanation only confirms how much C and how little Python, that specific case happens to be.

dejv 3y ago

There are huge apps (such as Shopify) which will safe a lot of money by having more performant BE so they do invest heavily into it. Python workloads, with deep pocketed backers, do spend more time inside GPU or C runtime.

pvg 3y ago

There's a talk from a couple of years ago by one of the YJIT developers that discusses this in some detail and it's more interesting/complicated than that. The whole thing is worth checking out but the specific section starts here https://youtu.be/vucLAqv7qpc?t=937 https://youtu.be/vucLAqv7qpc?t=937