[pypy-dev] go benchmark

[Maciej Fijalkowski]

On Mon, Aug 15, 2011 at 8:07 PM, Hakan Ardo <hakan at debian.org> wrote:
> Hi,
> I've been looking a bit at the go benchmark, which sometimes is
> significantly slower on jit-short_from_state.
>
> What's happening with default trace_limit=12000 on trunk is that the
> loop in random_playout is compiled into a loop containing 209 guards
> and the loop in computer_move is compiled into a loop with 390 guards.
> After that a lot of bridges are created. So I'm guessing we have some
> large loops here with a lot of different paths that are common.
>
> I patched go.py to print the number of loops, bridges and guards that
> was created each iteration using a pypyjit.set_compile_hook. It also
> prints when a loop with more than 200 guards are produced:
>
>    http://paste.pocoo.org/show/458824/
>
> Could this be fixed by...
> ... stop producing bridges after a fixed number of have been produced
> with the same root loop?
> ... never produce a bridge if it's parent trace have a large number of
> guards that have failed more than trace_eagerness/2 times?
> ... falling back on using a method jit in the above cases ;)
>
> Is this something I should investigate on jit-short_from_state, or
> could we consider it a separate problem and merge jit-short_from_state
> anyway? The only connection to jit-short_from_state I can think of is
> that bridges probably have become somewhat more expensive to produce.
>

Personally I would consider this a separate problem.