On 20 August 2010 16:04, Hart's Antler <[email protected]> wrote: > Hi Paolo, > > thanks for your in-depth response, i tried your suggestions and noticed a big > speed improvement with no more degrading performance, i didn't realize having > more green is bad. However it still runs 4x slower than just plain old > compiled RPython, i checked if the JIT was really running, and your right its > not actually using any JIT'ed code, it only traces and then aborts, though > now i can not figure out why it aborts after trying several things. > > I didn't write this as an app-level function because i wanted to understand > how the JIT works on a deeper level and with RPython. I had seen the blog > post before by Carl Friedrich Bolz about JIT'ing and that he was able to > speed things up 22x faster than plain RPython translated to C, so that got me > curious about the JIT. Now i understand that that was an exceptional case, > but what other cases might RPython+JIT be useful? And its good to see here > what if any speed up there will be in the worst case senairo. > > Sorry about all the confusion about numpy being 340x faster, i should have > added in that note that i compared numpy fast fourier transform to Rpython > direct fourier transform, and direct is known to be hundreds of times slower. > (numpy lacks a DFT to compare to) > > updated code with only the length as green: http://pastebin.com/DnJikXze > > The jitted function now checks jit.we_are_jitted(), and prints 'unjitted' if > there is no jitting. > abort: trace too long seems to happen every trace, so we_are_jitted() is > never true, and the 4x overhead compared to compiled RPython is then > understandable. > > trace_limit is set to its maximum, so why is it aborting? Here is my > settings: > jitdriver.set_param('threshold', 4) > jitdriver.set_param('trace_eagerness', 4) > jitdriver.set_param('trace_limit', sys.maxint) > jitdriver.set_param('debug', 3) > > > Tracing: 80 1.019871 > Backend: 0 0.000000 > Running asm: 0 > Blackhole: 80 > TOTAL: 16.785704 > ops: 1456160 > recorded ops: 1200000 > calls: 99080 > guards: 430120 > opt ops: 0 > opt guards: 0 > forcings: 0 > abort: trace too long: 80 > abort: compiling: 0 > abort: vable escape: 0 > nvirtuals: 0 > nvholes: 0 > nvreused: 0
This application probably isn't a very good use for the jit because it has very little control flow. It may unroll the loop, but you're probably not gaining anything there. As long as the methods get inlined (as there is no polymorphic dispatch here that I can see), jit can't improve on this much. What optimisations do you expect it to make? -- William Leslie _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
