On Mon, Jan 12, 2015 at 1:09 PM, Armin Rigo <ar...@tunes.org> wrote:
> See the old explanation about our JIT here:
> rpython/doc/jit/pyjitpl5.rst. What changed from this old explanation
> is that if no can_enter_jit is found in the source code, one is
> automatically inserted just before the jit_merge_point.
>
Yes, I think I understand it now. I guess that doc needs some update to
include this as well as the fact that there should be no code between these
hints and both hints should have identical argument set.
About your other questions:
>
> > - Is it correct to not have any _user_ code run between can_enter_jit
> and jit_merge_point calls but have some _interpreter_ code there? Error
> message says that there should be _any_ code between them which seems
> hardly possible.
>
> There should not be any code that doesn't fully constant-fold away.
> You can have some function returns, and maybe close a loop that says
> "while True". You cannot close a loop that says "while more
> complicated condition".
>
I see only simple assignment "pc = new_pc" between them in lang-js. I guess
it's simple enough.
Looking at PyPy I've noticed that there still can be some code between
these hints if we're unlucky enough to catch e.g. KeyboardInterrupt after
can_enter_jit is called but before we leave handle_bytecode. Or does
exception handling in RPython differs from Python? There're just some
return's there but in CPython KeyboardInterrupt can be raised from any
bytecode.
By the way, can't this condition ("no complex code between hints") be
enforced at run-time (during tracing)? It seems that the only check
verifies only arguments passed to hints but not code itself.
I'm not sure to understand the distinction.
>
Yes, now I see that was nonsense.
> - Would it be more beneficial to analyse user code and provide
> can_enter_jit hint only for real loops instead of all backward jumps?
>
> It's a bit pointless. As I said, can_enter_jit is only an
> optimization: you make the JIT tracing a little bit faster by not
> calling it repeatedly before every single jit_merge_point. You could
> spend efforts and make it even less common using bytecode analysis,
> but you're hitting diminishing returns very quickly imho.
>
OK, I won't go there until tracing become bottleneck if that ever happens.
I guess having explicit can_enter_jit hint should still be useful. At least
I don't feel comfortable having JIT setting counts for every single
bytecode without it. That should be a waste of memory and cycles.
--
Kind regards, Yuriy.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
