@@Jit Attribute Considerations

On Mon, Aug 3, 2020 at 8:51 PM Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

Only the trigger mode 4 (attributes) is actually using @@Jit("tracing")
and
"function". This trigger mode feels like micro-management for developers
and since it has virtually no spotlight in discussions and blog posts
about
the JIT at the moment, we don't know if it brings benefits.

I think turning JIT off is a valid use case, the rest looks much more
iffy. I am not sure we want to let people tell the engine to JIT certain
functions - are there a lot of cases where the engine wouldn't do it but
it's actually the right thing to do?

In that case maybe we should rename the attribute to @@DisableJit ? This
would not clutter the global namespace with a "jit" class.

Don't see any use for "opcache.jit=attributes".

--
Stas Malyshev
smalyshev@gmail.com

I think turning JIT off is a valid use case, the rest looks much more
iffy. I am not sure we want to let people tell the engine to JIT certain
functions - are there a lot of cases where the engine wouldn't do it but
it's actually the right thing to do?

Wouldn't a use case be profiling code, to see if JIT makes a difference to
a specific function? So I can profile with JIT disabled globally and @@JIT
on specific code, modify my code and see if it improves the JIT performance?

I'm basing this on my experience with the @jit annotation in Numba (
http://numba.pydata.org/) where it's useful to see the effect on small
pieces of code.

Peter

My solution:

• remove doc-comment trigger. It doesn't make sense.
• add @@Jit("off") only. Later we may extend this.

On Tue, Aug 4, 2020 at 11:11 AM Benjamin Eberlei kontakt@beberlei.de
wrote:

On Mon, Aug 3, 2020 at 7:44 PM Benjamin Eberlei kontakt@beberlei.de
wrote:

Hi,

I am going to pick up a discussion from
https://github.com/php/php-src/pull/5915 about the @@Jit attribute.

Nikita mentioned he is still not 100% clear what the usecase is for @@Jit
attribute and asked to discuss here.

The reason is that the default tracing JIT is clever to decide itself
when
to JIT or not, better not interfere with that. In case you run the
tracing
JIT, only @@Jit("off") has an effect the others @@Jit("tracing") and
@@Jit("function") get ignored.

Only the trigger mode 4 (attributes) is actually using @@Jit("tracing")
and "function". This trigger mode feels like micro-management for
developers and since it has virtually no spotlight in discussions and
blog
posts about the JIT at the moment, we don't know if it brings benefits.

Maybe for now it would be better to remove docblock / attribute support
for the JIT, and take a new attempt at it in 8.1? That prevents us from
rolling something we regret having to maintain later.

I updated the PR https://github.com/php/php-src/pull/5915 with the
following things:

• Removed attribute trigger mode for now.
• Removed obsolete doc comment trigger mode
• Add @@Jit("off") to disable JIT for an op_array or script

Open questions:

• Are we ok with removing @Jit("on"), @@Jit("tracing") and
  @@Jit("function") for now to thoroughly discuss best approach for 8.1?
• Rename @@Jit to something more specific like @@JitOptions or @@JitHint?
• Remove the attribute trigger constant 4, and move tracing JIT to use 4
  instead of 5?

Outlook:

We need to think about what the @@Jit attribute should actually mean in
context of the function or tracing JIT. Personally it probably means
"Always Jit this function regardless of hot counter or tracing results".
I believe we don't need the attributes trigger mode, as everything happens
either in context of function or tracing JIT.

greetings
Benjamin