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@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@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
participants (1)
-
Arthur Peters