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(a)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(a)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
