Thanks for the answer. I had read the doc but didn't fully understood it
until I experienced it!
I have a few more questions if you don't mind. These should be less
trivial than the previous one.
I'm trying to experience the efficiency of the translation and jit-ing
tools provided by pypy on AST-based interpreters at different level of
complexity (from completly recursive toward completly iterative).
To test the speed of the interpreters, I use a program that write files:
given n and runs it produces two functions and a call. The first
function is f : x -> n*x but using a tree and only the + operator. The
second one is recursive
g : x -> if x=0 (f 3) else (f 3), (g (x-1)). Then I add a call: (g runs).
The aim is to force the JITing versions to recognize the instructions f
3 as needed to be traced and do it.
I have the following problems:
When translating the two JITing interpreters that I have (one purely
recursive, the second one tail-recursive in CPS), I get this warning:
[platform:WARNING] rpython_lltypesystem_rffi.c: In function
‘pypy_g__PyPy_dg_dtoa__Float_Signed_Signed_arrayPtr_arra’:
[platform:WARNING] rpython_lltypesystem_rffi.c:534: warning: passing
argument 4 of ‘_PyPy_dg_dtoa’ from incompatible pointer type
[platform:WARNING] rpython_lltypesystem_rffi.c:534: warning: passing
argument 5 of ‘_PyPy_dg_dtoa’ from incompatible pointer type
Whenever the tests take longer than a couple of seconds to be executed
by the non-JITing interpreter, JITing version get the following stack
overflow:
[...]
File "jit_metainterp_warmspot.c", line 194, in
ll_portal_runner__treeClass_F1WAEPtr_dicttablePt
File "implement.c", line 11681, in portal
File "jit_metainterp_warmspot.c", line 194, in
ll_portal_runner__treeClass_F1WAEPtr_dicttablePt
File "implement.c", line 12345, in portal
File "jit_metainterp_warmspot.c", line 194, in
ll_portal_runner__treeClass_F1WAEPtr_dicttablePt
File "implement.c", line 12345, in portal
...
Fatal RPython error: StackOverflow
Abort trap
The non JIT-ing version passes the test (n=10000, runs = 2000) in 2.4s,
the JITing counter-part takes 45s to raise the error when the cps JITing
version only takes 0.3s to stop.
I had already noticed the huge difference between JITing and non-JITing
versions (purely recursive) on tests that declare functions (they run in
similar time whithout function declaration). I guess it is due to the
"should I trace" phase.
My interpreting function takes an AST, a dictionnary of function
declaration and an environment (cps version has the continuation as
well). Everything is declared green.
You can find these files here:
https://github.com/zebign1/RPython-internship/tree/master/Interpreters/ifF1WAE
(I just came accross your tutorial on bitbucket, so I didn't know there
were parsing tools available with RPython — when I try to import the
parser module, translation failed — so I wrote my own parser, whici is
probably less efficient, but all the interpreters share the same.)
Here are my questions:
- What is the warning?
- What is the stack overflow? (I first thought it was the same bug as
before but it's not within a function I've written apparently)
- Is it normal that the JITing version takes 35x longer than the non
JITing version (is it due to the recursive form ?)?
- Have I made any mistakes declaring all my variables green? (it is
highly possible that I missed something here)
- Your tutorial transformed your AST into bytecode. Why?
Again, thank you for the answer.
Cheers
Leonard.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
