[pypy-dev] Re: Project suggestions

[Aurélien Campéas]

Michael Hudson a écrit :
> Aurélien Campéas <aurelien.campeas at free.fr> writes:
>>So the same graph can exist in three states : raw python, annotated
>>python (possible whenever the raw python matches rpython), low-level
>>stuff ?
> 
> 
> Yes.  Though I don't know if you can even form the flow graph of
> unrestricted Python (not saying you can't, just it wasn't a design
> goal).
> 

Still confused I am, then.
I thought you could annotate the graph because you programmed into 
rpython and thus enabled type inference, thereby allowing the production 
of a low-level C-friendly version of the graph ...

ok, it's not that important right now for me to understand it all anyway

> 
>>Then, to translate unrestricted python, I have to work on the first
>>pass/state of the graph.
> 
> 
> Yes.  But believe us on this one: ahead-of-time analysis on
> unrestricted python is not going to lead to significant speedups.

But there are maybe other benefits of an unrestricted python translator 
to lisp than only getting it natively compiled for small perf gains. 
Ability to develop quickly arbitrary extensions to python could be one 
beneficial side-effect, for instance.

>>>>>Thing is, I don't know how feasible this is.  It's pretty hard,
>>>>>without some kind of type inference, to translate, say this Python:
>>>>>   a + b
>>>>>into anything significantly more efficient than this Common Lisp:
>>>>>   (py:add a b)
>>>>
>>>>The mere fact that it will be compiled will make it more efficient I
>>>>guess. I mean, not on CLISP, but with a real lisp compiler.
>>>
>>>Not much.  The "interpreter overhead" for Python is usually
>>>estimated
>>>at about 20%, though it obviously depends what code you're running to
>>>some extent.
>>
>>hmmmm, 20% related to what ? Is this an observed quantity from
>>benchmarking, say, C-translated rpython vs CPython ?
> 
> 
> Well, it's very much a guesstimate, but what I was meaning to compare
> was interpreted python as against compiled c code that executes the
> same operations in the same order but without the overhead of
> dispatching the opcodes (this is more or less what the now
> more-or-less dead Python2C project did.  There's a reason it's
> more-or-less dead).
> 
> 
>>Also, "on average" can, as you say, cover a lot of differences
>>depending on what we have to do.
> 
> 
> Indeed!  If you're computation is bound, say, by the speed of
> multiplying really large integers, the interpreter overhead is roughly
> zero.  If you're manipluating small ints, then it's probably quite
> large.

Builtin ops like bignums arithmetic or whatever is implemented in C is 
obviously fast. OTOH, I wonder if some implementation choices of current 
CPyton, and part of its slowness, were made balancing simplicity of the 
code versus speed (stackless could be an example of a faster 
implementation, couldn't it ?). I remember having read stuff about that 
in some distant past.


> 
>>... but the more I think about it, it looks like CLOS might help with
>>these overloaded operators ...
> 
> 
> Maybe :) Please don't let me discourage you too much; I'd be genuinely
> interested in what you find.  But please don't expect miracles.
> 

Thanks, I am not discouraged and don't expect miracles :)
What pypy brings me right now is a nice way to enhance my 
{python,lisp}-fu at the same time. I am for sure quite far from 
discovering anything not already known. Would this happen, I'd let pypy 
people informed.


Cheers,
Aurélien.