[pypy-dev] cppyy use case question

[wlavrijsen at lbl.gov]

Hi Alex,

> Thanks! I have accumulated some understanding about the process, and the issue
> can be worked around by having a dictionary that would map ints into python
> objects and vice versa before those are sent to c++, so when c++ functions
> feth them back they can be retreived.

good you found a workaround, as using cpyext from cppyy is turning out to be a
bigger can of worms that I expected. :} Will take a tad bit longer: I have some
working code, but only post-translation. For some reason, the resulting objects
look nothing as expected in the test and as passed, they go into the CPython
interpreter (this is a test, after all), which then bombs.

Post-translation, it's looking fine, though, and working as expected.

Performance ... is absolutely deplorable: slower than PyROOT on CPython!

My guess is that in the micro-benchmark, the JIT gets no chance of making a
trace out of the loop iteration, since the loop iteration requires the PyObject
in every call (the PyObject that I'm passing is the iterator variable itself).
I'll have to look into more detail ....

However, if I do not pass the loop iterator, but pass a constant, it is very,
very zippy (though far from what can be done by unwrapping the constant). My
guess here is that the JIT can move the constant out of the loop iteration,
and this thus spares all those cpyext calls. Iow., it isn't actually fast,
but the JIT has its way with the loop. Again, I need to look into that.

So, I can't check in any code that doesn't pass a test, and since you'd have
to rebuild anyway, let's hold off with checking this code in (unless you are
happy with a patch?). I'll get to it soon enough.

> With respect to build, I installed root from gentoo repository, and the
> problem there is that headers are in /usr/include/root and the actual libs are
> in /usr/lib/root, but the pypy build expects libs to be in
> /usr/include/root/lib if you specify SYSROOT=/usr/include/root.

Oops. Yes, that is something that can be solved easily enough.

> With respect to genreflex command, you could probably warn people that they
> should use gcc 4.3, not 4.6, cuz gccxml, used by genreflex, is not compatible
> with newer versions of STL, and crashes on standard headers.

That shouldn't be ... on my box I have gcc 4.6.2 and that does not pose any
problems. What version of gccxml do you have? Mine's at 0.9.0.

> Also, any headers
> that are not absolutely necessary to define the interface to Python should be
> removed if possible, that does make life a lot easier, even with SWIG, because
> it makes wrappers smaller.

Have you looked into providing a selection.xml to genreflex to select the
needed classes? Also, another common option is to collect all desired headers
in a single header file (with simple #include's) and feed that to genreflex,
together with a selection.xml that simply uses "*" patterns.

> PS: If you want I could give you benchmark results of cppyy vs cpyext+SWIG
> when we get it running, probably it will be of some interest.

My benchmarks are pure C++. :) But yes, I'm interested in any result, although
for now, the binary benchmark "it works yes/no" is already interesting.

Best regards,
            Wim
-- 
WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net