<mattip>
in the same file, ufunc_generic_fastcall calls replace_with_wrapped_result_and_return
<mattip>
in the first one full_args is OK, in the second it is not
<mattip>
ahh, no, now I have confused myself again
<mattip>
ignore this
lehmrob has quit [Quit: Konversation terminated!]
[Arfrever] has joined #pypy
Julian has quit [Ping timeout: 272 seconds]
smarr has joined #pypy
Julian has joined #pypy
<smarr>
Hi: To improve interpreter performance, I added a few specializations for method calls with 1,2, and 3 arguments. So, I do now have specialized classes to to handle these cases, and the n-ary standard case. Previously, everything was the n-ary case, and the calling convention was to simply pass an array/list with the arguments. This specialization gives a good speedup of 25% in the interpreter, so, is rather valuable.
<smarr>
Unfortunately, the recursive benchmarks do not seem to like it when JIT compiled. I see them getting 2-5x slower. Is there possibly something I could be doing wrong with the JitDrivers? Instead of having a single one, for each arity specialization, I have a separate one, to be able to name the `reds` explicitly.
<smarr>
The functions perviously had different `self` identifies already (listed as `greens`). So, by my understanding, I would not expect the JIT compiler to trigger much differently. The difference I can think of is that some traces should now be a little shorter, because the specialized versions need to do fewer work. But perhaps I am missing something the JitDriver is doing, which now doesn't happen anymore, and it triggers differently?