Hi Stefan. CPython extension compatibility layer is in alpha at best. I heavily doubt that anything would run out of the box. However, this is a cpython compatiblity layer anyway, it's not meant to be used as a long term solutions. First of all it's inneficient (and unclear if will ever be), but it's also unjitable. This means that to JIT, cpython extension is like a black box which should not be touched. Also, several concepts, like refcounting are completely alien to pypy and emulated.
For example for numpy, I think a rewrite is necessary to make it fast (and as experiments have shown, it's possible to make it really fast), so I would not worry about using cython for speeding things up. In theory you should not need it and the boundary layer between cython-compiled code and JITted code would make you suffer anyway. There is another usecase for using cython for providing access to C libraries. This is a bit harder question and I don't have a good answer for that, but maybe cpython compatibility layer would be good enough in this case? I can't see how Cython can produce a "native" C code instead of CPython C code without some major effort. Cheers, fijal On Thu, Aug 12, 2010 at 8:49 AM, Stefan Behnel <[email protected]> wrote: > Hi, > > there has recently been a move towards a .NET/IronPython port of Cython, > mostly driven by the need for a fast NumPy port. During the related > discussion, the question came up how much it would take to let Cython also > target other runtimes, including PyPy. > > Given that PyPy already has a CPython C-API compatibility layer, I doubt > that it would be hard to enable that. With my limited knowledge about the > internals of that layer, I guess the question thus becomes: is there > anything Cython could do to the C code it generates that would make the > Cython generated extension modules run faster/better/safer on PyPy than > they would currently? I never tried to make a Cython module actually run on > PyPy (simply because I don't use PyPy), but I have my doubts that they'd > run perfectly out of the box. While generally portable, I'm pretty sure the > C code relies on some specific internals of CPython that PyPy can't easily > (or efficiently) provide. > > Stefan > > _______________________________________________ > [email protected] > http://codespeak.net/mailman/listinfo/pypy-dev > _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
