[pypy-dev] cppyy use case question
alex.pyattaev at gmail.com
Mon Jun 4 01:40:35 CEST 2012
Please, mention in the manual, for the mortals, that the reflection library
has to be linked with -lReflex, so that they do not have to figure that out on
sunnuntai 03 kesäkuu 2012 02:33:15 Alex Pyattaev kirjoitti:
> 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
Cpyext is not needed with cppyy as far as I understand, is it?
> Post-translation, it's looking fine, though, and working as expected.
> Performance ... is absolutely deplorable: slower than PyROOT on CPython!
Performance was originally the point, right? Or am I missing something (lol)?
> 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 ....
I am giving you my benchmark code, right now it uses dictionary to map
pyobject id into objects when they leave c++ domain. Obviously, you add about
O(2*log(N)) overhead to the code, but that should not be too much anyway. If
that can be done in rpython, it could probably be made to work massively
faster. Like a module that does object caching for the storage of objects
that would be sent to c++ domain. Then in c++ one can do as simple as have an
long int index that can be used to resolve back to byobject when the job is
It also does classical SWIG typemap to do the same job. to use swig use
SConstruct build. Or just use the run.sh script to get all the stuff
> > 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.
mine is 0.9.0-2009.05.16, but it does crash with gcc 4.6. maybe you have older
gcc in a different slot?
> > 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.
The point is that if the header is included, and it confuses the parser, then
the patterns have no effect. So it is better not to have extra headers like Qt
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pypy-dev