[pypy-dev] Removal of RCTypes, the extension compiler, support for PyObjects

Carl Friedrich Bolz cfbolz at gmx.de
Tue Nov 20 18:07:26 CET 2007


this message of richard didn't make it to the list, I am forwarding it.

---------- Forwarded message ----------
From: Richard Emslie <rxe at ukshells.co.uk>
Date: 20.11.2007 17:49
Subject: Re: [pypy-dev] Removal of RCTypes, the extension compiler,
support for PyObjects
To: Carl Friedrich Bolz <cfbolz at gmx.de>
Cc: Martijn Faassen <faassen at startifact.com>, pypy-dev at codespeak.net




On Tue, 20 Nov 2007, Carl Friedrich Bolz wrote:

> Hi Martijn,
>
> Martijn Faassen wrote:
>> I'll just note what this might mean to you in terms of project
>> perception and perception of commitment:
>>
>> You're replacing one of the few areas of PyPy that at least *seemed* to
>> be useful in the near term for production use (even though it evidently
>> wasn't really) with "the extension compiler can be reimplemented with
>> rffi if someone is interested in doing that".
>>
>> I.e. you're removing your implicit commitment (in the form of code that
>> more or less worked) and replacing it with an explicit lack of
>> commitment or interest in making this work.
>
> I really thought we were through with that. So, again:
>
> First let me note that I think the extcompiler is a promising idea. I
> agree that the idea could lead to something generally useful. However:
> The current implementation is not useful at all. It wasn't used
> seriously by anybody. Richard tried to use it and he found that it
> wasn't creating anything useful, since the resulting CPython
> extensions weren't really any faster than just writing the stuff in
> pure Python to begin with.
>

To be more accurate - what was found was that the overhead of calling in
and out of the of the generated extension module outweighed the gain in
speed generated by the rpython code.  Also the generated code was not 100%
stable and even though I spent a few weeks hacking the generated code, it
was still segfaulting (whereas the non extension module was fine.)  All in
all I agree that removing the current implementation is the best course of
action for moving forward.

Cheers - Richard



More information about the Pypy-dev mailing list