Tuesday, July 5, 2011

Cython backend aiming PyPy Status

This has been a long time since I posted something but I still work actively on the backend, here is what happened since the last blog post :

  • I have integrated AnalyseDeclarationsTransform and AnalyseExpressionsTransform with the pipeline, this means that I can now get the type of declarations and expressions (like : this is a function call that returns an integer, this parameter is a float, this variable is a Python object)
  • It is now possible to have cdef'd variable inside functions (of basic C types, structures, pointers, arrays)
  • Manipulation of C numeric types (like mathematic operations) although this is not finished (like passing them as parameters of functions or returning them)

For this week, I plan to write tests for the features I've implemented the last weeks, and continue the manipulations of C numeric types (especially the manipulations listed above).


  1. you should write tests *before* :-)
    (nice job, btw)

  2. Do you have any benchmarks or thoughts about how fast a Cython extension can be expected to run when using PyPy and your backend vs. a a regular Cython C-language extension?

    If it's premature to answer a question like that, that's fine -- I just had to ask though! :)

  3. @Anto: I know, I should get used to this :)

    @Gary: I have no idea yet about the speed of the code generated, but considering that PyPy C extension support is very slow, running Python code on PyPy is always faster than running C code (and PyPy is not compatible with Cython's C extensions anyway).

  4. OK, thanks for your response... :) How about this follow-up question: Do you think Cython code using your approach could be faster than regular PyPy, because of the type restrictions of other reasons?

  5. Since the variables always have the same type, I guess the JIT can optimize that, but on the other end, Cython's int are turned into ctypes' c_int and not standard Python int, this could create an overhead (this could be optimized as well using escape analysis but I don't think this will be implemented before the Summer of Code deadline, I don't know if the JIT can unbox those variables)