Phil Hassey - game dev blog
Phil Hassey as Rambo
".. I've been there,
I know what it's like,
and I'll do it again if I have to."

Struggling with pyrex

In my last blog post, someone said I should check out pyrex. So I did.

pyrex-julia.png

Okay .. I must say, I found it extremely difficult to use and rather slow – 700 ms per frame (my pure C implementation is around 65 ms per frame). I had quite a bit of trouble figuring out the magic of getting anything to work, a few things seem pretty inconsistent. Thankfully I found someone (allefant – thanks) who helped me get some stuff working, but even he was rather baffled by some of the stuff we had to do to get it going.

Unfortunately, even after all our efforts, it was still slow. pyrex does so many magic things, that even with everything defined out to be C-ish, it still wraps ’em up so we don’t get the C-speed we want. I think the largest confusion is that pyrex marries both python and a magic brand of c-python code together in the same place – making it hard to know what “context” you are in at any point. To be kind, it does have some *really* cool features that Shed-Skin and PyPy/Rpython don’t have (such as properties). But the feeling of inconsistency and confusion I got while working with it just took the fun out of it for me.

6 Responses to “Struggling with pyrex”

  1. oleastre Says:

    For m, pyrex is usefulle to interface C code with python one, not for directly implementing stuff.

    You may write time consuming parts of your code in C and interface it with pyrex to be callable from python.

  2. Mark Dufour Says:

    doesn’t that kind of defeat the purpose of pyrex?

    btw, JIT compilers are similarly intransparent. with Psyco, it’s hard to tell when and why something will go much faster or not.

  3. Allefant Says:

    Sorry, I didn’ have a runnable version yet when I looked at the code yesterday, so didn’t try to pinpoint the speed problem. The mistake is one pyrex peculiarity – to get C style casts you need to use not float(). Now what happens in your code is, you perform lots of calls to the Python function float() where you meant to do a cast – killing any performance.

    Replace this:
    a=(float(x/SW) * 4.0 – 2.0)
    b=(float(y/SH) * 4.0 – 2.0)
    with this:
    a=(x/SW) * 4.0 – 2.0
    b=(y/SH) * 4.0 – 2.0

    And the per-frame time should drop by a factor of 10 or 20 🙂

  4. Allefant Says:

    Hm, somehow < and > got eaten in my comment?

  5. Allefant Says:

    It should have been:
    a=(<float>x/SW) * 4.0 – 2.0
    b=(<float>y/SH) * 4.0 – 2.0

  6. philhassey Says:

    Okay – that change got the speed similar to PyPy/Rpython and Shed-skin.