Hi Stefan,
Cython is a programming language, so you can stick anything you like into
the wrapper. Note that a lot of code is not being (re-)written specifically
for a platform (CPython/PyPy/...), or at least shouldn't be, so when
writing a wrapper as a library, you may want to put some (and sometimes a
lot of) functionality into the wrapper itself. Be it to make a C-ish
interface more comfortable or to provide a certain functionality on top of
a bare C/C++ library. Also, Cython allows you to parallelise code quite
easily based on OpenMP, another thing that is often done in wrappers for
computational code.
ah, so even the whole loop could be in the wrapper and thus generated. (In
my case, the C++ code is always "as-is" since the C++ API to be bound is by
definition pre-existing, and often not under control of the Python developer
who wants to use it.)
That brings me to something else: one thing that I'd love to know from the
signature object, but this may not be relevant to the Cython use case since
both ends are controlled, is what the ownership rules are for each of the
arguments and the return type.
For C, this may not be too relevant, other than for const char* returns,
but for C++ it's rather important: unless an API follows a strict convention
(e.g. all non-const pointers passed in get owned, everything const does not
get modified, consistent naming, etc.), it's hard to do anything fully
automatic, so patch-ups are frequently needed.
IIRC, exceptions can be surprisingly expensive in C++, so I agree that it
matters for very small functions. But you'd want to inline those anyway and
avoid exceptions if at all possible.
Right, but any inlining in my case is done by the PyPy JIT, and it is blind
the moment C++ gets entered. So, I'm a bit out of luck there: it'll take a
lot more engineering to combine several consecutive C++ calls into one set,
which as a whole is then put in a try/catch.
However, what could be done if together with the python binding from cppyy,
such a signature would be made available through a property (is a triviality,
given that all reflection information is available), then any bound C++
function through cppyy (or PyCling on CPython for that matter) could be made
part of the Cython generated code and be inlined after all. Sounds pretty
cool to me.
Ah, sorry, misread your paragraph. You were talking about alternative
signatures. Yes, those require at least some setup overhead in static code.
Should be possible to avoid that overhead in loops, though. We'll see how
that works out.
Depending on at which point the code kicks in, but if the input are still
boxed types, then in my experience the fastest approach by far, is to hash
their types and memoize the overload selection made on that hash.
Best regards,
Wim
--
[email protected] -- +1 (510) 486 6411 -- www.lavrijsen.net
_______________________________________________
pypy-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-dev
