[pypy-dev] offtopic, ontopic, ...

[Amaury Forgeot d'Arc]

2012/2/14 Stefan Behnel <stefan_ml at behnel.de>

> Antonio Cuni, 14.02.2012 09:35:
> > On 02/14/2012 09:17 AM, Stefan Behnel wrote:
> >>
> >> Stuffing the code for both CPython and PyPy into the same C source file
> may
> >> result in a noticeable increase in C code size at some point, but as
> long
> >> as the C preprocessor can filter it back out, at least the build times
> >> won't go up all that much, and it's not like a couple of compressed
> KBytes
> >> more would hurt a PyPI package these days.
> >
> > This is unlikley to happen IMHO, because PyPy does not offer its own C
> API
> > (yet?). The only C API supported by PyPy is cpyext, which is a (slowish)
> > wrapper compatible with CPython.
> >
> > The only places where the C code needs to be different is where Cython
> > bypass the C API and directly manipulates the underlying C structures.
>
> I agree that this interconnection should grow out of cpyext, but I think we
> should look out for ways to extend (pun intended) that C-API in order to
> improve both the efficiency and the semantics.
>
> I mean, even Py_INCREF() is wrapped in another macro in Cython that we
> already replace by code that does ref-counting validation for us at test
> time. Feel free to let us generate any code you want for that, including
> special setup and cleanup code at a function boundary or other appropriate
> places.
>
> Higher level functionality could be wrapped in PyPy-specific C-API calls to
> avoid going through multiple CPython API calls, e.g. a method lookup
> followed by a call.
>
> We could emit hints like "the code is only going to use this object
> temporarily for iteration", which may allow PyPy to reduce the overhead of
> providing a C façade for it. Maybe there are mechanisms on PyPy side that
> Cython could hook into in order to create and use objects more efficiently,
> or it could drop optimistic optimisations that are known to never apply to
> PyPy and only cost runtime checks or degrade the performance in other ways.
>
> Seriously - we control the code on both sides. I think the possibilities
> are endless.


Why only think in terms of C code then? The best API pypy offers so far
is written in RPython - space operations, type definitions, and external C
calls.

The "only" missing part is to allow this in a separately compiled module.

-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20120214/02fe241b/attachment-0001.html>