[pypy-dev] Question on the future of RPython

[Terrence Cole]

On Sun, 2010-09-26 at 23:57 -0700, Saravanan Shanmugham wrote:
> Well, I am happy to see that the my interest in a general purpose RPython is not 
> as isolated as I was lead to believe :-))
> Thx,

What I wrote has apparently been widely misunderstood, so let me explain
what I mean in more detail.  What I want is _not_ RPython and it is
_not_ Shedskin.  What I want is not a compiler at all.  What I want is a
visual tool, for example, a plugin to an IDE.  This tool would perform
static analysis on a piece of python code.  Instead of generating code
with this information, it would mark up the python code in the text
display with colors, weights, etc in order to show properties from the
static analysis.  This would be something like semantic highlighting, as
opposed to syntax highlighting.  

I think it possible that this information would, if created and
presented in the correct way, represent the sort of optimizations that
pypy-c-jit -- a full python implementation, not a language subset --
would likely perform on the code if run.  Given this sort of feedback,
it would be much easier for a python coder to write code that works well
with the jit: for example, moving a declaration inside a loop to avoid
boxing, based on the information presented.

Ideally, such a tool would perform instantaneous syntax highlighting
while editing and do full parsing and analysis in the background to
update the semantic highlighting as frequently as possible.  Obviously,
detailed static analysis will provide far more information than it would
be possible to display on the code at once, so I see this gui as having
several modes -- like predator vision -- that show different information
from the analysis.  Naturally, what those modes are will depend strongly
on the details of how pypy-c-jit works internally, what sort of
information can be sanely collected through static analysis, and,
naturally, user testing.

I was somewhat baffled at first as to how what I wrote before was
interpreted as interest in a static python.  I think the disconnect here
is the assumption on many people's part that a static language will
always be faster than a dynamic one.  Given the existing tools that
provide basically no feedback from the compiler / interpreter / jitter,
this is inevitably true at the moment.  I foresee a future, however,
where better tools let us use the full power of a dynamic python AND let
us tighten up our code for speed to get the full advantages of jit
compilation as well.  I believe that in the end, this combination will
prove superior to any fully static compiler.

-Terrence


> Sarvi
> 
> 
> ----- Original Message ----
> > From: Terrence Cole <list-sink at trainedmonkeystudios.org>
> > To: pypy-dev at codespeak.net
> > Sent: Sun, September 26, 2010 2:28:12 PM
> > Subject: Re: [pypy-dev] Question on the future of RPython
> > 
> > On Sat, 2010-09-25 at 17:47 +0200, horace grant wrote:
> > > i just had a  (probably) silly idea. :)
> > > 
> > > if some people like rpython so much,  how about writing a rpython
> > > interpreter in rpython? wouldn't it be much  easier for the jit to
> > > optimize rpython code? couldn't jitted rpython  code theoretically be
> > > as fast as a program that got compiled to c from  rpython?
> > >
> > > hm... but i wonder if this would make sense at all.  maybe if you ran
> > > rpython code with pypy-c-jit, it already could be  jitted as well as
> > > with a special rpython interpreter? ...if there were a  special rpython
> > > interpreter, would the current jit generator have to be  changed to
> > > take advantage of the more simple language?
> > 
> > An  excellent question at least.  
> > 
> > A better idea, I think, would be to  ask what subset of full-python will
> > jit well.  What I'd really like to  see is a static analyzer that can
> > display (e.g. by coloring names or lines)  how "jit friendly" a piece of
> > python code is.  This would allow a  programmer to get an idea of what
> > help the jit is going to be when running  their code and, hopefully, help
> > people avoid tragic performance  results.  Naturally, for performance
> > intensive code, you would still  need to profile, but for a lot of uses,
> > simply not having catastrophically  bad performance is more than enough
> > for a good user experience.  
> > 
> > With such a tool, it wouldn't really matter if the answer to "what  is
> > faster" is RPython -- it would be whatever python language  subset
> > happens to work well in a particular case.  I've started working  on
> > something like this [1], but given that I'm doing a startup, I  don't
> > have nearly the time I would need to make this useful in the  near-term.
> > 
> > -Terrence
> > 
> > [1]  http://github.com/terrence2/melano
> > 
> > > just curious...
> > > 
> > > 
> > > On Tue, Sep 7, 2010 at 11:07 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> > >  > Armin Rigo, 07.09.2010 10:57:
> > > >> On Mon, Sep 6, 2010 at 8:27  PM, Saravanan Shanmugham
> > > >>> Is there a wish list of RPython  enhancements somewhere that the
> > > >>> PyPy team might be  considering?
> > > >>> Stuff that would benefit RPython users in  general.
> > > >>
> > > >> Again, feel free to make a fork or a  branch of PyPy and try to develop
> > > >> a version of RPython that is  more suited to writing general programs
> > > >> in.
> > >  >
> > > > In that case, I suggest working on Shedskin or Cython  instead.
> > > >
> > > > Stefan
> > > >
> > > >  _______________________________________________
> > > > pypy-dev at codespeak.net
> > > >  http://codespeak.net/mailman/listinfo/pypy-dev
> > > >
> > >  _______________________________________________
> > > pypy-dev at codespeak.net
> > > http://codespeak.net/mailman/listinfo/pypy-dev
> > 
> > 
> > 
> > _______________________________________________
> > pypy-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/pypy-dev
> > 
> 
> 
>