[pypy-dev] Questions from a lurker

Arthur Peters amp at singingwizard.org
Mon Jul 18 21:20:19 CEST 2005


I accidently replied to this off list, so the off-list emails (3 of them)
are appended for postarity.

Also I fixed the problem with test_all.py: I had created a __init__.py
file directly in pypy-dist. I don't remember why I created it. Result
was sure strange. Anyway it was my fault.

Thanks all.
-Arthur

----------------------------------------------------

On Sun, 2005-07-17 at 00:25 +0200, Carl Friedrich Bolz wrote:
> Hi Arthur,
> 
> some more notes -- again I might not be the perfect person to answer 
> this, corrections welcome.
> 
> Arthur Peters wrote:
> [snip]
> > Makes sense, but it seems to me that there will be a lot of overlap
> > between the translator and the JIT compiler. Couldn't large parts of
> > the translator be reused?
> 
> Yes and no. The translator (and especially the type inference which we 
> call annotation) works on special assumptions that don't apply to a 
> regular programs: For example that the objects bound to a name in a 
> certain place always have the same type.
> 
> > 
> > BTW, I actually haven't heard for certain that there will be a JIT
> > compiler. Will there be? I'd really like to see one. Python is a great
> > language but runs slow sometimes and I think a JIT could really help.
> > Though one of the main slow things about it is the function call
> > overhead and for that to be reduced JIT compilation would have to happen
> > at a level higher than functions and would need type inference and all
> > that. However it would be really cool to have things like inlining of
> > functions (it would require a decorator to mark the function as
> > invariant so that the compiler knows that it cannot be changed at
> > runtime like normal python functions can). I come from a C++ background
> > so I'm used to having simple functions be as fast as macros.
> 
> Yes, there will be a JIT compiler although probably a bit different from 
> other JIT compilers. The problem is that Python is so very dynamic that 
> you cannot really know /anything/ in advance. Which means that even 
> "just in time" -- e.g. right before the program is run -- is too early.
> (This does not apply to the code our translator translates, because that 
> code, mainly PyPy's interpreter, was written with a lot of limitation 
> especially regarding the dynamism.) The first time you really know 
> anything for sure about a Python function is when you run it for the 
> first time (because then you have fixed values with fixed types to work 
> with). This is (heavily simplified) the idea driving Psyco: Psyco gets 
> information about a function when this function is being executed.
> 
> I'm not totally sure whether the thing that makes Python slow is really 
> the function calls. One of the slower things might be dispatching (which 
> function will be executed for the code a + b) which is a thing that 
> Psyco addresses. And, ideally, the user would not need to take care of 
> telling the JIT which function to inline, the JIT should rather be 
> clever enough to realize that a function is worth inlining. I even think 
> that the JIT could do this better than the programmer.
> 
> > 
> > Also it seems sad to have such a cool and difficult to create things as
> > the translator end up only being used on one program. It seems like it
> > could be useful elsewhere.
> > 
> 
> Yesish. The problem is that it's rather hard to get the translator 
> working for a given Python program (or rather, get the program working 
> for the translator :-) ). At the moment you'd have to adhere to a lot of 
> restrictions which are sometimes not easy to explain. This will problem 
> only change to a certain degree.
> 
> Regards,
> 
> Carl Friedrich 

-------------------------------------------------

On Sat, 2005-07-16 at 17:40 -0500, Arthur Peters wrote:
> On 7/16/2005, "Carl Friedrich Bolz" <cfbolz at gmx.de> wrote:
> >Yes, there will be a JIT compiler although probably a bit different from
> >other JIT compilers. The problem is that Python is so very dynamic that
> >you cannot really know /anything/ in advance. Which means that even
> >"just in time" -- e.g. right before the program is run -- is too early.
> >(This does not apply to the code our translator translates, because that
> >code, mainly PyPy's interpreter, was written with a lot of limitation
> >especially regarding the dynamism.) The first time you really know
> >anything for sure about a Python function is when you run it for the
> >first time (because then you have fixed values with fixed types to work
> >with). This is (heavily simplified) the idea driving Psyco: Psyco gets
> >information about a function when this function is being executed.
> 
> That makes sense.
> 
> >
> >I'm not totally sure whether the thing that makes Python slow is really
> >the function calls. One of the slower things might be dispatching (which
> >function will be executed for the code a + b) which is a thing that
> >Psyco addresses. And, ideally, the user would not need to take care of
> >telling the JIT which function to inline, the JIT should rather be
> >clever enough to realize that a function is worth inlining. I even think
> >that the JIT could do this better than the programmer.
> 
> I agree.
> 
> What I ment was a decorator that said that the method (or perhaps I
> should say method name) would not be rebound. This would allow the
> function to be embeded in the caller without fear of rebinding. This
> would be an issue because this is valid:
> 
> class A:
>   def f(self):
>     pass
> 
> def call_f(a):
>   a.f()
> 
> a = A()
> call_f(a) # does nothing
> 
> def new_f():
>   print "Hi"
> 
> a.f = new_f
> 
> call_f(a) # prints "Hi"
> 
> If A.f were inlined into call_f then the second call to call_f would
> either run the wrong code or would have to trigger a recompile.
> 
> -Arthur

----------------------------------------------------

On Sat, 2005-07-16 at 10:40 -0500, Arthur Peters wrote:
> Answer interlaced.
> 
> On 7/16/2005, "Carl Friedrich Bolz" <cfbolz at gmx.de> wrote:
> >> - I read what some discussion of the GIL as it relate to pypy and I agree
> >> that the GIL need to be implemented and that a different thread model
> >> might be a good way to go. However I thought of the following: Would it
> >> be possible to detect when a section of code only uses local variables
> >> and unlock the GIL? This seems possible because local variables will
> >> cannot be shared between threads anyway. In addition, local variables
> >> likely be translated into more basic types than a python object (native
> >> ints and floats for instance), that would not require any interaction
> >> with the object-space to manipulate (not sure about that usage of the
> >> term "object-space"). Thoughts?
> >
> >First a comment about the usage of the term "object space": I think you
> >are mixing levels here (and I might misunderstand you). The PyPy
> >interpreter (meaning the bytecode interpreter plus the standard
> >objectspace) gets translated to low level code. This "interpreter level
> >code" deals with the standard object space as a regular class instance
> >that is in principle in no way different than any other class. The
> >classes that appear on interpreter level are all translated to more
> >basic types (what would be the alternative, there is no layer below that
> >could deal with anything else), probably to something like a struct.
> >Thus the operations of objects at this level never need to be done via
> >the object space -- the object space is rather a regular object in itself.
> >
> >The object space /is/ used, if you interpret a Python program with
> >PyPy's interpreter. The bytecode interpreter does not now how to deal
> >with /any/ object (except for True and False), it has to delegate to the
> >object space for every single operation. Even for basic types like ints
> >and such -- at this level ("application level") there isn't any type
> >inference or anything like that!
> 
> Makes sense, but it seems to me that there will be a lot of overlap
> between the translator and the JIT compiler. Couldn't large parts of
> the translator be reused?
> 
> BTW, I actually haven't heard for certain that there will be a JIT
> compiler. Will there be? I'd really like to see one. Python is a great
> language but runs slow sometimes and I think a JIT could really help.
> Though one of the main slow things about it is the function call
> overhead and for that to be reduced JIT compilation would have to happen
> at a level higher than functions and would need type inference and all
> that. However it would be really cool to have things like inlining of
> functions (it would require a decorator to mark the function as
> invariant so that the compiler knows that it cannot be changed at
> runtime like normal python functions can). I come from a C++ background
> so I'm used to having simple functions be as fast as macros.
> 
> Also it seems sad to have such a cool and difficult to create things as
> the translator end up only being used on one program. It seems like it
> could be useful elsewhere.
> 
> >Hope that helped a bit and wasn't too confused :-).
> 
> I got most of it. ;-) Thanks a bunch.
> 
> -Arthur



More information about the Pypy-dev mailing list