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

Reply via email to