[pypy-dev] Internship and bug report

[Léonard de Haro]

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.