[pypy-dev] cppyy use case question

[Alex Pyattaev]

> 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.
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 
done.
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 
immediately.

> > 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 
library=)

Alex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20120603/f397c267/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reflex.tar.gz
Type: application/x-compressed-tar
Size: 119967 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20120603/f397c267/attachment-0001.bin>