3 ms·

Pypy actually works really well. It could probably get even farther if people knew about it more. Test your packages on Pypy, people.

by remram 3y ago

nextaccountic 3y ago
The only trouble is C packages, which are really really common, right? So you have a performance hit or something (or so I heard) I guess that now the GIL is going away, pypy will become better at handling packages with native code like numpy
- Twirrim 3y ago
  It's fine with C packages these days, it's increasingly rare to find libraries that it won't work with. That said, it has happened often enough I'm cautious about where I use it. It would suck to be dependent on pypy's excellent performance, and then find I can't do something due to library incompatibility.
- eyegor 3y ago
  In my experience, pypy works with basically everything these days. I remember having some struggles with a weird fortran based extension module a few years ago, but it might work now too. Most c extension modules should work in pypy, there's just a performance hit depending on how they're built (cffi is the most compatible). https://doc.pypy.org/en/latest/faq.html#do-c-extension-modules-work-with-pypy https://doc.pypy.org/en/latest/faq.html#do-c-extension-modul...
  - nextaccountic 3y ago
    The point of using C extensions is to have better performance. Python is already slow in general; code that use such extensions typically depend on this performance to not be unbearable (such as data science) People wanting to use Pypy usually do so because they want better performance. Having a performance hit while using pypy is disconcerting. I was speculating that in the future, C extensions in pypy would be faster, but I now see that the GIL is actually unrelated to this performance hit. Anyway it's really a pity.
    - im3w1l 3y ago
      I get what you are saying, but normally this wouldn't matter too much right? You will have a small number of calls into the C-extension that together do a lot of work. So as a percentage the ffi-overhead is small.
    - remram 3y ago
      C extensions are fast if you use cffi. It's when it has to emulate CPython to run extensions written against CPython, that it is slow. Please do not phrase that as a failure of Pypy. That is so weird.
- stuaxo 3y ago
  This is way better than before when no C packages worked. Now, a lot of C packages work - and where they don't it's worth raising bugs: with PyPy, but also in the downstream program - occasionally they can use something else if it looks like the fix will take a while.

Pypy actually works really well. It could probably get even farther if people knew about it more. Test your packages on Pypy, people.

by remram 3y ago

Pypy actually works really well. It could probably get even farther if people knew about it more. Test your packages on Pypy, people.

nextaccountic 3y ago

The only trouble is C packages, which are really really common, right? So you have a performance hit or something (or so I heard) I guess that now the GIL is going away, pypy will become better at handling packages with native code like numpy

Twirrim 3y ago
It's fine with C packages these days, it's increasingly rare to find libraries that it won't work with. That said, it has happened often enough I'm cautious about where I use it. It would suck to be dependent on pypy's excellent performance, and then find I can't do something due to library incompatibility.
eyegor 3y ago
In my experience, pypy works with basically everything these days. I remember having some struggles with a weird fortran based extension module a few years ago, but it might work now too. Most c extension modules should work in pypy, there's just a performance hit depending on how they're built (cffi is the most compatible). https://doc.pypy.org/en/latest/faq.html#do-c-extension-modules-work-with-pypy https://doc.pypy.org/en/latest/faq.html#do-c-extension-modul...
- nextaccountic 3y ago
  The point of using C extensions is to have better performance. Python is already slow in general; code that use such extensions typically depend on this performance to not be unbearable (such as data science) People wanting to use Pypy usually do so because they want better performance. Having a performance hit while using pypy is disconcerting. I was speculating that in the future, C extensions in pypy would be faster, but I now see that the GIL is actually unrelated to this performance hit. Anyway it's really a pity.
  - im3w1l 3y ago
    I get what you are saying, but normally this wouldn't matter too much right? You will have a small number of calls into the C-extension that together do a lot of work. So as a percentage the ffi-overhead is small.
  - remram 3y ago
    C extensions are fast if you use cffi. It's when it has to emulate CPython to run extensions written against CPython, that it is slow. Please do not phrase that as a failure of Pypy. That is so weird.
stuaxo 3y ago
This is way better than before when no C packages worked. Now, a lot of C packages work - and where they don't it's worth raising bugs: with PyPy, but also in the downstream program - occasionally they can use something else if it looks like the fix will take a while.