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

[Stefan Behnel]

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.

Stefan