[pypy-dev] offtopic, ontopic, ...
Amaury Forgeot d'Arc
amauryfa at gmail.com
Tue Feb 14 10:41:10 CET 2012
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
> >> result in a noticeable increase in C code size at some point, but as
> >> 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
> >> more would hurt a PyPI package these days.
> > This is unlikley to happen IMHO, because PyPy does not offer its own C
> > (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
> 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
The "only" missing part is to allow this in a separately compiled module.
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pypy-dev