PHP 8's JIT is currently mainly controlled through the opcache.jit
configuration directive [1].
The value for opcache.jit is currently a sequence of four digits, "5021"
for instance. This would activate JIT optimizations based on static type
inference and inner procedure analyses (Optimization Level), JIT
optimization of all functions on load of the respective sourcecode file
(Trigger), global linear-scan register allocator (Register Allocation),
and AVX instruction generation (CPU-Specific Optimization Flags).
I think that using a single configuration directive for these four
distinct aspects of just-in-compilation is a bad idea. Many will, at least
at first glance, mistake the value for a bitmask.
I think it would be best to split up opcache.jit into five separate
configuration directives and propose the following names:
- opcache.jit for (de)activating JIT
- opcache.jit_optimization_level for setting the optimization level
- opcache.jit_trigger for configuring the JIT trigger
- opcache.jit_register_allocation for configuring register allocation
- opcache.jit_cpu_flags for configuring CPU-specific flags
What do you think?
Am 14.04.2020 um 15:53 schrieb Sebastian Bergmann:
The value for opcache.jit is currently a sequence of four digits, "5021"
for instance. This would activate JIT optimizations based on static type
inference and inner procedure analyses (Optimization Level), JIT
optimization of all functions on load of the respective sourcecode file
(Trigger), global linear-scan register allocator (Register Allocation),
and AVX instruction generation (CPU-Specific Optimization Flags).
Sorry for the noise, but it is more confusing than I thought just a couple
of minutes ago. The RFC reads
Consists of 4 decimal digits - CRTO
and then lists the individual parts in reverse order (OTRC).
PHP 8's JIT is currently mainly controlled through the opcache.jit configuration directive [1].
The value for opcache.jit is currently a sequence of four digits, "5021" for instance. This would activate JIT optimizations based on static type inference and inner procedure analyses (Optimization Level), JIT optimization of all functions on load of the respective sourcecode file (Trigger), global linear-scan register allocator (Register Allocation), and AVX instruction generation (CPU-Specific Optimization Flags).
I think that using a single configuration directive for these four distinct aspects of just-in-compilation is a bad idea. Many will, at least at first glance, mistake the value for a bitmask.
I think it would be best to split up opcache.jit into five separate configuration directives and propose the following names:
- opcache.jit for (de)activating JIT
- opcache.jit_optimization_level for setting the optimization level
- opcache.jit_trigger for configuring the JIT trigger
- opcache.jit_register_allocation for configuring register allocation
- opcache.jit_cpu_flags for configuring CPU-specific flags
What do you think?
+1 for improving developer experience. Now’s the time to make this easier for folks to use. If we wait until after GA, we’ll have to support the harder-to-use sequence of digits for at least the rest of 8.x.
Cheers,
Ben
On Tue, Apr 14, 2020 at 3:53 PM Sebastian Bergmann sebastian@php.net
wrote:
PHP 8's JIT is currently mainly controlled through the opcache.jit
configuration directive [1].The value for opcache.jit is currently a sequence of four digits, "5021"
for instance. This would activate JIT optimizations based on static type
inference and inner procedure analyses (Optimization Level), JIT
optimization of all functions on load of the respective sourcecode file
(Trigger), global linear-scan register allocator (Register Allocation),
and AVX instruction generation (CPU-Specific Optimization Flags).I think that using a single configuration directive for these four
distinct aspects of just-in-compilation is a bad idea. Many will, at least
at first glance, mistake the value for a bitmask.I think it would be best to split up opcache.jit into five separate
configuration directives and propose the following names:
- opcache.jit for (de)activating JIT
- opcache.jit_optimization_level for setting the optimization level
- opcache.jit_trigger for configuring the JIT trigger
- opcache.jit_register_allocation for configuring register allocation
- opcache.jit_cpu_flags for configuring CPU-specific flags
What do you think?
I have made a PR for this and added two follow up discussion points:
https://github.com/php/php-src/pull/5510
-
We now have a bool opcache.jit and the "implicit" flag
opcache.jit_buffer_size which is 0 by default and leads to disabling the
JIT. Maybe we should turn these around and set opcache.jit=0 and
opcache.jit_buffer_size=16M (or whatever is a good default). -
The default for opcache.jit_trigger should be changed to 3 (profile and
jit hot functions only). This is suggested in the RFC as well.
Both changes would require tests to change, and changes to the CI setup to
make sure the build running with JIT enabled still works.
Hi Benjamin,
I think it would be best to split up opcache.jit into five separate
configuration directives and propose the following names:
- opcache.jit for (de)activating JIT
- opcache.jit_optimization_level for setting the optimization level
- opcache.jit_trigger for configuring the JIT trigger
- opcache.jit_register_allocation for configuring register allocation
- opcache.jit_cpu_flags for configuring CPU-specific flags
...
- We now have a bool opcache.jit and the "implicit" flag
opcache.jit_buffer_size which is 0 by default and leads to disabling the
JIT. Maybe we should turn these around and set opcache.jit=0 and
opcache.jit_buffer_size=16M (or whatever is a good default).
I'd agree with that - I keep forgetting that opcache.jit isn't a boolean.
To avoid confusion with the RFC and to be consistent with opcache.enable and opcache.enable_cli,
I'd prefer opcache.enable_jit={0,1} over opcache.jit.
Also, people who are reading a php.ini would not remember what opcache.jit_optimization_level=1 means.
Maybe supporting aliases for the 4 integer flags would be useful.
(opcache.jit_optimization_level={no,minimal,selective_inlining,jit_optimize_3,jit_optimize_4,jit_optimize_5|full})
- I can't think of a good name for 3-5. Also, it's possible that even more aggressive settings may be added in the future.
- Emit a startup error (or warn and use the default) if the alias or number is unrecognized.
One possibility I thought of is to default the jit_buffer_size to a multiple of opcache.memory_consumption,
which might be a reasonable default in most use cases.
(Large codebases would get a large buffer, tiny scripts would get a small buffer).
I'm not sure what that multiple should be or if there'd be a minimum that should be enforced.
- If opcache.memory_consumption is somehow set to 0 or negative (file_cache_only?), maybe go with a default such as 16M.
Thanks,
- Tyson
Hi Tyson,
For opcache.jit_optimization_level I think we'd better remain these magic
numbers, like what we did for opcache.optimization_level.
I think this kind of setting requires professional knowledge in this domain,
and it doesn't make much sense to change to the text-based
Options. E.g. what does "minimal" mean in this context?
Regards,
CHU Zhaowei
-----Original Message-----
From: tyson andre tysonandre775@hotmail.com
Sent: Saturday, May 2, 2020 9:59 PM
To: Benjamin Eberlei kontakt@beberlei.de; PHP Internals
internals@lists.php.net
Subject: Re: [PHP-DEV] opcache.jit directive should be split up
Hi Benjamin,
I think it would be best to split up opcache.jit into five separate
configuration directives and propose the following names:
- opcache.jit for (de)activating JIT
- opcache.jit_optimization_level for setting the optimization level
- opcache.jit_trigger for configuring the JIT trigger
- opcache.jit_register_allocation for configuring register
allocation- opcache.jit_cpu_flags for configuring CPU-specific flags
...
- We now have a bool opcache.jit and the "implicit" flag
opcache.jit_buffer_size which is 0 by default and leads to disabling
the JIT. Maybe we should turn these around and set opcache.jit=0 and
opcache.jit_buffer_size=16M (or whatever is a good default).
I'd agree with that - I keep forgetting that opcache.jit isn't a boolean.
To avoid confusion with the RFC and to be consistent with opcache.enable
and opcache.enable_cli, I'd prefer opcache.enable_jit={0,1} over
opcache.jit.
Also, people who are reading a php.ini would not remember what
opcache.jit_optimization_level=1 means.
Maybe supporting aliases for the 4 integer flags would be useful.
(opcache.jit_optimization_level={no,minimal,selective_inlining,jit_optimize _3,jit_optimize_4,jit_optimize_5|full})
- I can't think of a good name for 3-5. Also, it's possible that even more
aggressive settings may be added in the future. - Emit a startup error (or warn and use the default) if the alias or number
is unrecognized.
One possibility I thought of is to default the jit_buffer_size to a
multiple of opcache.memory_consumption, which might be a reasonable
default in most use cases.
(Large codebases would get a large buffer, tiny scripts would get a small
buffer).
I'm not sure what that multiple should be or if there'd be a minimum that
should be enforced.
- If opcache.memory_consumption is somehow set to 0 or negative
(file_cache_only?), maybe go with a default such as 16M.
Thanks,
- Tyson
--
To unsubscribe, visit:
http://www.php.net/unsub.php
Hi CHU Zhaowei,
By alias, I meant "an alternative name or label that refers to an item, and can be used to locate or access it."
(add a way to set the option without removing existing ways)
(Users would have the choice of using both the magic numbers or the strings to refer to the same setting value).
E.g. what does "minimal" mean in this context?
It's a short label based on the description of the value in https://wiki.php.net/rfc/jit#phpini_defaults
1 - minimal JIT (call standard VM handlers)
It would be easier for someone to remember/infer what opcache.jit_optimization_level=minimal
means than 1 if they saw it in their php.ini or a command line invocation,
with or without familiarity with the JIT.
(without needing to go to php.net)
Regards,
- Tyson