gevent would have to have support for running using PyPys stackless mode.
Actually pypy has it's own version of the greenlet module in their
default build afaik (built on slightly different primitives). IIRC
Armin finished that not long after europython last year. There'd
still be an amount of porting to be done though, since gevent includes
more C code then just greenlet, you might get started easier using
eventlet which has a few hubs to choose from, some of which only rely
on the stdlib. On plain CPython that can be expected to be a little
slower but never tried PyPy myself.
Regards,
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
Or the cython modules are re-written in python using ctypes for use in PyPy.
at the moment PyPy is 5x faster than the CPython. That makes me "crave" for a combination pypy+gevent
It seems there is a Python C level API compatibility layer for pypy.
Since Cython produces traditional C extension code it would make it
possible to run the gevent C code produced by cython on pypy.
Or am I missing something ?
"cpyext is slow, and always will be slow. It has to emulate far too
many details of the CPython object model that don't exist on PyPy
(e.g., reference counting). Since people are using NumPy primarily for
speed this would mean that even if we could have a working NumPy, no
one would want to use it. Also, as soon as the execution crosses the
cpyext boundary, it becomes invisible to the JIT, which means the JIT
has to assume the worst and deoptimize stuff away."
[1] http://morepypy.blogspot.fr/2011/05/numpy-follow-up.html
Armin Rigo is working on STM,
gevent attempts to work around concurrency problems in Python by reducing the dependence on native threading. STM will likely reduce single threaded performance, and by extension gevent.
There's also a good chance that C extensions won't work well, and that PyPy's greenlet interface will be a low priority because of how it relates to the goals of introducing STM.
And STM is needed for gevent support?
Indeed that sounds quite handy.
I've done this. It's better in that the implementation is only several 100 lines. It's worse because the only reason it's useful is to work around pathological contention in the GIL introduced by very high levels of concurrency. Gevent reduces the concurrency overhead since most of it's done in C.
Sorry, I explained poorly. What I'm saying is that scheduled coroutines alleviate some negative aspects of the GIL. But doing the scheduling in pure Python the overhead is very high anyway, you may as well use native threading for the improved portability and compatibility with existing code. Your mileage may vary of course.
Here's my Python 3, pure Python gevent clone: https://bitbucket.org/anacrolix/gthread The README contains an overview of my experiences with the model.
I also wrote an asynchronous framework using the new PEP 380 for Python 3.3: https://bitbucket.org/anacrolix/green380
Lastly, I wrote a pure Python script that monkey patches the stdlib and allows you to run unmodified Python code emulating threads as greenlets, which is my personal favorite: https://bitbucket.org/anacrolix/green380. python3 goco.py <usual python parameters>.