2012/2/14 Stefan Behnel <stefan...@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
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
