[pypy-dev] cpyext performance

wlavrijsen at lbl.gov wlavrijsen at lbl.gov
Tue Jul 10 21:20:07 CEST 2012


Hi Amaury,

On Tue, 10 Jul 2012, Amaury Forgeot d'Arc wrote:
> 2012/7/10  <wlavrijsen at lbl.gov>:
>> Generating such a C function by the backend then requires a C-API for the
>> calls to do the wrapping. That PyPy C-API is a long awaited project. :)
> Do you have an idea what this API would look like?
> Then I can help with the implementation :)

I'm trying to resist the urge to say that it should be the Python C-API, with
all PyObject*'s replaced by PyPyObject*'s. :)

For callbacks, something simpler could do. For example, the PyPyObject*'s
passed in (i.e. the wrapped callback arguments), are going to be fully owned
by the callback function. That way, the JIT is not blind to what happens to
the objects, which should lead to better traces.

Myself, I have two needs for callbacks: GUIs and fitting. For the former,
performance is a non-issue. These callbacks are things like "button clicked",
and its thread safety and clean error handling that's important. As an API,
something like PyPyRun_SimpleString or PyPyRun_AnyFile will already do fine.

The latter, which is closer to what Eleytherios wants, I think, could be
self-contained. More likely, (our) users will want to implement a __call__
member function and pass the callable instance. The idea is to have access
to instance-specific data. Since the instance must live somewhere before
being send down the wire, its data are basically global. In terms of API, to
generate the C stub, a simple PyPyObject_Call() would be enough (the tracking
of the relevant PyPyObject* would be done in the bindings layer at the
interpreter level; this is how it currently works in PyROOT/CPython as well).

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


More information about the pypy-dev mailing list