4 ms·

I migrated some internal tools from Lua to Python because of the incredible ecosystem. However, I miss everyday the speed of Lua thanks to LuaJIT. But I already

by bratao 8y ago

I migrated some internal tools from Lua to Python because of the incredible ecosystem. However, I miss everyday the speed of Lua thanks to LuaJIT. But I already ported almost all critical code to Cython. It is on my todo list to undo this port and test with Pypy. I feel that PyPy need to receive much more love and attention than it actually gets. I already donated, and put all my hopes on PyPy. The Windows is also very renegaded, where the multiprocessing module is unusable. I hope to get some time soon to help this incredible project and finish lib_pypy/_winapi.py.

dec0dedab0de 8y ago
It is on my todo list to undo this port That has always been my reason for not giving a Cython a real chance. I'm afraid I would go through the trouble porting everything, then have a use case where I need to just run pure python. I've considered having a compat layer where you import dummy versions of all the classes and decorators if cython isn't present. Has anyone ever tried that?
- uryga 8y ago
  I don't know about your question, but Cython recently added [1] the option to use native Python type annotations (Python 3.6, PEP 484) instead of its previous C-like dialect. That could lead to a situation where a sensibly type-annotated Cython file can still be a valid Python file – that would help with portability. [1] https://github.com/cython/cython/issues/1672#issuecomment-330821277 https://github.com/cython/cython/issues/1672#issuecomment-33...
  - acemarke 8y ago
    Cython also supports writing type annotations in a separate .pxd file. It's a bit awkward because you're effectively duplicating all function + variable declarations, but it _is_ a valid way to keep the original Python source intact. (On a side note, using this feature led to a particularly memorable debugging session that set a personal record in terms of time spent vs amount of code changed to fix the issue: https://news.ycombinator.com/item?id=11115110 https://news.ycombinator.com/item?id=11115110 ).
- deleted 8y ago
  [deleted]
- bratao 8y ago
  Yeah, using Cython feel dirty because of that. I miss the opportunity to step into during debug and have to use workarounds to do profiling.
- maxerickson 8y ago
  There's a built in pattern that is at least similar to what you describe: https://cython.readthedocs.io/en/latest/src/tutorial/pure.html#augmenting-pxd https://cython.readthedocs.io/en/latest/src/tutorial/pure.ht... In the standard library, they maintain both Python and C versions of some modules: https://www.python.org/dev/peps/pep-0399/ https://www.python.org/dev/peps/pep-0399/
bear24rw 8y ago
What type of performance issues do you run into with cpython?
- stuaxo 8y ago
  Not the OP, but personally I'd like to be able to use python for all the things that people say "just don't use python for". Including things like modifying every pixel of an image, and other things that need to be fast-ish.
  - pletnes 8y ago
    Did you try numba yet?
pjmlp 8y ago
I share the same perception of lack of love from the community regarding JIT compilers, not only PyPy. I see Julia and JavaScript eventually wining over those that can't be bothered to deal with C for the extra performance step.
- majewsky 8y ago
  I see Go (also) occupying that niche. Maybe that's because of my (cloud technology) bubble, but 90%+ of the interesting new projects are in Go (not just web services or container runtimes, also CLI tools).
  - pjmlp 8y ago
    Yes, there were a couple of talks at Go UK 2018 about that.
- kristofferc 8y ago
  The Julia compiler is a little bit different in the sense that it actually compiles ahead of time (it is not a tracing JIT). This takes place just before a method (with known runtime types for the arguments) is executed for the first time. So performance is predictable but on the other hand there is a risk of over specializations.
  - pjmlp 8y ago
    I know, but that is not the point. The point is the lack of adoption of JIT runtimes across the Python community at large.

by bratao 8y ago

dec0dedab0de 8y ago

It is on my todo list to undo this port That has always been my reason for not giving a Cython a real chance. I'm afraid I would go through the trouble porting everything, then have a use case where I need to just run pure python. I've considered having a compat layer where you import dummy versions of all the classes and decorators if cython isn't present. Has anyone ever tried that?

uryga 8y ago
I don't know about your question, but Cython recently added [1] the option to use native Python type annotations (Python 3.6, PEP 484) instead of its previous C-like dialect. That could lead to a situation where a sensibly type-annotated Cython file can still be a valid Python file – that would help with portability. [1] https://github.com/cython/cython/issues/1672#issuecomment-330821277 https://github.com/cython/cython/issues/1672#issuecomment-33...
- acemarke 8y ago
  Cython also supports writing type annotations in a separate .pxd file. It's a bit awkward because you're effectively duplicating all function + variable declarations, but it _is_ a valid way to keep the original Python source intact. (On a side note, using this feature led to a particularly memorable debugging session that set a personal record in terms of time spent vs amount of code changed to fix the issue: https://news.ycombinator.com/item?id=11115110 https://news.ycombinator.com/item?id=11115110 ).
deleted 8y ago
[deleted]
bratao 8y ago
Yeah, using Cython feel dirty because of that. I miss the opportunity to step into during debug and have to use workarounds to do profiling.
maxerickson 8y ago
There's a built in pattern that is at least similar to what you describe: https://cython.readthedocs.io/en/latest/src/tutorial/pure.html#augmenting-pxd https://cython.readthedocs.io/en/latest/src/tutorial/pure.ht... In the standard library, they maintain both Python and C versions of some modules: https://www.python.org/dev/peps/pep-0399/ https://www.python.org/dev/peps/pep-0399/

bear24rw 8y ago

What type of performance issues do you run into with cpython?

stuaxo 8y ago
Not the OP, but personally I'd like to be able to use python for all the things that people say "just don't use python for". Including things like modifying every pixel of an image, and other things that need to be fast-ish.
- pletnes 8y ago
  Did you try numba yet?

pjmlp 8y ago

I share the same perception of lack of love from the community regarding JIT compilers, not only PyPy. I see Julia and JavaScript eventually wining over those that can't be bothered to deal with C for the extra performance step.

majewsky 8y ago
I see Go (also) occupying that niche. Maybe that's because of my (cloud technology) bubble, but 90%+ of the interesting new projects are in Go (not just web services or container runtimes, also CLI tools).
- pjmlp 8y ago
  Yes, there were a couple of talks at Go UK 2018 about that.
kristofferc 8y ago
The Julia compiler is a little bit different in the sense that it actually compiles ahead of time (it is not a tracing JIT). This takes place just before a method (with known runtime types for the arguments) is executed for the first time. So performance is predictable but on the other hand there is a risk of over specializations.
- pjmlp 8y ago
  I know, but that is not the point. The point is the lack of adoption of JIT runtimes across the Python community at large.