<br><br><div class="gmail_quote">2012/2/14 Stefan Behnel <span dir="ltr"><<a href="mailto:stefan_ml@behnel.de">stefan_ml@behnel.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Antonio Cuni, 14.02.2012 09:35:<br>
<div class="im">> On 02/14/2012 09:17 AM, Stefan Behnel wrote:<br>
>><br>
>> Stuffing the code for both CPython and PyPy into the same C source file may<br>
>> result in a noticeable increase in C code size at some point, but as long<br>
>> as the C preprocessor can filter it back out, at least the build times<br>
>> won't go up all that much, and it's not like a couple of compressed KBytes<br>
>> more would hurt a PyPI package these days.<br>
><br>
> This is unlikley to happen IMHO, because PyPy does not offer its own C API<br>
> (yet?). The only C API supported by PyPy is cpyext, which is a (slowish)<br>
> wrapper compatible with CPython.<br>
><br>
> The only places where the C code needs to be different is where Cython<br>
> bypass the C API and directly manipulates the underlying C structures.<br>
<br>
</div>I agree that this interconnection should grow out of cpyext, but I think we<br>
should look out for ways to extend (pun intended) that C-API in order to<br>
improve both the efficiency and the semantics.<br>
<br>
I mean, even Py_INCREF() is wrapped in another macro in Cython that we<br>
already replace by code that does ref-counting validation for us at test<br>
time. Feel free to let us generate any code you want for that, including<br>
special setup and cleanup code at a function boundary or other appropriate<br>
places.<br>
<br>
Higher level functionality could be wrapped in PyPy-specific C-API calls to<br>
avoid going through multiple CPython API calls, e.g. a method lookup<br>
followed by a call.<br>
<br>
We could emit hints like "the code is only going to use this object<br>
temporarily for iteration", which may allow PyPy to reduce the overhead of<br>
providing a C façade for it. Maybe there are mechanisms on PyPy side that<br>
Cython could hook into in order to create and use objects more efficiently,<br>
or it could drop optimistic optimisations that are known to never apply to<br>
PyPy and only cost runtime checks or degrade the performance in other ways.<br>
<br>
Seriously - we control the code on both sides. I think the possibilities<br>
are endless.</blockquote><div><br></div><div>Why only think in terms of C code then? The best API pypy offers so far</div><div>is written in RPython - space operations, type definitions, and external C calls.</div><div><br>
</div><div>The "only" missing part is to allow this in a separately compiled module.</div></div><div><br></div>-- <br>Amaury Forgeot d'Arc<br>