Everything

php

@@Jit Attribute Considerations

php.internals

Benjamin Eberlei

6 years ago

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.

greetings
Benjamin

Stas Malyshev

6 years ago

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?

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

--
Stas Malyshev
smalyshev@gmail.com

Benjamin Eberlei

6 years ago

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.

Derick Rethans

6 years ago

On 3 August 2020 20:20:35 BST, Benjamin Eberlei <kontakt@beberlei.de> wrote:

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

Things with a negative name are usually a code smell. I'm not keen on a @[disableJit] attribute name.

cheers,
Derick

Benas IML

6 years ago

`@@NoJit` sounds pretty alright to me.

On Mon, Aug 3, 2020, 11:27 PM Derick Rethans <derick@php.net> wrote:

Benjamin Eberlei

6 years ago

Alternatively make it @@Jit("off") only and any other argument will lead to
an error for now.

Then the problem left becomes "Jit" being a very short global class.

On Mon, Aug 3, 2020 at 10:36 PM Benas IML <benas.molis.iml@gmail.com> wrote:

Peter Bowyer

6 years ago

On Mon, 3 Aug 2020 at 19:52, Stanislav Malyshev <smalyshev@gmail.com> wrote:

> 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

Benjamin Eberlei

6 years ago

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.

Dmitry Stogov

6 years ago

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:

A.L.E.C

6 years ago

On 06.08.2020 08:50, Dmitry Stogov wrote:

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

There are pros and cons to the "Jit" attribute name, please consider
@@JitOff (and @@JitOn).

Also make sure to define what happens if you use the attribute on a
function as well as class or e.g. class constant. In other words, when
it's not applicable will it be ignored or throw a warning/error?

--
Aleksander Machniak
Kolab Groupware Developer        [https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com