[pypy-dev] Question on the future of RPython

Paolo Giarrusso p.giarrusso at gmail.com
Thu Sep 2 10:56:14 CEST 2010


On Thu, Sep 2, 2010 at 10:40, William Leslie
<william.leslie.ttg at gmail.com>wrote:

> But what makes you think that? A dynamic compiler has more information, so
> it should be able to produce better code.
>
Note that he's not arguing about a static compiler for the same code, which
has no type information, and where you are obviously right. He's arguing
about a statically typed language, where the type information is already
there in the source, e.g. C - there is much less information missing.
Actually, your point can still be made, but it becomes much less obvious.
For this case, it's much more contended what's best - see the "java faster
than C" debate. Nobody has yet given a proof convincing enough to close the
debate.

I would say that there's a tradeoff between JIT and Ahead-Of-Time
compilation, when AOT makes sense (not in Python, SmallTalk, Self...).

On 02/09/2010 6:37 PM, "Saravanan Shanmugham" <sarvi at yahoo.com> wrote:
>
> The point I was making is that RPython(a static subset of Python) will be
> faster
> than Dynamic Python code on a JIT or compiled to machine code.
>
> Note that, with enough implementation effort, that doesn't need to be true.
Run-time specialization would allow exactly the same code to be generated,
without any extra guards in the inner loop. Java can do that at times, and
can even be better than C, but not always (see above). You'd need a static
compiler with Profile-Guided Optimization and have a profile which matches
runtime, to guarantee superior results.

Cheers
-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20100902/d33bb6f2/attachment.html>


More information about the Pypy-dev mailing list