3 ms·

There's just less need for cython these days. If you're writing a compiled extension, there's pybind11 or, better yet, pyo3, where you can also get access to i

There's just less need for cython these days. If you're writing a compiled extension, there's pybind11 or, better yet, pyo3, where you can also get access to internals of polars and other libraries. In numeric Python, and especially with computers becoming progressively faster, it's rarely the case than the layer of pure Python is where the cpu time is spent. And in the rare case when you need to do something funky for-loop-style with your numpy data, there's jit-compiled numba...

alfalfasprout 3y ago
Nowadays the python bottleneck is typically moreso with the GIL. Assuming you're already using native extensions for heavy lifting, the GIL is what prevents workloads from being efficiently multithreaded if they need any sort of communication without really hacky workarounds. I have a feeling this is why ultimately why PEP 703 is being accepted despite the setbacks to the Faster CPython effort-- while faster CPython is a great goal, it is rarely the bottleneck nowadays.
- Qem 3y ago
  > I have a feeling this is why ultimately why PEP 703 is being accepted despite the setbacks to the Faster CPython effort-- while faster CPython is a great goal, it is rarely the bottleneck nowadays. How much of a setback that should be? The initial target was a 5x improvement over 4 releases, IIRC. What are current estimates like?
  - alfalfasprout 3y ago
    There will be a 10-15% hit for single threaded CPython code by adopting nogil. So FasterCPython will have to first improve performance at least that much to get to where we are today. That's a cost that's probably worth it.