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).

5 comments:

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

    ReplyDelete
  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! :)

    ReplyDelete
  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).

    ReplyDelete
  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?

    ReplyDelete
  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)

    ReplyDelete