This is fantastic news thank you! I was going to ask if JIT would also work
when Opcache is enabled with "opcache.file_cache_only". Our use case is a
ReactPHP app that right now only has Opcache basically for the
optimizations and we do not use the standard shared memory portion. We
believe JIT could improve quite a lot these kinds of "long-running"
processes that can serve multiple requests per-process. Thanks a lot!

This is fantastic news thank you! I was going to ask if JIT would also
work when Opcache is enabled with "opcache.file_cache_only".

Unfortunately, not yet, but we are planning to move opcache into PHP-8
core and allow optimization and JIT without caching.

Our use
case is a ReactPHP app that right now only has Opcache basically for the
optimizations and we do not use the standard shared memory portion. We
believe JIT could improve quite a lot these kinds of "long-running"
processes that can serve multiple requests per-process. Thanks a lot!

Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where we
are going to continue active improvement, and into PHP-7.4, as an
experimental feature.
Thanks. Dmitry.

This is fantastic news thank you! I was going to ask if JIT would also
work when Opcache is enabled with "opcache.file_cache_only".

Unfortunately, not yet, but we are planning to move opcache into PHP-8
core and allow optimization and JIT without caching.

Our use
case is a ReactPHP app that right now only has Opcache basically for the
optimizations and we do not use the standard shared memory portion. We
believe JIT could improve quite a lot these kinds of "long-running"
processes that can serve multiple requests per-process. Thanks a lot!

Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where we
are going to continue active improvement, and into PHP-7.4, as an
experimental feature.
Thanks. Dmitry.

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an experimental
feature.

Thanks. Dmitry.

This has been a long time on the horizon, nice to see this finally moving
forward :)

Here are some initial thoughts: I think that it's best to approach this
issue from a cost/benefit angle. The benefits of the JIT compiler are
roughly (and as already outlined in the RFC):

Significantly better performance for numerical code.

Slightly better performance for "typical" PHP web application code.

The potential to move more code from C to PHP, because PHP will now be
sufficiently fast.

However, there are also a number of costs, on which I'll expand in more
detail:

a) Maintenance: This is really my main concern. Right now there are about
3-4 people who I would trust to carry out a non-trivial language change,
which will require touching the compiler, the virtual machine, the
optimizer and the persistence layer. Each of those components is quite
complex, in different ways. Some people who are comfortable with doing VM
changes will struggle with implementing optimizer changes.

Adding a JIT compiler exacerbates this issue further. Because this JIT is
dynasm based, the core JIT code is essentially written in raw x86 assembly.
This will further limit the pool of people who will be able to make
non-trivial engine changes. Personally, I don't have any particular
familiarity with writing x86 assembly, so it will likely take a while to
get up to speed with this code.

b) Bugs and stability: I think that everyone is aware that the initial PHP
7.3 release suffered from substantial stability issues, more than new minor
version releases tend to do. I think there are multiple reasons for that
(and we might want to start a conversation about our QA processes in a
separate thread), but one main contributing factor were opcache optimizer
bugs. Compiler optimizations are tricky and hard to verify, and we often
only learn about issues once the optimizer makes contact with production
codebases, which feature a much richer collection of code patterns than our
test suite. One can wonder whether the relatively minor speedups we get
from our optimization framework are really worth having these stability
issues...

Adding a JIT compiler adds a new dimension of stability issues. Next to
"simple" executor bugs, and optimizer bugs, we now get additional bugs in
the JIT. These are probably going to be hard to debug, as we'll have to
drop down from our usual C-level tooling, down to inspecting assembly.

c) Platform support: Having a JIT segregates platforms into two tiers:
Those that have JIT support and those that don't. While that is not a
problem per se, it does introduce some dangers. For example, if we decide
to more parts of our C code into PHP because PHP is fast enough with a JIT,
that will of course only be true for platforms that actually have JIT
support. I'm not terribly concerned about loosing out some performance on
MIPS, but we do need to make sure that all our main platforms are supported
(Windows is a must there, imho).

d) Debugging: I'm not sure whether or not this is an issue (maybe the RFC
can clarify?), but I'm wondering if this will have an impact on things like
XDebug. Will it be possible to using XDebug to accurately inspect variables
at any point in time while the JIT is running? If not, that would be a big
tooling regression.

Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where we
are going to continue active improvement, and into PHP-7.4, as an
experimental feature.
Thanks. Dmitry.

This has been a long time on the horizon, nice to see this finally
moving forward :)

Here are some initial thoughts: I think that it's best to approach this
issue from a cost/benefit angle. The benefits of the JIT compiler are
roughly (and as already outlined in the RFC):

* Significantly better performance for numerical code.
* Slightly better performance for "typical" PHP web application code.
* The potential to move more code from C to PHP, because PHP will now
be sufficiently fast.

However, there are also a number of costs, on which I'll expand in more
detail:

a) Maintenance: This is really my main concern. Right now there are
about 3-4 people who I would trust to carry out a non-trivial language
change, which will require touching the compiler, the virtual machine,
the optimizer and the persistence layer. Each of those components is
quite complex, in different ways. Some people who are comfortable with
doing VM changes will struggle with implementing optimizer changes.

Adding a JIT compiler exacerbates this issue further. Because this JIT
is dynasm based, the core JIT code is essentially written in raw x86
assembly. This will further limit the pool of people who will be able to
make non-trivial engine changes. Personally, I don't have any particular
familiarity with writing x86 assembly, so it will likely take a while to
get up to speed with this code.

b) Bugs and stability: I think that everyone is aware that the initial
PHP 7.3 release suffered from substantial stability issues, more than
new minor version releases tend to do. I think there are multiple
reasons for that (and we might want to start a conversation about our QA
processes in a separate thread), but one main contributing factor were
opcache optimizer bugs. Compiler optimizations are tricky and hard to
verify, and we often only learn about issues once the optimizer makes
contact with production codebases, which feature a much richer
collection of code patterns than our test suite. One can wonder whether
the relatively minor speedups we get from our optimization framework are
really worth having these stability issues...

Adding a JIT compiler adds a new dimension of stability issues. Next to
"simple" executor bugs, and optimizer bugs, we now get additional bugs
in the JIT. These are probably going to be hard to debug, as we'll have
to drop down from our usual C-level tooling, down to inspecting assembly.

c) Platform support: Having a JIT segregates platforms into two tiers:
Those that have JIT support and those that don't. While that is not a
problem per se, it does introduce some dangers. For example, if we
decide to more parts of our C code into PHP because PHP is fast enough
with a JIT, that will of course only be true for platforms that actually
have JIT support. I'm not terribly concerned about loosing out some
performance on MIPS, but we do need to make sure that all our main
platforms are supported (Windows is a must there, imho).

I don't see any problems with including JIT without Windows support.
Windows runs PHP much slower any way.

d) Debugging: I'm not sure whether or not this is an issue (maybe the
RFC can clarify?), but I'm wondering if this will have an impact on
things like XDebug. Will it be possible to using XDebug to accurately
inspect variables at any point in time while the JIT is running? If not,
that would be a big tooling regression.

Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where we
are going to continue active improvement, and into PHP-7.4, as an
experimental feature.
Thanks. Dmitry.

This has been a long time on the horizon, nice to see this finally
moving forward :)

Here are some initial thoughts: I think that it's best to approach this
issue from a cost/benefit angle. The benefits of the JIT compiler are
roughly (and as already outlined in the RFC):

Significantly better performance for numerical code.

Slightly better performance for "typical" PHP web application code.

The potential to move more code from C to PHP, because PHP will now
be sufficiently fast.

However, there are also a number of costs, on which I'll expand in more
detail:

a) Maintenance: This is really my main concern. Right now there are
about 3-4 people who I would trust to carry out a non-trivial language
change, which will require touching the compiler, the virtual machine,
the optimizer and the persistence layer. Each of those components is
quite complex, in different ways. Some people who are comfortable with
doing VM changes will struggle with implementing optimizer changes.

Adding a JIT compiler exacerbates this issue further. Because this JIT
is dynasm based, the core JIT code is essentially written in raw x86
assembly. This will further limit the pool of people who will be able to
make non-trivial engine changes. Personally, I don't have any particular
familiarity with writing x86 assembly, so it will likely take a while to
get up to speed with this code.

b) Bugs and stability: I think that everyone is aware that the initial
PHP 7.3 release suffered from substantial stability issues, more than
new minor version releases tend to do. I think there are multiple
reasons for that (and we might want to start a conversation about our QA
processes in a separate thread), but one main contributing factor were
opcache optimizer bugs. Compiler optimizations are tricky and hard to
verify, and we often only learn about issues once the optimizer makes
contact with production codebases, which feature a much richer
collection of code patterns than our test suite. One can wonder whether
the relatively minor speedups we get from our optimization framework are
really worth having these stability issues...

Adding a JIT compiler adds a new dimension of stability issues. Next to
"simple" executor bugs, and optimizer bugs, we now get additional bugs
in the JIT. These are probably going to be hard to debug, as we'll have
to drop down from our usual C-level tooling, down to inspecting assembly.

c) Platform support: Having a JIT segregates platforms into two tiers:
Those that have JIT support and those that don't. While that is not a
problem per se, it does introduce some dangers. For example, if we
decide to more parts of our C code into PHP because PHP is fast enough
with a JIT, that will of course only be true for platforms that actually
have JIT support. I'm not terribly concerned about loosing out some
performance on MIPS, but we do need to make sure that all our main
platforms are supported (Windows is a must there, imho).

I don't see any problems with including JIT without Windows support.
Windows runs PHP much slower any way.

Without my usual Windows bias, I do believe it is a considerable fact
like Nikita pointed out as Windows is a first class citizen in terms
of operating systems we support. While PHP on Windows may not have the
speed that the Unix counterpart have, it is still a very important
development platform. Many developers develop on Windows and deploy on
a Unix based system, being unable to test such an important feature in
a development environment is also a large question mark.

I'm personally interested in taking a look at it (and I'm certain
Anatol does too), but simply dismissing is a no-go for me.

Without my usual Windows bias, I do believe it is a considerable fact
like Nikita pointed out as Windows is a first class citizen in terms
of operating systems we support. While PHP on Windows may not have the
speed that the Unix counterpart have, it is still a very important
development platform. Many developers develop on Windows and deploy on
a Unix based system, being unable to test such an important feature in
a development environment is also a large question mark.

As long as we can agree that very few actually *deploy *on Windows, I think
we're on solid grounds.
As the JIT implementation is likely to have at least some significant
differences compared to Linux, I'm not sure what testing it on Windows
would give you. JIT is supposed to be entirely transparent, and the
performance characteristics - as well as the bug patterns - are likely to
be quite different on Linux vs. Windows, at least in many cases.
Is it really that important to have?

I'm honestly a bit perplexed by how many people here viewing Windows
support as a must have, while at the same time I think we all agree PHP is
very scarcely found on production Windows servers, and JIT is a
predominantly production feature.

I'm personally interested in taking a look at it (and I'm certain

Anatol does too), but simply dismissing is a no-go for me.

It'd be interesting to evaluate the cost associated with supporting
Windows. Bare in mind, we're proposing to vote on this as a production
feature for PHP 8 - which realistically means almost two years from now at
the earliest. I'm sure we'd have Windows support a lot sooner than that
if we decide that it's a must have. I agree with Nikita that the key
question is in fact, do we or do we not want to introduce JIT in - with the
main question being the maintenance cost. Let's tackle this question
first, otherwise - why send Dmitry (and maybe others) for doing more work
(Windows support) if we are likely to flush it all down the toilet?

I think that if we reach the conclusion that Windows support is a must, we
can condition the inclusion of JIT based on having it. Let's first agree
on whether we want it in the first place.

Without my usual Windows bias, I do believe it is a considerable fact
like Nikita pointed out as Windows is a first class citizen in terms
of operating systems we support. While PHP on Windows may not have the
speed that the Unix counterpart have, it is still a very important
development platform. Many developers develop on Windows and deploy on
a Unix based system, being unable to test such an important feature in
a development environment is also a large question mark.

As long as we can agree that very few actually *deploy *on Windows, I think
we're on solid grounds.
As the JIT implementation is likely to have at least some significant
differences compared to Linux, I'm not sure what testing it on Windows
would give you. JIT is supposed to be entirely transparent, and the
performance characteristics - as well as the bug patterns - are likely to
be quite different on Linux vs. Windows, at least in many cases.
Is it really that important to have?

I'm honestly a bit perplexed by how many people here viewing Windows
support as a must have, while at the same time I think we all agree PHP is
very scarcely found on production Windows servers, and JIT is a
predominantly production feature.

I'm personally interested in taking a look at it (and I'm certain

Anatol does too), but simply dismissing is a no-go for me.

It'd be interesting to evaluate the cost associated with supporting
Windows. Bare in mind, we're proposing to vote on this as a production
feature for PHP 8 - which realistically means almost two years from now at
the earliest. I'm sure we'd have Windows support a lot sooner than that
if we decide that it's a must have. I agree with Nikita that the key
question is in fact, do we or do we not want to introduce JIT in - with the
main question being the maintenance cost. Let's tackle this question
first, otherwise - why send Dmitry (and maybe others) for doing more work
(Windows support) if we are likely to flush it all down the toilet?

Maybe we're the only ones, but we run production PHP on Windows. I have no
issues with the idea of not initially having support for Windows. I can
probably even live with never having support for Windows - provided that we
don't find ourselves in a situation like Nikita mentioned where features
start getting developed in PHP instead of C and require JIT in order to
function.

I think that if we reach the conclusion that Windows support is a must, we
can condition the inclusion of JIT based on having it. Let's first agree
on whether we want it in the first place.

Without my usual Windows bias, I do believe it is a considerable fact
like Nikita pointed out as Windows is a first class citizen in terms
of operating systems we support. While PHP on Windows may not have the
speed that the Unix counterpart have, it is still a very important
development platform. Many developers develop on Windows and deploy on
a Unix based system, being unable to test such an important feature in
a development environment is also a large question mark.

As long as we can agree that very few actually *deploy *on Windows, I
think
we're on solid grounds.
As the JIT implementation is likely to have at least some significant
differences compared to Linux, I'm not sure what testing it on Windows
would give you. JIT is supposed to be entirely transparent, and the
performance characteristics - as well as the bug patterns - are likely to
be quite different on Linux vs. Windows, at least in many cases.
Is it really that important to have?

I'm honestly a bit perplexed by how many people here viewing Windows
support as a must have, while at the same time I think we all agree PHP is
very scarcely found on production Windows servers, and JIT is a
predominantly production feature.

I'm personally interested in taking a look at it (and I'm certain

Anatol does too), but simply dismissing is a no-go for me.

It'd be interesting to evaluate the cost associated with supporting
Windows. Bare in mind, we're proposing to vote on this as a production
feature for PHP 8 - which realistically means almost two years from now at
the earliest. I'm sure we'd have Windows support a lot sooner than that
if we decide that it's a must have. I agree with Nikita that the key
question is in fact, do we or do we not want to introduce JIT in - with
the
main question being the maintenance cost. Let's tackle this question
first, otherwise - why send Dmitry (and maybe others) for doing more work
(Windows support) if we are likely to flush it all down the toilet?

Maybe we're the only ones, but we run production PHP on Windows. I have no
issues with the idea of not initially having support for Windows. I can
probably even live with never having support for Windows - provided that we
don't find ourselves in a situation like Nikita mentioned where features
start getting developed in PHP instead of C and require JIT in order to
function.

Question from a non-compiler-engineer: Could we end up in a situation where
future language features (in 8.3 or something) are only performant on JIT-
enabled platforms? I know there were some RFCs rejected in the past on the
grounds that they involved too many runtime checks (and thus a performance
hit); if it were possible for a JIT to optimize some of those away, it might
make the cost acceptable. However, if a JIT only works on some systems that
might widen the gap between have- and have-not platforms.

Is that a concern, or am I making things up? Or, is it a concern but we're
legit OK with that happening (which is also an entirely valid decision to
make)?

Without my usual Windows bias, I do believe it is a considerable fact
like Nikita pointed out as Windows is a first class citizen in terms
of operating systems we support. While PHP on Windows may not have the
speed that the Unix counterpart have, it is still a very important
development platform. Many developers develop on Windows and deploy on
a Unix based system, being unable to test such an important feature in
a development environment is also a large question mark.

As long as we can agree that very few actually *deploy *on Windows, I
think
we're on solid grounds.
As the JIT implementation is likely to have at least some significant
differences compared to Linux, I'm not sure what testing it on Windows
would give you. JIT is supposed to be entirely transparent, and the
performance characteristics - as well as the bug patterns - are likely to
be quite different on Linux vs. Windows, at least in many cases.
Is it really that important to have?

I'm honestly a bit perplexed by how many people here viewing Windows
support as a must have, while at the same time I think we all agree PHP is
very scarcely found on production Windows servers, and JIT is a
predominantly production feature.

I'm personally interested in taking a look at it (and I'm certain

Anatol does too), but simply dismissing is a no-go for me.

It'd be interesting to evaluate the cost associated with supporting
Windows. Bare in mind, we're proposing to vote on this as a production
feature for PHP 8 - which realistically means almost two years from now at
the earliest. I'm sure we'd have Windows support a lot sooner than that
if we decide that it's a must have. I agree with Nikita that the key
question is in fact, do we or do we not want to introduce JIT in - with
the
main question being the maintenance cost. Let's tackle this question
first, otherwise - why send Dmitry (and maybe others) for doing more work
(Windows support) if we are likely to flush it all down the toilet?

Maybe we're the only ones, but we run production PHP on Windows. I have no
issues with the idea of not initially having support for Windows. I can
probably even live with never having support for Windows - provided that we
don't find ourselves in a situation like Nikita mentioned where features
start getting developed in PHP instead of C and require JIT in order to
function.

Question from a non-compiler-engineer: Could we end up in a situation where
future language features (in 8.3 or something) are only performant on JIT-
enabled platforms? I know there were some RFCs rejected in the past on the
grounds that they involved too many runtime checks (and thus a performance
hit); if it were possible for a JIT to optimize some of those away, it might
make the cost acceptable. However, if a JIT only works on some systems that
might widen the gap between have- and have-not platforms.

I think, JIT only approach doesn't make a lot of sense for PHP, with one
of the most fast VM. And this is a trend. Even V8, starting from JIT
only, switched back to VM+JIT.

Thanks. Dmitry.

Is that a concern, or am I making things up? Or, is it a concern but we're
legit OK with that happening (which is also an entirely valid decision to
make)?

This is marvellous stuff, truly brilliant. I particularly appreciate the
non-intrusive approach of setting jit'd code as the opcode handler, this
makes life a little easier for hacky extension authors, I think.

As others have said:

I don't like the idea of omitting to support windows, less worried about
fancy architectures.
I'm not keen on the idea that there is no way to debug the code this
generates outside of GDB, and I'm not sure how useful gdb will be: I've
tried to debug JIT'd code in that before and it doesn't do so well, but I
could easily have been doing it wrong. I'd be very happy to be corrected
about this ?
I'm not keen on the idea of merging this into 7.4, for various reasons
that don't need to be repeated.

Without my usual Windows bias, I do believe it is a considerable fact
like Nikita pointed out as Windows is a first class citizen in terms
of operating systems we support. While PHP on Windows may not have the
speed that the Unix counterpart have, it is still a very important
development platform. Many developers develop on Windows and deploy on
a Unix based system, being unable to test such an important feature in
a development environment is also a large question mark.

As long as we can agree that very few actually *deploy *on Windows, I
think
we're on solid grounds.
As the JIT implementation is likely to have at least some significant
differences compared to Linux, I'm not sure what testing it on Windows
would give you. JIT is supposed to be entirely transparent, and the
performance characteristics - as well as the bug patterns - are likely
to
be quite different on Linux vs. Windows, at least in many cases.
Is it really that important to have?

I'm honestly a bit perplexed by how many people here viewing Windows
support as a must have, while at the same time I think we all agree
PHP is
very scarcely found on production Windows servers, and JIT is a
predominantly production feature.

I'm personally interested in taking a look at it (and I'm certain

Anatol does too), but simply dismissing is a no-go for me.

It'd be interesting to evaluate the cost associated with supporting
Windows. Bare in mind, we're proposing to vote on this as a production
feature for PHP 8 - which realistically means almost two years from now at
the earliest. I'm sure we'd have Windows support a lot sooner than
that
if we decide that it's a must have. I agree with Nikita that the key
question is in fact, do we or do we not want to introduce JIT in - with
the
main question being the maintenance cost. Let's tackle this question
first, otherwise - why send Dmitry (and maybe others) for doing more
work
(Windows support) if we are likely to flush it all down the toilet?

Maybe we're the only ones, but we run production PHP on Windows. I have
no
issues with the idea of not initially having support for Windows. I can
probably even live with never having support for Windows - provided
that we
don't find ourselves in a situation like Nikita mentioned where features
start getting developed in PHP instead of C and require JIT in order to
function.

Question from a non-compiler-engineer: Could we end up in a situation
where
future language features (in 8.3 or something) are only performant on
JIT-
enabled platforms? I know there were some RFCs rejected in the past on
the
grounds that they involved too many runtime checks (and thus a
performance
hit); if it were possible for a JIT to optimize some of those away, it
might
make the cost acceptable. However, if a JIT only works on some systems
that
might widen the gap between have- and have-not platforms.

I think, JIT only approach doesn't make a lot of sense for PHP, with one
of the most fast VM. And this is a trend. Even V8, starting from JIT
only, switched back to VM+JIT.

Thanks. Dmitry.

Is that a concern, or am I making things up? Or, is it a concern but
we're
legit OK with that happening (which is also an entirely valid decision to
make)?

This is marvellous stuff, truly brilliant. I particularly appreciate the
non-intrusive approach of setting jit'd code as the opcode handler, this
makes life a little easier for hacky extension authors, I think.

As others have said:

I don't like the idea of omitting to support windows, less worried
about fancy architectures.

I can provide help to people who will going to implement JIT support for
Windows. This is not going to be easy, because MSVC doesn't support
"hybrid VM" and "global register variables", therefore the code is going
to be more expensive.

I'm not keen on the idea that there is no way to debug the code this
generates outside of GDB, and I'm not sure how useful gdb will be: I've
tried to debug JIT'd code in that before and it doesn't do so well, but
I could easily have been doing it wrong. I'd be very happy to be
corrected about this ?

I'm not sure, what is wrong with GDB, and if any other debuggers have
special API for run-time generated code.

I'm not keen on the idea of merging this into 7.4, for various
reasons that don't need to be repeated.

OK. It's not only your opinion.
You may vote against, and persuade others.

>
>> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski <[email protected]
<mailto:[email protected]>> wrote:
>>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen
<[email protected] <mailto:[email protected]>>
>>>
>>> wrote:
>>>> Without my usual Windows bias, I do believe it is a
considerable fact
>>>> like Nikita pointed out as Windows is a first class citizen in
terms
>>>> of operating systems we support. While PHP on Windows may not
have the
>>>> speed that the Unix counterpart have, it is still a very important
>>>> development platform. Many developers develop on Windows and
deploy on
>>>> a Unix based system, being unable to test such an important
feature in
>>>> a development environment is also a large question mark.
>>>
>>> As long as we can agree that very few actually *deploy *on
Windows, I
>>> think
>>> we're on solid grounds.
>>> As the JIT implementation is likely to have at least *some*
significant
>>> differences compared to Linux, I'm not sure what testing it on
Windows
>>> would give you. JIT is supposed to be entirely transparent,
and the
>>> performance characteristics - as well as the bug patterns - are
likely to
>>> be quite different on Linux vs. Windows, at least in many cases.
>>> Is it really that important to have?
>>>
>>> I'm honestly a bit perplexed by how many people here viewing
Windows
>>> support as a must have, while at the same time I think we all
agree PHP is
>>> very scarcely found on production Windows servers, and JIT is a
>>> predominantly production feature.
>>>
>>> I'm personally interested in taking a look at it (and I'm certain
>>>
>>>> Anatol does too), but simply dismissing is a no-go for me.
>>>
>>> It'd be interesting to evaluate the cost associated with supporting
>>> Windows. Bare in mind, we're proposing to vote on this as a
production
>>> feature for PHP 8 - which realistically means almost two years
from now
>>> *at
>>> the earliest*. I'm sure we'd have Windows support a lot sooner
than that
>>> if we decide that it's a must have. I agree with Nikita that
the key
>>> question is in fact, do we or do we not want to introduce JIT
in - with
>>> the
>>> main question being the maintenance cost. Let's tackle this
question
>>> first, otherwise - why send Dmitry (and maybe others) for doing
more work
>>> (Windows support) if we are likely to flush it all down the toilet?
>>>
>> Maybe we're the only ones, but we run production PHP on Windows.
I have no
>> issues with the idea of not initially having support for
Windows. I can
>> probably even live with never having support for Windows -
provided that we
>> don't find ourselves in a situation like Nikita mentioned where
features
>> start getting developed in PHP instead of C and require JIT in
order to
>> function.
>
> Question from a non-compiler-engineer: Could we end up in a
situation where
> future language features (in 8.3 or something) are only
performant on JIT-
> enabled platforms? I know there were some RFCs rejected in the
past on the
> grounds that they involved too many runtime checks (and thus a
performance
> hit); if it were possible for a JIT to optimize some of those
away, it might
> make the cost acceptable. However, if a JIT only works on some
systems that
> might widen the gap between have- and have-not platforms.
I think, JIT only approach doesn't make a lot of sense for PHP, with
one
of the most fast VM. And this is a trend. Even V8, starting from JIT
only, switched back to VM+JIT.
Thanks. Dmitry.
>
> Is that a concern, or am I making things up? Or, is it a concern
but we're
> legit OK with that happening (which is also an entirely valid
decision to
> make)?
>
> --Larry Garfield

This is marvellous stuff, truly brilliant. I particularly appreciate the
non-intrusive approach of setting jit'd code as the opcode handler, this
makes life a little easier for hacky extension authors, I think.

As others have said:

I don't like the idea of omitting to support windows, less worried
about fancy architectures.

I can provide help to people who will going to implement JIT support for
Windows. This is not going to be easy, because MSVC doesn't support
"hybrid VM" and "global register variables", therefore the code is going
to be more expensive.

I think an important point here is that this issue affects not only
Windows: It also affects any platform that uses clang as their compiler.
Notably this includes MacOS.

Clang theoretically supports global registers, but only for non-allocatable
regs (rsp and rbp), which I think is not very useful for this purpose.

So this problem needs to be solved not just for Windows support, but also
for MacOS support (and also FreeBSD and other clang-using platforms).

Nikita

I'm not keen on the idea that there is no way to debug the code this
generates outside of GDB, and I'm not sure how useful gdb will be: I've
tried to debug JIT'd code in that before and it doesn't do so well, but
I could easily have been doing it wrong. I'd be very happy to be
corrected about this ?

I'm not sure, what is wrong with GDB, and if any other debuggers have
special API for run-time generated code.

I'm not keen on the idea of merging this into 7.4, for various
reasons that don't need to be repeated.

OK. It's not only your opinion.
You may vote against, and persuade others.

>
>> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski <[email protected]
<mailto:[email protected]>> wrote:
>>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen
<[email protected] <mailto:[email protected]>>
>>>
>>> wrote:
>>>> Without my usual Windows bias, I do believe it is a
considerable fact
>>>> like Nikita pointed out as Windows is a first class citizen in
terms
>>>> of operating systems we support. While PHP on Windows may not
have the
>>>> speed that the Unix counterpart have, it is still a very

important

>>>> development platform. Many developers develop on Windows and
deploy on
>>>> a Unix based system, being unable to test such an important
feature in
>>>> a development environment is also a large question mark.
>>>
>>> As long as we can agree that very few actually *deploy *on
Windows, I
>>> think
>>> we're on solid grounds.
>>> As the JIT implementation is likely to have at least *some*
significant
>>> differences compared to Linux, I'm not sure what testing it on
Windows
>>> would give you. JIT is supposed to be entirely transparent,
and the
>>> performance characteristics - as well as the bug patterns - are
likely to
>>> be quite different on Linux vs. Windows, at least in many cases.
>>> Is it really that important to have?
>>>
>>> I'm honestly a bit perplexed by how many people here viewing
Windows
>>> support as a must have, while at the same time I think we all
agree PHP is
>>> very scarcely found on production Windows servers, and JIT is a
>>> predominantly production feature.
>>>
>>> I'm personally interested in taking a look at it (and I'm

certain

>>>
>>>> Anatol does too), but simply dismissing is a no-go for me.
>>>
>>> It'd be interesting to evaluate the cost associated with

supporting

>>> Windows. Bare in mind, we're proposing to vote on this as a
production
>>> feature for PHP 8 - which realistically means almost two years
from now
>>> *at
>>> the earliest*. I'm sure we'd have Windows support a lot sooner
than that
>>> if we decide that it's a must have. I agree with Nikita that
the key
>>> question is in fact, do we or do we not want to introduce JIT
in - with
>>> the
>>> main question being the maintenance cost. Let's tackle this
question
>>> first, otherwise - why send Dmitry (and maybe others) for doing
more work
>>> (Windows support) if we are likely to flush it all down the

toilet?

>>>
>> Maybe we're the only ones, but we run production PHP on Windows.
I have no
>> issues with the idea of not initially having support for
Windows. I can
>> probably even live with never having support for Windows -
provided that we
>> don't find ourselves in a situation like Nikita mentioned where
features
>> start getting developed in PHP instead of C and require JIT in
order to
>> function.
>
> Question from a non-compiler-engineer: Could we end up in a
situation where
> future language features (in 8.3 or something) are only
performant on JIT-
> enabled platforms? I know there were some RFCs rejected in the
past on the
> grounds that they involved too many runtime checks (and thus a
performance
> hit); if it were possible for a JIT to optimize some of those
away, it might
> make the cost acceptable. However, if a JIT only works on some
systems that
> might widen the gap between have- and have-not platforms.
I think, JIT only approach doesn't make a lot of sense for PHP, with
one
of the most fast VM. And this is a trend. Even V8, starting from JIT
only, switched back to VM+JIT.
Thanks. Dmitry.
>
> Is that a concern, or am I making things up? Or, is it a concern
but we're
> legit OK with that happening (which is also an entirely valid
decision to
> make)?
>
> --Larry Garfield

> Morning Dmitry, and internals,
>
> This is marvellous stuff, truly brilliant. I particularly
appreciate the
> non-intrusive approach of setting jit'd code as the opcode
handler, this
> makes life a little easier for hacky extension authors, I think.
>
> As others have said:
>
> I don't like the idea of omitting to support windows, less
worried
> about fancy architectures.
I can provide help to people who will going to implement JIT support
for
Windows. This is not going to be easy, because MSVC doesn't support
"hybrid VM" and "global register variables", therefore the code is
going
to be more expensive.

I think an important point here is that this issue affects not only
Windows: It also affects any platform that uses clang as their compiler.
Notably this includes MacOS.

Clang theoretically supports global registers, but only for
non-allocatable regs (rsp and rbp), which I think is not very useful for
this purpose.

We will have to provide a patch for CLANG, implementing PHP VM calling
convention (HHVM, Erlang, Haskel did this).

Thanks. Dmitry.

So this problem needs to be solved not just for Windows support, but
also for MacOS support (and also FreeBSD and other clang-using platforms).

Nikita

> I'm not keen on the idea that there is no way to debug the
code this
> generates outside of GDB, and I'm not sure how useful gdb will
be: I've
> tried to debug JIT'd code in that before and it doesn't do so
well, but
> I could easily have been doing it wrong. I'd be very happy to be
> corrected about this ?
I'm not sure, what is wrong with GDB, and if any other debuggers have
special API for run-time generated code.
> I'm not keen on the idea of merging this into 7.4, for various
> reasons that don't need to be repeated.
OK. It's not only your opinion.
You may vote against, and persuade others.
Thanks. Dmitry.
>
> Bottom line though, I love it, it's brilliant, and look forward
to PHP 8.
>
> Thank you, Dmitry.
>
> Cheers
> Joe
>
>
> On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>
>
>
> On 2/1/19 3:29 AM, Larry Garfield wrote:
> > On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler
wrote:
> >> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
> >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen
> <[email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> >>>
> >>> wrote:
> >>>> Without my usual Windows bias, I do believe it is a
> considerable fact
> >>>> like Nikita pointed out as Windows is a first class
citizen in
> terms
> >>>> of operating systems we support. While PHP on Windows
may not
> have the
> >>>> speed that the Unix counterpart have, it is still a
very important
> >>>> development platform. Many developers develop on
Windows and
> deploy on
> >>>> a Unix based system, being unable to test such an important
> feature in
> >>>> a development environment is also a large question mark.
> >>>
> >>> As long as we can agree that very few actually *deploy *on
> Windows, I
> >>> think
> >>> we're on solid grounds.
> >>> As the JIT implementation is likely to have at least *some*
> significant
> >>> differences compared to Linux, I'm not sure what testing
it on
> Windows
> >>> would give you. JIT is supposed to be entirely transparent,
> and the
> >>> performance characteristics - as well as the bug
patterns - are
> likely to
> >>> be quite different on Linux vs. Windows, at least in
many cases.
> >>> Is it really that important to have?
> >>>
> >>> I'm honestly a bit perplexed by how many people here viewing
> Windows
> >>> support as a must have, while at the same time I think
we all
> agree PHP is
> >>> very scarcely found on production Windows servers, and
JIT is a
> >>> predominantly production feature.
> >>>
> >>> I'm personally interested in taking a look at it (and
I'm certain
> >>>
> >>>> Anatol does too), but simply dismissing is a no-go for me.
> >>>
> >>> It'd be interesting to evaluate the cost associated with
supporting
> >>> Windows. Bare in mind, we're proposing to vote on this as a
> production
> >>> feature for PHP 8 - which realistically means almost two
years
> from now
> >>> *at
> >>> the earliest*. I'm sure we'd have Windows support a lot
sooner
> than that
> >>> if we decide that it's a must have. I agree with Nikita
that
> the key
> >>> question is in fact, do we or do we not want to
introduce JIT
> in - with
> >>> the
> >>> main question being the maintenance cost. Let's tackle this
> question
> >>> first, otherwise - why send Dmitry (and maybe others)
for doing
> more work
> >>> (Windows support) if we are likely to flush it all down
the toilet?
> >>>
> >> Maybe we're the only ones, but we run production PHP on
Windows.
> I have no
> >> issues with the idea of not initially having support for
> Windows. I can
> >> probably even live with never having support for Windows -
> provided that we
> >> don't find ourselves in a situation like Nikita mentioned
where
> features
> >> start getting developed in PHP instead of C and require
JIT in
> order to
> >> function.
> >
> > Question from a non-compiler-engineer: Could we end up in a
> situation where
> > future language features (in 8.3 or something) are only
> performant on JIT-
> > enabled platforms? I know there were some RFCs rejected
in the
> past on the
> > grounds that they involved too many runtime checks (and thus a
> performance
> > hit); if it were possible for a JIT to optimize some of those
> away, it might
> > make the cost acceptable. However, if a JIT only works on
some
> systems that
> > might widen the gap between have- and have-not platforms.
>
> I think, JIT only approach doesn't make a lot of sense for
PHP, with
> one
> of the most fast VM. And this is a trend. Even V8, starting
from JIT
> only, switched back to VM+JIT.
>
> Thanks. Dmitry.
>
> >
> > Is that a concern, or am I making things up? Or, is it a
concern
> but we're
> > legit OK with that happening (which is also an entirely valid
> decision to
> > make)?
> >
> > --Larry Garfield
> >
>
> --
>
>

I'm not keen on the idea of merging this into 7.4, for various
reasons that don't need to be repeated.

OK. It's not only your opinion.
You may vote against, and persuade others.

I think it would be interesting to clarify the intended audience for an
experimental JIT in 7.4. Presumably, it would be marked as not suitable for
production, so would only be of interest to those experimenting with the
feature; but any problems they find might already be fixed in master, so
would it be better to encourage them to download a snapshot build of
8.0-pre-alpha and test there?

Regards,

Question from a non-compiler-engineer: Could we end up in a situation
where
future language features (in 8.3 or something) are only performant on JIT-
enabled platforms? I know there were some RFCs rejected in the past on
the
grounds that they involved too many runtime checks (and thus a performance
hit); if it were possible for a JIT to optimize some of those away, it
might make the cost acceptable. However, if a JIT only works on some
systems that might widen the gap between have- and have-not platforms.

I think, JIT only approach doesn't make a lot of sense for PHP, with one
of the most fast VM. And this is a trend. Even V8, starting from JIT
only, switched back to VM+JIT.

Thanks. Dmitry.

I'm... not sure how that answers my question? I'm saying "if we had a VM+JIT,
and the JIT part made feature X acceptably fast but it wasn't acceptably fast
with just the VM, is that a problem?" Or is that a situation that cannot
happen? Or that we don't care if it happens?

I'm... not sure how that answers my question? I'm saying "if we had a VM+JIT,
and the JIT part made feature X acceptably fast but it wasn't acceptably fast
with just the VM, is that a problem?" Or is that a situation that cannot
happen? Or that we don't care if it happens?

Technically, you're absolutely right that this may happen. For instance, if we decide to implement certain features in userland, factoring in the fact that JIT makes it fast enough - but without JIT it would be prohibitively slow - this could be a problem. I do think that if we’d want to go in this direction, our platform support would likely have to be wider than it currently is. But there are still two things that mitigate this issue to a large degree:

Our VM is super quick, by far the quickest non-JITted dynamic language (to the best of our knowledge). So VM would be slower, but depending on the specific use case - probably not dead slow.

Most PHP production workloads are on Linux, and as far as I can tell this trend is only growing over the years - with virtual machines and now containers becoming more and more popular - meaning that even developers with other host OSs still use Linux for the actual PHP development.

That said, again, we should probably evaluate it thoroughly before we come to rely on JIT for any must-have functionality.

Most PHP production workloads are on Linux, and as far as I can tell
this trend is only growing over the years - with virtual machines and
now containers becoming more and more popular - meaning that even
developers with other host OSs still use Linux for the actual PHP
development.

I am not sure this really is the case. Depending on which statistics you
believe te be true, about a quarter to a third of the Web is powered by
Wordpress. Wordpress market share is not diminishing.

Do not underestimate the huge amount of Wordpress plugin developers that
develop on Windows. Code quality is varying from very low to quite high,
but these people are PHP developers as well.

Question from a non-compiler-engineer: Could we end up in a situation
where
future language features (in 8.3 or something) are only performant on JIT-
enabled platforms? I know there were some RFCs rejected in the past on
the
grounds that they involved too many runtime checks (and thus a performance
hit); if it were possible for a JIT to optimize some of those away, it
might make the cost acceptable. However, if a JIT only works on some
systems that might widen the gap between have- and have-not platforms.

I think, JIT only approach doesn't make a lot of sense for PHP, with one
of the most fast VM. And this is a trend. Even V8, starting from JIT
only, switched back to VM+JIT.

Thanks. Dmitry.

I'm... not sure how that answers my question? I'm saying "if we had a VM+JIT,
and the JIT part made feature X acceptably fast but it wasn't acceptably fast
with just the VM, is that a problem?" Or is that a situation that cannot
happen? Or that we don't care if it happens?

Everything is possible, but I don't think very realistic now.
When some features are going to depend on JIT, we might have much better
JIT then now.

As long as we can agree that very few actually deploy on Windows, I think we're on solid grounds.
As the JIT implementation is likely to have at least some significant differences compared to Linux, I'm not sure what testing it on Windows would give you. JIT is supposed to be entirely transparent, and the performance characteristics - as well as the bug patterns - are likely to be quite different on Linux vs. Windows, at least in many cases.
Is it really that important to have?

I think we can easily agree on the fact that by no means Windows is
the top candidate for production. For me personally from a project
standpoint, I believe it is something important that we can have a PHP
that is pretty much as transparent and identical no matter what
platform you are on, which is something I have tried to do myself by
implementing various Linux routines for Windows natively to make PHP
as platform independent as possible.

I'm honestly a bit perplexed by how many people here viewing Windows support as a must have, while at the same time I think we all agree PHP is very scarcely found on production Windows servers, and JIT is a predominantly production feature.

With above being said, then I do also agree with you here, but I would
like to have such functionality and improvements to our core system be
as global as possible, naturally I don't think its fair either to
require it so desperately upfront, but it should be a heavy
consideration with the amount of work that we all have put into making
Windows support one of the best among programming languages of similar
category.

It'd be interesting to evaluate the cost associated with supporting Windows. Bare in mind, we're proposing to vote on this as a production feature for PHP 8 - which realistically means almost two years from now at the earliest. I'm sure we'd have Windows support a lot sooner than that if we decide that it's a must have. I agree with Nikita that the key question is in fact, do we or do we not want to introduce JIT in - with the main question being the maintenance cost. Let's tackle this question first, otherwise - why send Dmitry (and maybe others) for doing more work (Windows support) if we are likely to flush it all down the toilet?

I don't think it would be fair either to simply dismiss the idea and
many years of hard work for a detail like platform support either, and
that is not the way I hope anyone would cast their vote.

I think that if we reach the conclusion that Windows support is a must, we can condition the inclusion of JIT based on having it. Let's first agree on whether we want it in the first place.

Agreed. Naturally I would contribute in what I can to work on those
parts (Windows).

I'm honestly a bit perplexed by how many people here viewing Windows
support as a must have, while at the same time I think we all agree PHP is
very scarcely found on production Windows servers, and JIT is a
predominantly production feature.

While this is anecdotal, I think you might find a different perspective from user group organizers. I've encountered many user group members over the years who run PHP on Windows. It's more common that they develop on Windows and deploy to Linux, but I do know those who also deploy to Windows in production.

That's not to say I personally think that Windows support is a must-have for JIT, but it's definitely important for many of the people in the user groups I've worked with.

Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where we
are going to continue active improvement, and into PHP-7.4, as an
experimental feature.
Thanks. Dmitry.

This has been a long time on the horizon, nice to see this finally
moving forward :)

Here are some initial thoughts: I think that it's best to approach this
issue from a cost/benefit angle. The benefits of the JIT compiler are
roughly (and as already outlined in the RFC):

Significantly better performance for numerical code.

Slightly better performance for "typical" PHP web application code.

The potential to move more code from C to PHP, because PHP will now
be sufficiently fast.

However, there are also a number of costs, on which I'll expand in more
detail:

a) Maintenance: This is really my main concern. Right now there are
about 3-4 people who I would trust to carry out a non-trivial language
change, which will require touching the compiler, the virtual machine,
the optimizer and the persistence layer. Each of those components is
quite complex, in different ways. Some people who are comfortable with
doing VM changes will struggle with implementing optimizer changes.

Adding a JIT compiler exacerbates this issue further. Because this JIT
is dynasm based, the core JIT code is essentially written in raw x86
assembly. This will further limit the pool of people who will be able to
make non-trivial engine changes. Personally, I don't have any particular
familiarity with writing x86 assembly, so it will likely take a while to
get up to speed with this code.

b) Bugs and stability: I think that everyone is aware that the initial
PHP 7.3 release suffered from substantial stability issues, more than
new minor version releases tend to do. I think there are multiple
reasons for that (and we might want to start a conversation about our QA
processes in a separate thread), but one main contributing factor were
opcache optimizer bugs. Compiler optimizations are tricky and hard to
verify, and we often only learn about issues once the optimizer makes
contact with production codebases, which feature a much richer
collection of code patterns than our test suite. One can wonder whether
the relatively minor speedups we get from our optimization framework are
really worth having these stability issues...

Adding a JIT compiler adds a new dimension of stability issues. Next to
"simple" executor bugs, and optimizer bugs, we now get additional bugs
in the JIT. These are probably going to be hard to debug, as we'll have
to drop down from our usual C-level tooling, down to inspecting assembly.

c) Platform support: Having a JIT segregates platforms into two tiers:
Those that have JIT support and those that don't. While that is not a
problem per se, it does introduce some dangers. For example, if we
decide to more parts of our C code into PHP because PHP is fast enough
with a JIT, that will of course only be true for platforms that actually
have JIT support. I'm not terribly concerned about loosing out some
performance on MIPS, but we do need to make sure that all our main
platforms are supported (Windows is a must there, imho).

I don't see any problems with including JIT without Windows support.
Windows runs PHP much slower any way.

Without my usual Windows bias, I do believe it is a considerable fact
like Nikita pointed out as Windows is a first class citizen in terms
of operating systems we support. While PHP on Windows may not have the
speed that the Unix counterpart have, it is still a very important
development platform. Many developers develop on Windows and deploy on
a Unix based system, being unable to test such an important feature in
a development environment is also a large question mark.

in the age of CI systems it doesn't matter much what your primary local
development platform is, even if it is different than the targeted
platform. One creates a PR, pushes, CI triggers, checks validity, could
be performance tested, and that's the real environment.
And not to mention containers for local development when the code is
actually run in a Linux container, no matter whether running on Win,
Linux or Mac.

I'm personally interested in taking a look at it (and I'm certain
Anatol does too), but simply dismissing is a no-go for me.

Also while I use php on windows less, I still see a large amount of
companies using php on windows, in similar ways than on Linux.

Nikita concerns are valid, PHP is and should remain a cross platform
language. And some top OSes besides linux should remain a target. Easier
said than done and willing to help at least for windows. I am sure msft
teams will step in as well.

Also while I use php on windows less, I still see a large amount of
companies using php on windows, in similar ways than on Linux.

Nikita concerns are valid, PHP is and should remain a cross platform
language. And some top OSes besides linux should remain a target. Easier
said than done and willing to help at least for windows. I am sure msft
teams will step in as well.

considering how open is Microsoft to open source nowadays it is probably
a no brainer to have them help. They might only need some hinting :)

More or less right. PHP uses GCC extensions, that are not available in MSVC.

Also while I use php on windows less, I still see a large amount of
companies using php on windows, in similar ways than on Linux.

Nikita concerns are valid, PHP is and should remain a cross platform
language. And some top OSes besides linux should remain a target. Easier
said than done and willing to help at least for windows. I am sure msft
teams will step in as well.

It would be great, if MSFT team helps.
I definitely, can't move JIT forward, and provide support for all
platforms at the same time.

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an experimental
feature.

Thanks. Dmitry.

This has been a long time on the horizon, nice to see this finally moving
forward :)

Here are some initial thoughts: I think that it's best to approach this
issue from a cost/benefit angle. The benefits of the JIT compiler are
roughly (and as already outlined in the RFC):

Significantly better performance for numerical code.

Slightly better performance for "typical" PHP web application code.

The potential to move more code from C to PHP, because PHP will now be
sufficiently fast.

However, there are also a number of costs, on which I'll expand in more
detail:

a) Maintenance: This is really my main concern. Right now there are about
3-4 people who I would trust to carry out a non-trivial language change,
which will require touching the compiler, the virtual machine, the
optimizer and the persistence layer. Each of those components is quite
complex, in different ways. Some people who are comfortable with doing VM
changes will struggle with implementing optimizer changes.

Adding a JIT compiler exacerbates this issue further. Because this JIT is
dynasm based, the core JIT code is essentially written in raw x86 assembly.
This will further limit the pool of people who will be able to make
non-trivial engine changes. Personally, I don't have any particular
familiarity with writing x86 assembly, so it will likely take a while to
get up to speed with this code.

b) Bugs and stability: I think that everyone is aware that the initial PHP
7.3 release suffered from substantial stability issues, more than new minor
version releases tend to do. I think there are multiple reasons for that
(and we might want to start a conversation about our QA processes in a
separate thread), but one main contributing factor were opcache optimizer
bugs. Compiler optimizations are tricky and hard to verify, and we often
only learn about issues once the optimizer makes contact with production
codebases, which feature a much richer collection of code patterns than our
test suite. One can wonder whether the relatively minor speedups we get
from our optimization framework are really worth having these stability
issues...

Adding a JIT compiler adds a new dimension of stability issues. Next to
"simple" executor bugs, and optimizer bugs, we now get additional bugs in
the JIT. These are probably going to be hard to debug, as we'll have to
drop down from our usual C-level tooling, down to inspecting assembly.

c) Platform support: Having a JIT segregates platforms into two tiers:
Those that have JIT support and those that don't. While that is not a
problem per se, it does introduce some dangers. For example, if we decide
to more parts of our C code into PHP because PHP is fast enough with a JIT,
that will of course only be true for platforms that actually have JIT
support. I'm not terribly concerned about loosing out some performance on
MIPS, but we do need to make sure that all our main platforms are supported
(Windows is a must there, imho).

d) Debugging: I'm not sure whether or not this is an issue (maybe the RFC
can clarify?), but I'm wondering if this will have an impact on things like
XDebug. Will it be possible to using XDebug to accurately inspect variables
at any point in time while the JIT is running? If not, that would be a big
tooling regression.

I think those are the main points that come to mind right now...

Regards,
Nikita

I strongly with Nikita's points on cost/benefit analysis. I have
written a lot but thrown it away because I think this point is so
important:

It appears that the JIT does not work on Clang or MSVC compilers. As
such, I consider this dead on arrival, even if it's considered
experimental. There are cross-platform JIT's out there -- how do they
manage it? I think that's the next critical step.

I tried to debug this. Unfortunately my gdb doesn't seem to work with JIT:
It hangs when the script starts running, on line Zend/zend_gdb.c:84 in
zend_gdb_register_code. I don't know if that's a bug or I need to do
something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
8.1.0.20180409-git).

I tried to debug this. Unfortunately my gdb doesn't seem to work with JIT:
It hangs when the script starts running, on line Zend/zend_gdb.c:84 in
zend_gdb_register_code. I don't know if that's a bug or I need to do
something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
8.1.0.20180409-git).

Nikita

Another project that I would like to test is amp
([email protected]:amphp/amp.git).
Here I am getting a segfault only on shutdown, after tests finished
running. However there are a number of test failures, all basically looking
the same:

Amp\Test\AllTest::testPendingPromiseArray
TypeError: Return value of Amp\Loop\Internal\TimerQueue::removeAndRebuild()
must be an instance of Amp\Loop\Internal\TimerQueueEntry, null returned

Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where we
are going to continue active improvement, and into PHP-7.4, as an
experimental feature.
Thanks. Dmitry.

I would like to check if the JIT provides an improvement for PHP-Parser.
Unfortunately I'm getting a segfault when running the tests. Should be
reproducible with

I tried to debug this. Unfortunately my gdb doesn't seem to work with
JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84
in zend_gdb_register_code. I don't know if that's a bug or I need to do
something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
8.1.0.20180409-git).

GDB takes enormous time registering too many JIT-ed functions...
It should be possible to catch the name of problematic functions and the
JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but
most probably, only on next week.

Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where we
are going to continue active improvement, and into PHP-7.4, as an
experimental feature.
Thanks. Dmitry.

I would like to check if the JIT provides an improvement for PHP-Parser.
Unfortunately I'm getting a segfault when running the tests. Should be
reproducible with

I tried to debug this. Unfortunately my gdb doesn't seem to work with
JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84
in zend_gdb_register_code. I don't know if that's a bug or I need to do
something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
8.1.0.20180409-git).

GDB takes enormous time registering too many JIT-ed functions...
It should be possible to catch the name of problematic functions and the
JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but
most probably, only on next week.

I fixed the problem caused JIT to fail on PHP-Parser tests (it was
related to changes introduced by typed properties patch).

Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where we
are going to continue active improvement, and into PHP-7.4, as an
experimental feature.
Thanks. Dmitry.

I would like to check if the JIT provides an improvement for PHP-Parser.
Unfortunately I'm getting a segfault when running the tests. Should be
reproducible with

I tried to debug this. Unfortunately my gdb doesn't seem to work with
JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84
in zend_gdb_register_code. I don't know if that's a bug or I need to do
something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
8.1.0.20180409-git).

GDB takes enormous time registering too many JIT-ed functions...
It should be possible to catch the name of problematic functions and the
JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but
most probably, only on next week.

I fixed the problem caused JIT to fail on PHP-Parser tests (it was
related to changes introduced by typed properties patch).

I'm also going to disable automatic JIT code registration in GDB.

Thanks. Dmitry.

Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x
speedup with default JIT configuration. That's promising :)

Next I want to try https://github.com/amphp/hpack (part of HTTP 2
implementation), where I also expect good results. Currently there is a
segfault while running tests.

>
>
>
>> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <[email protected]
<mailto:[email protected]>
>> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>>
>> Hi Internals,
>>
>>
>> I'm glad to finally propose including JIT into PHP.
>>
>>
>> https://wiki.php.net/rfc/jit
>>
>>
>> In the current state it may be included both into PHP-8,
where we
>> are going to continue active improvement, and into PHP-7.4,
as an
>> experimental feature.
>>
>>
>> Thanks. Dmitry.
>>
>>
>> I would like to check if the JIT provides an improvement for
PHP-Parser.
>> Unfortunately I'm getting a segfault when running the tests.
Should be
>> reproducible with
>>
>> git clone [email protected]:nikic/PHP-Parser.git
>> cd PHP-Parser
>> composer install
>> php-jit vendor/bin/phpunit
>>
>> I tried to debug this. Unfortunately my gdb doesn't seem to work
with
>> JIT: It hangs when the script starts running, on line
Zend/zend_gdb.c:84
>> in zend_gdb_register_code. I don't know if that's a bug or I
need to do
>> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
>> 8.1.0.20180409-git).
>
> GDB takes enormous time registering too many JIT-ed functions...
> It should be possible to catch the name of problematic functions
and the
> JIT only them (using PHPDOC trigger). I'll try to analyze the
crash, but
> most probably, only on next week.
I fixed the problem caused JIT to fail on PHP-Parser tests (it was
related to changes introduced by typed properties patch).
I'm also going to disable automatic JIT code registration in GDB.
Thanks. Dmitry.

Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x
speedup with default JIT configuration. That's promising :)

Next I want to try https://github.com/amphp/hpack (part of HTTP 2
implementation), where I also expect good results. Currently there is a
segfault while running tests.

Could you provide a quick instruction, how to reproduce this (in the
same way like with PHP-Parser).

>
>
>
>> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <[email protected]
<mailto:[email protected]>
>> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>>
>> Hi Internals,
>>
>>
>> I'm glad to finally propose including JIT into PHP.
>>
>>
>> https://wiki.php.net/rfc/jit
>>
>>
>> In the current state it may be included both into PHP-8,
where we
>> are going to continue active improvement, and into PHP-7.4,
as an
>> experimental feature.
>>
>>
>> Thanks. Dmitry.
>>
>>
>> I would like to check if the JIT provides an improvement for
PHP-Parser.
>> Unfortunately I'm getting a segfault when running the tests.
Should be
>> reproducible with
>>
>> git clone [email protected]:nikic/PHP-Parser.git
>> cd PHP-Parser
>> composer install
>> php-jit vendor/bin/phpunit
>>
>> I tried to debug this. Unfortunately my gdb doesn't seem to work
with
>> JIT: It hangs when the script starts running, on line
Zend/zend_gdb.c:84
>> in zend_gdb_register_code. I don't know if that's a bug or I
need to do
>> something additional here (I'm using GNU gdb (Ubuntu

8.1-0ubuntu3)

>> 8.1.0.20180409-git).
>
> GDB takes enormous time registering too many JIT-ed functions...
> It should be possible to catch the name of problematic functions
and the
> JIT only them (using PHPDOC trigger). I'll try to analyze the
crash, but
> most probably, only on next week.
I fixed the problem caused JIT to fail on PHP-Parser tests (it was
related to changes introduced by typed properties patch).
I'm also going to disable automatic JIT code registration in GDB.
Thanks. Dmitry.

Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x
speedup with default JIT configuration. That's promising :)

Next I want to try https://github.com/amphp/hpack (part of HTTP 2
implementation), where I also expect good results. Currently there is a
segfault while running tests.

Could you provide a quick instruction, how to reproduce this (in the
same way like with PHP-Parser).

The reproduce steps are basically the same in this case, just on a
different repo:

Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where we
are going to continue active improvement, and into PHP-7.4, as an
experimental feature.
Thanks. Dmitry.

I would like to check if the JIT provides an improvement for
PHP-Parser.
Unfortunately I'm getting a segfault when running the tests. Should be
reproducible with

I tried to debug this. Unfortunately my gdb doesn't seem to work with
JIT: It hangs when the script starts running, on line
Zend/zend_gdb.c:84
in zend_gdb_register_code. I don't know if that's a bug or I need to do
something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
8.1.0.20180409-git).

GDB takes enormous time registering too many JIT-ed functions...
It should be possible to catch the name of problematic functions and the
JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but
most probably, only on next week.

I fixed the problem caused JIT to fail on PHP-Parser tests (it was
related to changes introduced by typed properties patch).

I'm also going to disable automatic JIT code registration in GDB.

Thanks. Dmitry.

Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x
speedup with default JIT configuration. That's promising :)

Unfortunately I made a mistake here and benchmarked against vanilla PHP
without opcache (and more importantly the optimizer in opcache). Here are
the correct results (for repeated parsing of a large file):

After figuring out that opcache.jit_buffer_size is specified in bytes
(not in megabytes, as RFC states) I got ~5% speedup running
vimeo/psalm (static analyzer) on its own codebase with default
JIT flags and ~7.3% with minimal JIT (1201).

In the current state it may be included both into PHP-8, where we are going to continue active improvement, and into PHP-7.4, as an experimental feature.

Thanks. Dmitry.

Hi Dmitry,

Thank you for making an RFC for this. That makes it possible to have a
proper discussion about the JIT idea.

A concern I have with the current RFC is a lack of a good case for why
it should be necessary; the case for JIT is based on performance
benefits, but the examples provided are unconvincing to me because they
seem too contrived. Both bench.php and drawing fractals represent a
best-case example for a JIT, small programs which do heavy arithmetic
and not much else. Maybe PHP being able to be used for this kind of
software would be cool, but it wouldn't justify the added complexity
(and for that matter security headaches) of adding a JIT to PHP given C,
C++, FORTRAN and so on already exist and are better-suited to it.

I guess what I am saying is that the JIT RFC could benefit from
real-world examples that show a benefit to having it. The ideal
application is something in between WordPress and your Mandelbrot
example, one which has significant complexity (i.e. a plausible
real-world application), hot code which a JIT can actually make notably
faster than the current Zend VM, and is something not too far away
from the kinds of applications people write in PHP today — even if you could write applications focussed on high-performance heavy
number-crunching in PHP, I don't expect people would want to, even if it
becomes less slow.

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an experimental
feature.

Can you give some information on if there are pre-conditions that must hold
for a function to be jitted, or quit conditions that force the JIT to be
reverted for a function? In addition, it would be helpful for testing if
there was a way to find out if a function was jitted, maybe through
ReflectionMethod/Function or opcache_get_status() ?

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an experimental
feature.

Can you give some information on if there are pre-conditions that must
hold for a function to be jitted, or quit conditions that force the JIT to
be reverted for a function? In addition, it would be helpful for testing if
there was a way to find out if a function was jitted, maybe through
ReflectionMethod/Function or opcache_get_status() ?

And as a follow up, the JIT seems to affect zend_execute_ex and
zend_execute_internal based profiling (tested with tideways_xhprof) in a
way that all Jitted functions are not called through those two hooks
anymore, and don't appear in profiling data anymore. Is that a correct
description? The number of parent=>child call entries drops from 88 to 12
in my sample code when jit is activated.

On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <[email protected]
<mailto:[email protected]>> wrote:
Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where
we are going to continue active improvement, and into PHP-7.4,
as an experimental feature.
Can you give some information on if there are pre-conditions that
must hold for a function to be jitted, or quit conditions that force
the JIT to be reverted for a function?

-dopcache.jit=1245 will lead to JIT only functions with @jit doc-comment
tag. It's possible to extend this manual control.

In addition, it would be
helpful for testing if there was a way to find out if a function was
jitted, maybe through ReflectionMethod/Function or
`opcache_get_status()` ?

yes. This makes sense.

And as a follow up, the JIT seems to affect zend_execute_ex and
zend_execute_internal based profiling (tested with tideways_xhprof) in a
way that all Jitted functions are not called through those two hooks
anymore, and don't appear in profiling data anymore. Is that a correct
description? The number of parent=>child call entries drops from 88 to
12 in my sample code when jit is activated.

Is that a desired side-effect?

Yes. This is, at least expected.
PHP profilers/debuggers may disable JIT and opcache for particular
request, setting "opcache.enable=0" in RINIT.

In addition, JIT-ed functions now may be tracked by Linux perf (oprofile
and Intel VTune).

On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <[email protected]
<mailto:[email protected]>> wrote:
Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where
we are going to continue active improvement, and into PHP-7.4,
as an experimental feature.
Can you give some information on if there are pre-conditions that
must hold for a function to be jitted, or quit conditions that force
the JIT to be reverted for a function?

-dopcache.jit=1245 will lead to JIT only functions with @jit doc-comment
tag. It's possible to extend this manual control.

@jit works if I have full control over my code-base, but whenever I use
libraries/frameworks this kind of configuration is too static, and puts a
burden on open-source maintainers to figure out what they want to jit or
not for users.

This option will not be very useful from a distributed maintenance
perspective, especially if you don't know if users pick 4 or 3, this is too
much configuration details/micro-management in my opinion, especially given
your argument that JIT is supposed to be as transparent and behind the
scenes as possible for users.

In my opinion 4 should not be available to users.

In addition, it would be
helpful for testing if there was a way to find out if a function was
jitted, maybe through ReflectionMethod/Function or
`opcache_get_status()` ?

yes. This makes sense.

And as a follow up, the JIT seems to affect zend_execute_ex and
zend_execute_internal based profiling (tested with tideways_xhprof) in a
way that all Jitted functions are not called through those two hooks
anymore, and don't appear in profiling data anymore. Is that a correct
description? The number of parent=>child call entries drops from 88 to
12 in my sample code when jit is activated.

Is that a desired side-effect?

Yes. This is, at least expected.
PHP profilers/debuggers may disable JIT and opcache for particular
request, setting "opcache.enable=0" in RINIT.

This may be acceptable for development profilers, but it is not for
production profiling such as Blackfire and Tideways. I see that overwriting
internal function pointers still works for hooks, so that doesn't need
improvement, but PHP extensions need a way to control zend_execute_ex
behavior, or get an alternative hook for jit based execution.

For Xhprof style profilers, a hook that gets the class + function name
alone would be enough.

For tracing profilers based on a whitelist of a few instrumented functions
like tideways, NewRelic and probably all other APM vendor extensions, there
needs to be a hook to selectively decide "don't JIT this function", that
can be hooked into from 0 to many extensions.

Example, Tideways hooks into the userland function Mage::logException(), to
detect that Magento has thrown an exception that leads to a 500 page being
rendered. It should be possible to make sure this function never gets
jitted, so that I see its execution in zend_execute_ex.

In addition, JIT-ed functions now may be tracked by Linux perf (oprofile
and Intel VTune).

I think you overestimate PHP users savyness in Linux level profiling, maybe
1 in 100 knows how to use perf. In addition many PHP users don't have root
on their servers (managed). And within Docker you don't even get there to
start perfing. Profilers that put user experience first must be PHP
extensions, so we need to make sure the basic level of hooking is possible
even though we have a JIT.

>
>
> On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>
>
>
> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> Hi Internals,
>
>
> I'm glad to finally propose including JIT into PHP.
>
>
> https://wiki.php.net/rfc/jit
>
>
> In the current state it may be included both into PHP-8,
where
> we are going to continue active improvement, and into
PHP-7.4,
> as an experimental feature.
>
>
> Can you give some information on if there are pre-conditions that
> must hold for a function to be jitted, or quit conditions
that force
> the JIT to be reverted for a function?
-dopcache.jit=1245 will lead to JIT only functions with @jit
doc-comment
tag. It's possible to extend this manual control.

@jit works if I have full control over my code-base, but whenever I use
libraries/frameworks this kind of configuration is too static, and puts
a burden on open-source maintainers to figure out what they want to jit
or not for users.

This option will not be very useful from a distributed maintenance
perspective, especially if you don't know if users pick 4 or 3, this is
too much configuration details/micro-management in my opinion,
especially given your argument that JIT is supposed to be as transparent
and behind the scenes as possible for users.

In my opinion 4 should not be available to users.

In some cases it may help (similar to "inline" in C).
For better performance, I would recomend "hot counters trigger" - 3 or
everything - 0.

> In addition, it would be
> helpful for testing if there was a way to find out if a
function was
> jitted, maybe through ReflectionMethod/Function or
> opcache_get_status() ?
yes. This makes sense.
>
> And as a follow up, the JIT seems to affect zend_execute_ex and
> zend_execute_internal based profiling (tested with
tideways_xhprof) in a
> way that all Jitted functions are not called through those two hooks
> anymore, and don't appear in profiling data anymore. Is that a
correct
> description? The number of parent=>child call entries drops from
88 to
> 12 in my sample code when jit is activated.
>
> Is that a desired side-effect?
Yes. This is, at least expected.
PHP profilers/debuggers may disable JIT and opcache for particular
request, setting "opcache.enable=0" in RINIT.

This may be acceptable for development profilers, but it is not for
production profiling such as Blackfire and Tideways. I see that
overwriting internal function pointers still works for hooks, so that
doesn't need improvement, but PHP extensions need a way to control
zend_execute_ex behavior, or get an alternative hook for jit based
execution.

JIT doesn't make a lot of sense if it doesn't optimize the overhead of
interpretation (nested calls to execute_ex, etc). It's clear, that it's
more difficult to debug optimized native code. Most implementations
fallback to interpretation when need debugging. Profiling of optimized
code is possible, but requires additional hooks.

For Xhprof style profilers, a hook that gets the class + function name
alone would be enough.

For tracing profilers based on a whitelist of a few instrumented
functions like tideways, NewRelic and probably all other APM vendor
extensions, there needs to be a hook to selectively decide "don't JIT
this function", that can be hooked into from 0 to many extensions.
Example, Tideways hooks into the userland function Mage::logException(),
to detect that Magento has thrown an exception that leads to a 500 page
being rendered. It should be possible to make sure this function never
gets jitted, so that I see its execution in zend_execute_ex.

I think you overestimate PHP users savyness in Linux level profiling,
maybe 1 in 100 knows how to use perf. In addition many PHP users don't
have root on their servers (managed). And within Docker you don't even
get there to start perfing. Profilers that put user experience first
must be PHP extensions, so we need to make sure the basic level of
hooking is possible even though we have a JIT.

> must hold for a function to be jitted, or quit conditions
that force
> the JIT to be reverted for a function?
-dopcache.jit=1245 will lead to JIT only functions with @jit
doc-comment
tag. It's possible to extend this manual control.

@jit works if I have full control over my code-base, but whenever I use
libraries/frameworks this kind of configuration is too static, and puts
a burden on open-source maintainers to figure out what they want to jit
or not for users.

This option will not be very useful from a distributed maintenance
perspective, especially if you don't know if users pick 4 or 3, this is
too much configuration details/micro-management in my opinion,
especially given your argument that JIT is supposed to be as transparent
and behind the scenes as possible for users.

In my opinion 4 should not be available to users.

In some cases it may help (similar to "inline" in C).
For better performance, I would recomend "hot counters trigger" - 3 or
everything - 0.

> In addition, it would be
> helpful for testing if there was a way to find out if a
function was
> jitted, maybe through ReflectionMethod/Function or
> `opcache_get_status()` ?
yes. This makes sense.
>
> And as a follow up, the JIT seems to affect zend_execute_ex and
> zend_execute_internal based profiling (tested with
tideways_xhprof) in a
> way that all Jitted functions are not called through those two

hooks

> anymore, and don't appear in profiling data anymore. Is that a
correct
> description? The number of parent=>child call entries drops from
88 to
> 12 in my sample code when jit is activated.
>
> Is that a desired side-effect?
Yes. This is, at least expected.
PHP profilers/debuggers may disable JIT and opcache for particular
request, setting "opcache.enable=0" in RINIT.

This may be acceptable for development profilers, but it is not for
production profiling such as Blackfire and Tideways. I see that
overwriting internal function pointers still works for hooks, so that
doesn't need improvement, but PHP extensions need a way to control
zend_execute_ex behavior, or get an alternative hook for jit based
execution.

JIT doesn't make a lot of sense if it doesn't optimize the overhead of
interpretation (nested calls to execute_ex, etc). It's clear, that it's
more difficult to debug optimized native code. Most implementations
fallback to interpretation when need debugging. Profiling of optimized
code is possible, but requires additional hooks.

I understand, but its not about preventing execute_ex for all calls, just
for the 50ish that I am interested in, high level framework functions that
are probably not efficently Jitted anyways.

For Tideways as production profiler, I am obviously interested in users
having great performance, but our users trust us to instrument what is
necessary to find out what might be wrong.

For Xhprof style profilers, a hook that gets the class + function name
alone would be enough.

For tracing profilers based on a whitelist of a few instrumented
functions like tideways, NewRelic and probably all other APM vendor
extensions, there needs to be a hook to selectively decide "don't JIT
this function", that can be hooked into from 0 to many extensions.
Example, Tideways hooks into the userland function Mage::logException(),
to detect that Magento has thrown an exception that leads to a 500 page
being rendered. It should be possible to make sure this function never
gets jitted, so that I see its execution in zend_execute_ex.

Sorry, but I can't add @nojit or @jit to third party frameworks or
libraries. And this is what most Profiling/APM extensions are explicitly
hooking into. A third party extension must control this somehow, without
users having to have to change their code at all.

I think you overestimate PHP users savyness in Linux level profiling,
maybe 1 in 100 knows how to use perf. In addition many PHP users don't
have root on their servers (managed). And within Docker you don't even
get there to start perfing. Profilers that put user experience first
must be PHP extensions, so we need to make sure the basic level of
hooking is possible even though we have a JIT.

Shouldn't we introduce annotations instead of relying on doc comments?

Yeah I'm not too happy with that approach either. I would rather see
another way to do this and like you said; annotations is probably the
best way to go about it as introducing a new keyword is not very
suitable imo.

Shouldn't we introduce annotations instead of relying on doc comments?

Yeah I'm not too happy with that approach either. I would rather see
another way to do this and like you said; annotations is probably the
best way to go about it as introducing a new keyword is not very
suitable imo.

Shouldn't we introduce annotations instead of relying on doc comments?

Yeah I'm not too happy with that approach either. I would rather see
another way to do this and like you said; annotations is probably the
best way to go about it as introducing a new keyword is not very
suitable imo.

Understanding and adoptions of annotations (Doctrine mainly afaics)
have change. I think it is tricky to define it in a way that it can be
useful and adopted as a core language feature, meaning being flexible
enough to be extendable and usable as a base for userland extensions.
That latter part is the biggest challenge. What do the actual
users/authors of the current userland implementation think? (pls other
thread? :)

Best,

I think I heard some stat that over 50% of Azure now runs Linux (and I am sure PHP is primarily running on Linux). So given JIT probably helps 95% of production PHP installations I wouldn’t hold this back. If Windows ends up being important to folks some (and possibly msft) will contribute that.

I think we should explore the feasibility of moving some internal PHP functions to userland if performance is reasonable. Will help security.

I'm honestly a bit perplexed by how many people here viewing Windows
support as a must have, while at the same time I think we all agree PHP is
very scarcely found on production Windows servers, and JIT is a
predominantly production feature.

While this is anecdotal, I think you might find a different perspective from user group organizers. I've encountered many user group members over the years who run PHP on Windows. It's more common that they develop on Windows and deploy to Linux, but I do know those who also deploy to Windows in production.

This is actually very consistent with my experience, including some hard data I have from relevant (even if it 100% representative) download and usage stats. Windows is an extremely popular platform for developing PHP on - in fact, from the data I have (which isn’t conclusive) - it’s even more popular than Linux in certain demographics. But much like you say, this dev scenario is more common (I would say a lot more common) than it is to see Windows in production - which does not come to say it’s non existent in prod, just that it’s a lot less common.

That's not to say I personally think that Windows support is a must-have for JIT, but it's definitely important for many of the people in the user groups I've worked with.

I’m not against having support for Windows at all. I do think that much of the discussion here ensued because it wasn’t completely clear that JIT is geared pretty much exclusively at production systems. Personally, I see Windows support as between nice-to-have and important, but not as a must. In other words, if we can bring this boost to the vast majority of production systems, not being able to bring it to a (I believe small) minority of these systems shouldn’t be a deal breaker. I respect that others may have a different view, as long as it’s clear to everyone that JIT is indeed almost exclusively geared at production.

While this is anecdotal, I think you might find a different perspective from user group organizers. I've encountered many user group members over the years who run PHP on Windows. It's more common that they develop on Windows and deploy to Linux, but I do know those who also deploy to Windows in production.

This is actually very consistent with my experience, including some hard data I have from relevant (even if it 100% representative) download and usage stats. Windows is an extremely popular platform for developing PHP on - in fact, from the data I have (which isn’t conclusive) - it’s even more popular than Linux in certain demographics. But much like you say, this dev scenario is more common (I would say a lot more common) than it is to see Windows in production - which does not come to say it’s non existent in prod, just that it’s a lot less common.

To add to that ... just how many windows based developers have actually
moved to PHP7? I'd missed that the official windows package HAD dropped
PEAR, but it's provided as part of the older third party windows
distributions, and THOSE are the ones being used by the people I'm
supporting because for a time there were no official distributions on
windows.. THAT is the reason their code base has not move to PHP7 as it
does not have access to all the third party packages being used.

While JIT should be totally transparent, is it not the case that
invariably edge cases can cause different effects on different
platforms, and it is perhaps that which is creating a concern if code
can't be fully tested on a windows platform for that reason? In
practice, it's academic, since if there are subtle differences between
Linux and Windows it probably does not matter if JIT is enabled or not?
One or other is simply displaying a bug that needs fixing?

Certainly production wise there is little evidence that W10 has done
anything to improve the speed of the web stack which still lags far
behind Linux on the same hardware, bu it's some time since I ACTUALLY
tested that but perhaps it is time to update my own benchmarks.

Most PHP production workloads are on Linux, and as far as I can tell
this trend is only growing over the years - with virtual machines and
now containers becoming more and more popular - meaning that even
developers with other host OSs still use Linux for the actual PHP
development.

I am not sure this really is the case. Depending on which statistics you
believe te be true, about a quarter to a third of the Web is powered by
Wordpress. Wordpress market share is not diminishing.

How is that related? The vast majority of WordPress is deployed on Linux servers, much (if not most) of it hosted.

Do not underestimate the huge amount of Wordpress plugin developers that
develop on Windows. Code quality is varying from very low to quite high,
but these people are PHP developers as well.

Again, how does that relate to what I said? I actually said in some demographics Windows is more common than Linux for development. I'm also saying that's slowly changing due to certain tech trends, but it doesn't mean that Windows development isn't still incredibly popular. The thing is, it's mostly orthogonal to JIT - which is a production oriented feature.

Most PHP production workloads are on Linux, and as far as I can tell
this trend is only growing over the years - with virtual machines and
now containers becoming more and more popular - meaning that even
developers with other host OSs still use Linux for the actual PHP
development.

I am not sure this really is the case. Depending on which statistics you
believe te be true, about a quarter to a third of the Web is powered by
Wordpress. Wordpress market share is not diminishing.

Do not underestimate the huge amount of Wordpress plugin developers that
develop on Windows. Code quality is varying from very low to quite high,
but these people are PHP developers as well.

How is that related?

It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't use
Linux for the actual PHP development. They are using Windows.

It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't use
Linux for the actual PHP development. They are using Windows.

That statement was in a certain context - for those who use containers and Linux VMs, which is (as mentioned) a growing trend. I think it's clear that I'm not claiming it's everyone, or even the majority - but if it wasn't clear - it should be now...

It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't use
Linux for the actual PHP development. They are using Windows.

That statement was in a certain context - for those who use containers and
Linux VMs, which is (as mentioned) a growing trend. I think it's clear
that I'm not claiming it's everyone, or even the majority - but if it
wasn't clear - it should be now...

Zeev

I feel like this discussion ended up going a bit astray, with a focus on
only the issue of Windows support... While I think that we should endeavor
to support at least Windows and MacOS before the JIT hits a release version
of PHP, at this point in time (and for the purposes of the vote) the
questions of maintenance and stability are the most important. Ultimately
those questions can't really be answered until interested parties have
reviewed the JIT codebase. To that end it would be helpful if:

a) A PR of the JIT branch could be submitted against php-src, so there is a
place for review comments and more technical discussions. (It might be
necessary to squash, as GH doesn't deal with large history well.)

b) The RFC (or some other place) is extended with some high-level design
information on how the JIT works on a technical level. Some notes on how
JIT bugs are usually debugged would also be very helpful.

It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't use
Linux for the actual PHP development. They are using Windows.

That statement was in a certain context - for those who use containers and
Linux VMs, which is (as mentioned) a growing trend. I think it's clear
that I'm not claiming it's everyone, or even the majority - but if it
wasn't clear - it should be now...

Zeev

I feel like this discussion ended up going a bit astray, with a focus on
only the issue of Windows support... While I think that we should endeavor
to support at least Windows and MacOS before the JIT hits a release version
of PHP, at this point in time (and for the purposes of the vote) the
questions of maintenance and stability are the most important.

If we don't start, we definitively won't get support.

Ultimately
those questions can't really be answered until interested parties have
reviewed the JIT codebase. To that end it would be helpful if:

a) A PR of the JIT branch could be submitted against php-src, so there is a
place for review comments and more technical discussions. (It might be
necessary to squash, as GH doesn't deal with large history well.)

OK. Not sure about re-base.

b) The RFC (or some other place) is extended with some high-level design
information on how the JIT works on a technical level. Some notes on how
JIT bugs are usually debugged would also be very helpful.

It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't
use
Linux for the actual PHP development. They are using Windows.

That statement was in a certain context - for those who use containers
and
Linux VMs, which is (as mentioned) a growing trend. I think it's clear
that I'm not claiming it's everyone, or even the majority - but if it
wasn't clear - it should be now...

Zeev

I feel like this discussion ended up going a bit astray, with a focus on
only the issue of Windows support... While I think that we should
endeavor
to support at least Windows and MacOS before the JIT hits a release
version
of PHP, at this point in time (and for the purposes of the vote) the
questions of maintenance and stability are the most important.

If we don't start, we definitively won't get support.

Ultimately
those questions can't really be answered until interested parties have
reviewed the JIT codebase. To that end it would be helpful if:

a) A PR of the JIT branch could be submitted against php-src, so there
is a
place for review comments and more technical discussions. (It might be
necessary to squash, as GH doesn't deal with large history well.)

OK. Not sure about re-base.

b) The RFC (or some other place) is extended with some high-level design
information on how the JIT works on a technical level. Some notes on how
JIT bugs are usually debugged would also be very helpful.

It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't
use
Linux for the actual PHP development. They are using Windows.

That statement was in a certain context - for those who use containers
and
Linux VMs, which is (as mentioned) a growing trend. I think it's clear
that I'm not claiming it's everyone, or even the majority - but if it
wasn't clear - it should be now...

Zeev

I feel like this discussion ended up going a bit astray, with a focus on
only the issue of Windows support... While I think that we should
endeavor
to support at least Windows and MacOS before the JIT hits a release
version
of PHP, at this point in time (and for the purposes of the vote) the
questions of maintenance and stability are the most important.

If we don't start, we definitively won't get support.

Ultimately
those questions can't really be answered until interested parties have
reviewed the JIT codebase. To that end it would be helpful if:

a) A PR of the JIT branch could be submitted against php-src, so there
is a
place for review comments and more technical discussions. (It might be
necessary to squash, as GH doesn't deal with large history well.)

OK. Not sure about re-base.

b) The RFC (or some other place) is extended with some high-level design
information on how the JIT works on a technical level. Some notes on how
JIT bugs are usually debugged would also be very helpful.

OK. I'll try to extend RFC with some design elements.

Thanks. Dmitry.

As you probably spent a lot of time profiling the JIT, I'm wondering if you
have any insights about what the main issues are right now that prevent
better performance and what some idea to improve those would be. E.g. I
don't think the JIT currently does any inlining (right?) and that might be
something that could give a benefit?

> On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski <[email protected]
<mailto:[email protected]>> wrote:
>
>>
>>> On 3 Feb 2019, at 16:43, Jan Ehrhardt <[email protected]
<mailto:[email protected]>> wrote:
>>>
>>> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +0000):
>>>>
>>>>
>>>> How is that related?
>>>
>>> It is directly related with your statement that "developers
with other
>>> host OSs still use Linux for the actual PHP development". They
don't use
>>> Linux for the actual PHP development. They are using Windows.
>>
>> That statement was in a certain context - for those who use
containers and
>> Linux VMs, which is (as mentioned) a growing trend. I think
it's clear
>> that I'm not claiming it's everyone, or even the majority - but
if it
>> wasn't clear - it should be now...
>>
>> Zeev
>>
>
> I feel like this discussion ended up going a bit astray, with a
focus on
> only the issue of Windows support... While I think that we should
endeavor
> to support at least Windows and MacOS before the JIT hits a
release version
> of PHP, at this point in time (and for the purposes of the vote) the
> questions of maintenance and stability are the most important.
If we don't start, we definitively won't get support.
> Ultimately
> those questions can't really be answered until interested parties
have
> reviewed the JIT codebase. To that end it would be helpful if:
>
> a) A PR of the JIT branch could be submitted against php-src, so
there is a
> place for review comments and more technical discussions. (It
might be
> necessary to squash, as GH doesn't deal with large history well.)
OK. Not sure about re-base.
> b) The RFC (or some other place) is extended with some high-level
design
> information on how the JIT works on a technical level. Some notes
on how
> JIT bugs are usually debugged would also be very helpful.
OK. I'll try to extend RFC with some design elements.
Thanks. Dmitry.

As you probably spent a lot of time profiling the JIT, I'm wondering if
you have any insights about what the main issues are right now that
prevent better performance and what some idea to improve those would be.

Real-life apps more suffer from bad data locality and data set size.
One of the metric that shows, how good/bad progam is executes is CPI
(Cycles per Instruction). You may measure it using Linux perf (perf
stat) or estimate using callgrind.

For bench.php it's 0.5, for Wordpress 1.2. This means that Wordpress
waste significantly more CPU time because of different stalls.

Even if we improve execution, using JIT, and reduce the amount of
executed instructions, this doesn't proportionally affects CPU cycles
(and time), because many data related stalls are still there.

E.g. I don't think the JIT currently does any inlining (right?) and that
might be something that could give a benefit?

Absolutely.

Currently JIT keeps VM state in consistency, when it calls any standard
VM handler, emits error/warning, throw exception, and just call any PHP
API function. But this is not necessary for most fast paths.

Then we will generate code only for fast paths, especially optimized
for our cases (information, collected during profiling). This code is
not going to keep the VM state and may implement inlining of PHP
functions and other smart optimizations.

The fast-path code is going to include "guard" check for transitions
to slow paths that were never executes during profiling, but that can't
be eliminated by static analyses (SSA info).

In case of guard failure, we should jump form JIT execution to VM,
restoring the VM state consistency. This process named "deoptimization".

It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't use
Linux for the actual PHP development. They are using Windows.

That statement was in a certain context - for those who use containers and Linux VMs, which is (as mentioned) a growing trend. I think it's clear that I'm not claiming it's everyone, or even the majority - but if it wasn't clear - it should be now...

please correct me but Docker containers can be run with Hyper-V
isolation on recent Windows versions. This way the users of of these
recent Windows versions can get directly the Linux performance jump.

And also, whoever hasn't started using containers while developing with
PHP should start doing so and not to rely on *AMP tools for packaging.

A concern I have with the current RFC is a lack of a good case for why
it should be necessary;

While this is a subjective opinion, it's definitely a valid one. Unlike
phpng (PHP 7) which was a slam dunk - JIT isn't - and whether or not the
added value is worth the added complexity is very much up for debate.

One our hopes in opening this up for comments, is that people would
actually try the code themselves and experiment with it - well beyond what
we can do ourselves. If & when we get feedback from folks on apps and use
cases they tried this on with interesting results, we'll add them to the
RFC. I'd love to hear from folks trying it on things like React. Then,
there's also the possibility of writing builtin functions in PHP - although
that would obviously require a much wider platform support than we
presently have to be viable.

and not much else. Maybe PHP being able to be used for this kind of
software would be cool, but it wouldn't justify the added complexity
(and for that matter security headaches) of adding a JIT to PHP given C,
C++, FORTRAN and so on already exist and are better-suited to it.

This too is a subjective (& obviously completely valid) opinion. Of
course, if the only point of JIT would be 'coolness' then it's probably not
worth the trouble (although JIT is a huge selling point even if it doesn't
bring huge gains, as we've seen in the past). But I don't think it'll end
just there. For me, I would prefer using PHP over any of these if I can
help it and if the performance is reasonable enough - and I doubt I'm the
only person on the planet that feels that way. Again, we don't think it's
a slam dunk (the RFC would have looked differently if we did), but it's not
inconceivable that if we position PHP as a language where you can get the
ease of development benefits of PHP, while getting near-native performance

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an
experimental feature.

Thanks. Dmitry.

Hi Dmitry,

Thank you for making an RFC for this. That makes it possible to have a
proper discussion about the JIT idea.

A concern I have with the current RFC is a lack of a good case for why
it should be necessary; the case for JIT is based on performance
benefits, but the examples provided are unconvincing to me because they
seem too contrived. Both bench.php and drawing fractals represent a
best-case example for a JIT, small programs which do heavy arithmetic
and not much else. Maybe PHP being able to be used for this kind of
software would be cool, but it wouldn't justify the added complexity
(and for that matter security headaches) of adding a JIT to PHP given C,
C++, FORTRAN and so on already exist and are better-suited to it.

I guess what I am saying is that the JIT RFC could benefit from
real-world examples that show a benefit to having it. The ideal
application is something in between WordPress and your Mandelbrot
example, one which has significant complexity (i.e. a plausible
real-world application), hot code which a JIT can actually make notably
faster than the current Zend VM, and is something not too far away
from the kinds of applications people write in PHP today — even if you could write applications focussed on high-performance heavy
number-crunching in PHP, I don't expect people would want to, even if it
becomes less slow.

That is actually a very good real-world example from my perspective and
makes a better case for why JIT compilation to native code would be
beneficial. I would like to write a PHP compiler in PHP (actually, I
began doing so but it's very neglected and pretty useless) and it is
exciting if JIT could make PHP do that type of task faster. :)

I’m not sure it’s a great real-world example - PHP Parser is much more maths-y than the vast amount of PHP code, but if your PHP-based compiler had a similar makeup it might show somewhat similar benefits.

Hi,

Dmitry Stogov wrote:

I've added info from Nikita: PHP-Parser became 1.5 times faster.

That is actually a very good real-world example from my perspective and makes a better case for why JIT compilation to native code would be beneficial. I would like to write a PHP compiler in PHP (actually, I began doing so but it's very neglected and pretty useless) and it is exciting if JIT could make PHP do that type of task faster. :)

I do not believe that something major like this should make it into any
PHP 7.x release. Having it as experimental new feature in the master/PHP
8.0 branch makes the most sense to me.

ACK

Does it mean that when PHP 8.0 comes out (in roughly two years' time most
probably), we'd be saying this is experimental? Or that only in the
meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs before
it's released, we'd say it's experimental but will remove that tag by the
time 8.0 is released?

If it's the former - I don't think we should go in this direction. If we
decide that it's sensible to have it - I think we should work to ensure
that it's production ready by the time PHP 8.0 is released. Offering it as
something experimental (i.e. not for production) in 7.4 can help us with
that goal, as it will make it easier for a wider range of people to
experiment with it and provide feedback. I can't think of any
technological downsides to including it as experimental in 7.4 - there's a
slight "marketing" downside (it will be less of a shiny new thing in PHP
8.0), but personally I think the feedback we're likely to get is worth it.

Does it mean that when PHP 8.0 comes out (in roughly two years' time most
probably), we'd be saying this is experimental? Or that only in the
meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs before
it's released, we'd say it's experimental but will remove that tag by the
time 8.0 is released?

The latter. Every new feature is experimental until it's released; scalar
type hints were experimental in master until 7.0 was released; typed
properties are experimental until 7.4 is released; I don't see why this
should be any different.

Offering it as
something experimental (i.e. not for production) in 7.4 can help us with
that goal, as it will make it easier for a wider range of people to
experiment with it and provide feedback.

As I mentioned in a previous e-mail, I'm not clear who these extra users
are, or what value their feedback will be. On one hand, if someone tests
their application on a stale version of the JIT engine released with 7.4.0,
and says "it segfaults when I foo" or "I'm surprised it doesn't optimise
bar", the answer is likely to be "we fixed that 6 months ago in master". On
the other hand, if someone is confident enough to enable an experimental
JIT feature on a server, they're probably fine with running a pre-alpha
snapshot, or building it from source (e.g. by downloading Rasmus's vagrant
box).

If the feature was "mostly finalised but needs more testing", then an
experimental release might make sense; but that's not the impression I get
here, as it's been said over and over that deeper changes are needed to get
the full advantage, and that's why we need PHP 8 in the first place.

Regards,

I do not believe that something major like this should make it into any
PHP 7.x release. Having it as experimental new feature in the
master/PHP
8.0 branch makes the most sense to me.

ACK

Does it mean that when PHP 8.0 comes out (in roughly two years' time most
probably), we'd be saying this is experimental? Or that only in the
meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs before
it's released, we'd say it's experimental but will remove that tag by the
time 8.0 is released?

I don't think we can really answer that question at this point in time.
That depends on how stable and compatible the JIT is by the time PHP 8.0
comes around. But having it as a non-experimental feature should definitely
the goal, and I also think this is possible.

If it's the former - I don't think we should go in this direction. If we
decide that it's sensible to have it - I think we should work to ensure
that it's production ready by the time PHP 8.0 is released. Offering it as
something experimental (i.e. not for production) in 7.4 can help us with
that goal, as it will make it easier for a wider range of people to
experiment with it and provide feedback. I can't think of any
technological downsides to including it as experimental in 7.4 - there's a
slight "marketing" downside (it will be less of a shiny new thing in PHP
8.0), but personally I think the feedback we're likely to get is worth it.

There a number of downsides to including it in PHP 7.4:

First and foremost for me: Maintenance. We are only shortly after
branching, and the PHP 7.4 and PHP 8.0 branches already have some
significant divergences (e.g. in object handler APIs). I don't expect that
this is going to be get as bad as PHP 5 vs PHP 7 internals, but I would
also very much prefer not having to maintain a new large and complex chunk
of code against two different major engine versions.

Marketing: As you already mentioned yourself, adding a JIT is a great
marketing point. I think that PHP 7 was quite successful from a marketing
perspective, because it had a nice blend of major performance wins, some
long-awaited features and a few incompatibilities. It would be great if we
could repeat this with PHP 8, and I think that having a JIT and some major
language feature (say generics) would be a great drive to upgrade. Adding
the JIT earlier as an experimental feature would dilute this a lot.

Stability / Compatibility: While we can mark features as experimental all
we want, let's fact it: If it exists, it's going to end up in production. I
would prefer to only publicize the JIT once it is stable, and also
importantly, has good integration with 3rd party extensions. Basically
"just works". I know that Joe has been testing some of this exts (like pcov
and pthreads) and their interaction with the JIT, and also been talking to
some other maintainers of "low-level" extensions like profilers. From what
I understood, quite some work will be needed to allow integration (beyond
just disabling the JIT).

I do not believe that something major like this should make it into
any
PHP 7.x release. Having it as experimental new feature in the
master/PHP
8.0 branch makes the most sense to me.

ACK

Does it mean that when PHP 8.0 comes out (in roughly two years' time most
probably), we'd be saying this is experimental? Or that only in the
meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs
before
it's released, we'd say it's experimental but will remove that tag by the
time 8.0 is released?

I don't think we can really answer that question at this point in time.
That depends on how stable and compatible the JIT is by the time PHP 8.0
comes around. But having it as a non-experimental feature should definitely
the goal, and I also think this is possible.

Agreed.

If it's the former - I don't think we should go in this direction. If we
decide that it's sensible to have it - I think we should work to ensure
that it's production ready by the time PHP 8.0 is released. Offering it
as
something experimental (i.e. not for production) in 7.4 can help us with
that goal, as it will make it easier for a wider range of people to
experiment with it and provide feedback. I can't think of any
technological downsides to including it as experimental in 7.4 - there's
a
slight "marketing" downside (it will be less of a shiny new thing in PHP
8.0), but personally I think the feedback we're likely to get is worth
it.

There a number of downsides to including it in PHP 7.4:

First and foremost for me: Maintenance. We are only shortly after
branching, and the PHP 7.4 and PHP 8.0 branches already have some
significant divergences (e.g. in object handler APIs). I don't expect that
this is going to be get as bad as PHP 5 vs PHP 7 internals, but I would
also very much prefer not having to maintain a new large and complex chunk
of code against two different major engine versions.

That's a valid point, but given we're only a few months away from
feature-completing 7.4, as well as the general direction that most probably
more substantial changes will make it into 8.0 - I don't know that the
initial investment in a 7.4 version of JIT (and the marginal cost of then
maintaining it) would be too big. I believe Dmitry's proposing that while
realizing the bulk of the work will fall on his shoulders if we decide to
do it.

Marketing: As you already mentioned yourself, adding a JIT is a great
marketing point. I think that PHP 7 was quite successful from a marketing
perspective, because it had a nice blend of major performance wins, some
long-awaited features and a few incompatibilities. It would be great if we
could repeat this with PHP 8, and I think that having a JIT and some major
language feature (say generics) would be a great drive to upgrade. Adding
the JIT earlier as an experimental feature would dilute this a lot.

We both agree that if we include JIT in 7.4 it will dilute from the 'shiny
new thing' aspect of it when it's available in 8.0. That said -
realistically, it seems that JIT will not be as revolutionary as phpng was
in terms of real world performance impact, so if I had to guess - migration
to 8 it would be a lot slower than the migration to 7 (the motivation to
upgrade to 7 in the vast majority of companies I came across was
predominantly around performance; new features were a nice bonus).

Stability / Compatibility: While we can mark features as experimental all

we want, let's fact it: If it exists, it's going to end up in production. I
would prefer to only publicize the JIT once it is stable, and also
importantly, has good integration with 3rd party extensions. Basically
"just works". I know that Joe has been testing some of this exts (like pcov
and pthreads) and their interaction with the JIT, and also been talking to
some other maintainers of "low-level" extensions like profilers. From what
I understood, quite some work will be needed to allow integration (beyond
just disabling the JIT).

I'm not too worried about it finding itself into production, as long as we
make it clear that it's not ready for it. People who run experimental
software in production are typically quite aware of the risk they're
taking, and often they are quite determined too - so they might be the ones
who check out Dmitry's code as it is today without waiting for our RFCs
anyway. It's also quite reasonable that an experimental feature won't work
with every last extension (as long as they're not super mainstream like
MySQL or curl).

Either way, I think the decision whether to include it in 7.4 or not is
tactical. It's gaining wider testing exposure, at the expense of losing
some 'sexiness' of a shiny new feature in 8.0. I see both approaches as
entirely valid.

Does it mean that when PHP 8.0 comes out (in roughly two years' time most
probably), we'd be saying this is experimental? Or that only in the
meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs before
it's released, we'd say it's experimental but will remove that tag by the
time 8.0 is released?

The latter. Every new feature is experimental until it's released; scalar
type hints were experimental in master until 7.0 was released; typed
properties are experimental until 7.4 is released; I don't see why this
should be any different.

I'm pretty sure we've had experimental features in released versions. To
me tagging something as experimental in master while it's in early
development stages is somewhat superfluous - the whole of master should be
considered pre-alpha / alpha until it goes to beta. That's why I was
asking.

Offering it as

something experimental (i.e. not for production) in 7.4 can help us with
that goal, as it will make it easier for a wider range of people to
experiment with it and provide feedback.

As I mentioned in a previous e-mail, I'm not clear who these extra users
are, or what value their feedback will be.

I'm not sure who they are either, but much like we've had several folks
here on internals report back their experimentation with JIT, I think
casting a wider net will likely result in more feedback.

On one hand, if someone tests their application on a stale version of the

JIT engine released with 7.4.0, and says "it segfaults when I foo" or "I'm
surprised it doesn't optimise bar", the answer is likely to be "we fixed
that 6 months ago in master".

And that could be a very reasonable answer; Given that it's an
experimental feature that someone purposely decided to build and enable,
telling them that they can get a more recent version of JIT by using master
is not an unreasonable response.

On the other hand, if someone is confident enough to enable an
experimental JIT feature on a server, they're probably fine with running a
pre-alpha snapshot, or building it from source (e.g. by downloading
Rasmus's vagrant box).

We seem to agree, but there's no doubt in my mind that 7.4 will reach a
much wider audience than folks who are here on internals. In a nutshell,
the fact that they can get a pre-alpha PHP 8 that has JIT, doesn't mean
they know it even exists. Including it in 7.4 can help advertise that - of
course, other than the fact that I'm sure in many cases it will actually
work, enabling them to provide us with real world feedback without having
to upgrade to master/8. If we thought that all of them would be bumping
into trouble, we wouldn't be proposing it as an option.

If the feature was "mostly finalised but needs more testing", then an
experimental release might make sense; but that's not the impression I get
here, as it's been said over and over that deeper changes are needed to get
the full advantage, and that's why we need PHP 8 in the first place.

Actually, I think it's closer to being "mostly finalized' than it is to
requiring a major overhaul. It's our 3rd attempt at it after spending the
better part of a decade working on it, and while there's always room for
improvement - and there are some specific areas that aren't yet done
(platform support, ZTS, etc.) - I don't think we're likely to see
fundamental ground-breaking changes. The most common PHP use case - Linux
x86/x86_64 single threaded - is probably fairly close to what it will be.

Again, like I told Nikita I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it), but I
do think there's a reasonable case for both directions.

[...] I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it), but I
do think there's a reasonable case for both directions.

If I may add some voice to Zeev's arguments, being able to play with JIT as
early as possible would allow the community to experiment using PHP in
areas where it doesn't fit right now. Having to wait 2 more years to
discover that maybe it's useful to build some new libraries could be a
waste of time at the tactical level (there are other technologies around
that move fast also :) )

Not to detract from the technical challenges of moving in this direction,
of course.
Just my 2cts from a "userland" guy :)

[...] I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it),
but I
do think there's a reasonable case for both directions.

If I may add some voice to Zeev's arguments, being able to play with JIT as
early as possible would allow the community to experiment using PHP in
areas where it doesn't fit right now. Having to wait 2 more years to
discover that maybe it's useful to build some new libraries could be a
waste of time at the tactical level (there are other technologies around
that move fast also :) )

Not to detract from the technical challenges of moving in this direction,
of course.
Just my 2cts from a "userland" guy :)

Nicolas

Hello everyone,

I agree with this sentiment and the general idea of shipping JIT as
experimental in 7.4 and required to build with a configure flag.
master for 8.0 is going to contain much more and be more unstable and not
practical for testing what JIT can do at that point due to all other
features and improvements going into it like additional optimizations and
platform support.
It will give me, as a userland developer, a platform where I can actually
play with it early and on a stable platform. And I understand what I'm
doing at that point.

First and foremost for me: Maintenance. We are only shortly after
branching, and the PHP 7.4 and PHP 8.0 branches already have some
significant divergences (e.g. in object handler APIs). I don't expect that
this is going to be get as bad as PHP 5 vs PHP 7 internals, but I would
also very much prefer not having to maintain a new large and complex chunk
of code against two different major engine versions.

That's a valid point, but given we're only a few months away from
feature-completing 7.4, as well as the general direction that most probably
more substantial changes will make it into 8.0 - I don't know that the
initial investment in a 7.4 version of JIT (and the marginal cost of then
maintaining it) would be too big. I believe Dmitry's proposing that while
realizing the bulk of the work will fall on his shoulders if we decide to
do it.

Currently, I'm keeping in consistency two JIT branches. For master and
PHP-7.4 (links in RFC). In case 7.4 don't pass, I stop its support.

Marketing: As you already mentioned yourself, adding a JIT is a great
marketing point. I think that PHP 7 was quite successful from a marketing
perspective, because it had a nice blend of major performance wins, some
long-awaited features and a few incompatibilities. It would be great if we
could repeat this with PHP 8, and I think that having a JIT and some major
language feature (say generics) would be a great drive to upgrade. Adding
the JIT earlier as an experimental feature would dilute this a lot.

We both agree that if we include JIT in 7.4 it will dilute from the 'shiny
new thing' aspect of it when it's available in 8.0. That said -
realistically, it seems that JIT will not be as revolutionary as phpng was
in terms of real world performance impact, so if I had to guess - migration
to 8 it would be a lot slower than the migration to 7 (the motivation to
upgrade to 7 in the vast majority of companies I came across was
predominantly around performance; new features were a nice bonus).

Marketing is simple :) We like to make good JIT in PHP-8, and we need
feedback to really do it. The more interest we get to JIT in PHP-7.4 the
better JIT might be implemented in PHP-8.

Stability / Compatibility: While we can mark features as experimental all

we want, let's fact it: If it exists, it's going to end up in production. I
would prefer to only publicize the JIT once it is stable, and also
importantly, has good integration with 3rd party extensions. Basically
"just works". I know that Joe has been testing some of this exts (like pcov
and pthreads) and their interaction with the JIT, and also been talking to
some other maintainers of "low-level" extensions like profilers. From what
I understood, quite some work will be needed to allow integration (beyond
just disabling the JIT).

Again, the early we know problems, the better.
Most people will start testing PHP-8 with their third-party extension
only after release. Then we will start getting reports about problems,
and the solutions might need serious API or design changes, that are not
allowed in minor releases...

This idea of an experimental feature as complex as a JIT is dangerous. It
is not finished, and dmitry has said he's not willing to put more time into
until it's merged. That's his prerogative, and it is ours to say that we
don't want unfinished software that only one or two people really
understand in PHP. All of the rest of internals need all of the time
between now and PHP 8 to educate ourselves on this so that we function as
well as we do now when it comes to finding and fixing bugs, and pushing PHP
forward. Merging the JIT into 7.4 puts a brick wall in the way of progress
that none of us have the tools to climb over.

I hear the argument about wanting to test, but anyone with sufficient
expertise to test the JIT is capable of building the branch available on
github, we do not need to push out an incomplete product to the entire
world for the sake of that handful of individuals who will actually test.

I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
current form, and would ask everyone to please think very carefully about
it, prior to supporting it.

[...] I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it),
but I
do think there's a reasonable case for both directions.

If I may add some voice to Zeev's arguments, being able to play with JIT
as
early as possible would allow the community to experiment using PHP in
areas where it doesn't fit right now. Having to wait 2 more years to
discover that maybe it's useful to build some new libraries could be a
waste of time at the tactical level (there are other technologies around
that move fast also :) )

Not to detract from the technical challenges of moving in this direction,
of course.
Just my 2cts from a "userland" guy :)

Nicolas

Hello everyone,

I agree with this sentiment and the general idea of shipping JIT as
experimental in 7.4 and required to build with a configure flag.
master for 8.0 is going to contain much more and be more unstable and not
practical for testing what JIT can do at that point due to all other
features and improvements going into it like additional optimizations and
platform support.
It will give me, as a userland developer, a platform where I can actually
play with it early and on a stable platform. And I understand what I'm
doing at that point.

I agree with this sentiment and the general idea of shipping JIT as
experimental in 7.4 and required to build with a configure flag.
master for 8.0 is going to contain much more and be more unstable and not
practical for testing what JIT can do at that point due to all other
features and improvements going into it like additional optimizations and
platform support.

This is a reasonable point - other things will be happening on master which
make JIT harder to test. I guess part of the decision here depends what
those are.

If the idea is for someone to build a tagged release (7.4.x) with an
experimental configure flag, could we have a half-way house, by tagging
official "JIT preview builds"? These would mostly just be commits of master
where things happened to be reasonably stable, with the occasional
throwaway branch reverting out something broken.

We could then publicise these builds as "try PHP 8 today" in all the same
places we would have publicised "try --enable-jit today". If anything, it
could be more visible, because every few months we could post a new tag to
the home page of php.net.

To compare strategies:

Experimental feature in 7.4, port all JIT changes. Users get a current
snapshot of JIT every release of 7.4.x; maintainers have to port a lot of
code that may never be used.

Experimental feature in 7.4, mostly frozen when 7.4.0 ships. Users get an
out of date JIT to play with; maintainers have to make sure it's not
completely broken during 7.4 cycle.

"JIT preview" tags every few months, with no published schedule. Users
get a current snapshot of JIT every few months; maintainers only manage the
implementation in one branch, and choose when to tag a new preview.

Regards,

This idea of an experimental feature as complex as a JIT is dangerous. It
is not finished, and dmitry has said he's not willing to put more time into
until it's merged. That's his prerogative, and it is ours to say that we
don't want unfinished software that only one or two people really
understand in PHP. All of the rest of internals need all of the time
between now and PHP 8 to educate ourselves on this so that we function as
well as we do now when it comes to finding and fixing bugs, and pushing PHP
forward.

Few years ago I was claimed for development PHPNNG privately, but that
time we delivered to @internals almost completed solution. Now you don't
like the solution, because it's incomplete in your opinion (ZTS support,
etc), and the development makes troubles...

If you are interested in ZTS, you may invest time in implementation of
the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
if you start, because I may find time myself.

I told, I'm not going to do any active JIT development at this point.
Why to waste time, if it's not going to be accepted...
However, I keep it in sync with master and PHP-7.4, fix reported
problems, respond to code review comments, etc (just check git commits
history).

In last email I asked for ideas for RFC improvement (like notes about
unsupported ZTS). May be it makes sense to add cons/pros for additional
PHP-7.4 proposal. May be write something more clear (I'm not a native
speaker).

But this "a bit toxic" discussion, at least, steals time from
constructive things.

Merging the JIT into 7.4 puts a brick wall in the way of progress
that none of us have the tools to climb over.

I hear the argument about wanting to test, but anyone with sufficient
expertise to test the JIT is capable of building the branch available on
github, we do not need to push out an incomplete product to the entire
world for the sake of that handful of individuals who will actually test.

I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
current form, and would ask everyone to please think very carefully about
it, prior to supporting it.

[...] I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it),
but I
do think there's a reasonable case for both directions.

If I may add some voice to Zeev's arguments, being able to play with JIT
as
early as possible would allow the community to experiment using PHP in
areas where it doesn't fit right now. Having to wait 2 more years to
discover that maybe it's useful to build some new libraries could be a
waste of time at the tactical level (there are other technologies around
that move fast also :) )

Not to detract from the technical challenges of moving in this direction,
of course.
Just my 2cts from a "userland" guy :)

Nicolas

Hello everyone,

I agree with this sentiment and the general idea of shipping JIT as
experimental in 7.4 and required to build with a configure flag.
master for 8.0 is going to contain much more and be more unstable and not
practical for testing what JIT can do at that point due to all other
features and improvements going into it like additional optimizations and
platform support.
It will give me, as a userland developer, a platform where I can actually
play with it early and on a stable platform. And I understand what I'm
doing at that point.

I told, I'm not going to do any active JIT development at this point.
Why to waste time, if it's not going to be accepted...

At this point, nobody can imagine that PHP 8 will not have a JIT, there
is no sense in saying or thinking you would be wasting your time.

If you opened a vote for the JIT to be accepted in PHP 8, and committed to
making the improvements that everyone wants to see in the interim, the
vote would be more or less a formality, not really necessary at all,
because we all know what will happen.

I cannot stress enough that you would not be wasting your time to continue
developing the JIT. Saying "it's this or nothing" is not a very productive
or sensible thing to do at this point.

You must already know that yourself, Nikita, and Bob are really the only
active contributors that are qualified to talk about technical aspects of
the JIT, to improve it, to find or fix bugs. You must also understand that
given the time necessary things will change; You are employed, at least in
part, to work on PHP, and nobody else (afaik) except Nikita is: We have to
find time in our weekends and late at night to read things we're not
familiar with at all, I've never been good at assembly myself, and my
knowledge here is lacking. I look forward to improving my knowledge, I find
it exciting, but it will take a long time, many many weekends and nights,
and 7.4 is simply too early. Even Nikita and Bob are not comfortable enough
to make changes right now, but are still useful. What we're looking at
then, is a bus factor of 1, for about the next year, it may be as high as 3
or 4 by the time 7.4 is actually released. There's not 1000 people familiar
enough with the Zend of today to find, fix and improve PHP, but 3 or 4 is
just unreasonably low - this is the reason I say it's dangerous. My words
are not meant to be toxic, at all.

For the last two and a bit years, I've been focused on being a release
manager, and haven't spent a lot of time working on patches like I used
too, I'm still familiar with zend at a low level, but you've just made it
100x more complicated, and are twisting our arms to accept this additional
complexity, all the while saying you won't make improvements and don't have
time for other improvements that you've identified that would widen the
scope of the JIT considerably (ZTS), and lay the groundwork for supporting
other platforms (Windows).

7.3 was one of the worst releases for stability in recent years, and
regardless of whether you intend to disable the JIT by default, it's going
to be rolled out into production in whatever version of PHP it is merged
into, if what it is merged into is a production release of PHP, you can't
stop that with a configure switch or an INI setting, as has already been
pointed out by Nikita. Therefore, it's important that the JIT is actually
production ready and has a scope wide enough to justify the additional
complexity it brings to everything. I'm aware that you think switching the
JIT off is a solution to the tooling problems we clearly have, but it is
not a solution, people are going to expect their tools to work with it, and
saying "disable the JIT" or "disable opcache" to end users is unacceptable.
I realise you have more important things to do right now than to
concentrate on the issues that extension maintainers have, but it's obvious
that these issues need to be addressed before we push the JIT onto the
ecosystem. By withdrawing the suggestion of merging into 7.4, and focusing
our efforts on a really great PHP 8, you give yourself and all those
maintainers time to work together and find solutions to these problems that
are acceptable to us all, time we all desperately need. yourself included.
You also reduce your own workload considerably by not having to concentrate
on 7.4. You also take away the worry of another unstable release in the 7
series, which we cannot really afford to have if we don't want to damage
adoption rates of PHP 8.

Yesterday the suggestion of "preview" releases was made, previews of the
master branch, this is the best idea I have heard around deploying the JIT
to the world, those releases need not have a fixed schedule and in no sense
are production releases of PHP. I'll happily volunteer myself to do that
additional work and manage those releases while the 7.4 release managers
concentrate on a stable 7.4, I'm quite sure that past release managers will
help me there too. We can then nominate permanent managers for 8 as normal,
and I/we will hand over to them a reasonably stable, well tested JIT, that
many of us are comfortable diagnosing and pushing forward.

If you are interested in ZTS, you may invest time in implementation of
the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
if you start, because I may find time myself.

This is great to hear, but I've worked on the TSRM layer before, it was
myself that prepared for PHP 7 the original native-tls patch that was
proposed some time ago for PHP 5, subsequently Anatol had to do all the
heavy lifting, I understand it very well, but I'm not able to confidently
develop on Windows, just like you, I'm not that familiar with Windows.
Again, fixing these things are going to take time, and the effort of many
of us.

Time and commitment, is all I am asking for, without those my confidence
has evaporated, I'm sorry to say.

Cheers
Joe

Hi,

Morning all,

This idea of an experimental feature as complex as a JIT is dangerous. It
is not finished, and dmitry has said he's not willing to put more time
into
until it's merged. That's his prerogative, and it is ours to say that we
don't want unfinished software that only one or two people really
understand in PHP. All of the rest of internals need all of the time
between now and PHP 8 to educate ourselves on this so that we function as
well as we do now when it comes to finding and fixing bugs, and pushing
PHP
forward.

Few years ago I was claimed for development PHPNNG privately, but that
time we delivered to @internals almost completed solution. Now you don't
like the solution, because it's incomplete in your opinion (ZTS support,
etc), and the development makes troubles...

If you are interested in ZTS, you may invest time in implementation of
the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
if you start, because I may find time myself.

I told, I'm not going to do any active JIT development at this point.
Why to waste time, if it's not going to be accepted...
However, I keep it in sync with master and PHP-7.4, fix reported
problems, respond to code review comments, etc (just check git commits
history).

In last email I asked for ideas for RFC improvement (like notes about
unsupported ZTS). May be it makes sense to add cons/pros for additional
PHP-7.4 proposal. May be write something more clear (I'm not a native
speaker).

But this "a bit toxic" discussion, at least, steals time from
constructive things.

Merging the JIT into 7.4 puts a brick wall in the way of progress
that none of us have the tools to climb over.

I hear the argument about wanting to test, but anyone with sufficient
expertise to test the JIT is capable of building the branch available on
github, we do not need to push out an incomplete product to the entire
world for the sake of that handful of individuals who will actually test.

I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
current form, and would ask everyone to please think very carefully about
it, prior to supporting it.

[...] I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it),
but I
do think there's a reasonable case for both directions.

If I may add some voice to Zeev's arguments, being able to play with
JIT
as
early as possible would allow the community to experiment using PHP in
areas where it doesn't fit right now. Having to wait 2 more years to
discover that maybe it's useful to build some new libraries could be a
waste of time at the tactical level (there are other technologies
around
that move fast also :) )

Not to detract from the technical challenges of moving in this
direction,
of course.
Just my 2cts from a "userland" guy :)

Nicolas

Hello everyone,

I agree with this sentiment and the general idea of shipping JIT as
experimental in 7.4 and required to build with a configure flag.
master for 8.0 is going to contain much more and be more unstable and
not
practical for testing what JIT can do at that point due to all other
features and improvements going into it like additional optimizations
and
platform support.
It will give me, as a userland developer, a platform where I can
actually
play with it early and on a stable platform. And I understand what I'm
doing at that point.

I definitely don't think, I "just made it 100x more complicated".
I hate complication, and trying to make things simpler and more
efficient. This, sometime, involves new more or less isolated subsystems
like optimizer and now JIT. Of course, they look complex, if you are not
experienced in these areas. But PHP core may work without them.

Nobody will port their complex applications to PHP-8 preview, just to
try JIT. Having this possibility in PHP-7.4 would involve broader auditory.

Thanks. Dmitry.

Morning Dmitry,

I told, I'm not going to do any active JIT development at this point.
Why to waste time, if it's not going to be accepted...

At this point, nobody can imagine that PHP 8 will not have a JIT,
there is no sense in saying or thinking you would be wasting your time.

If you opened a vote for the JIT to be accepted in PHP 8, and committed
to making the improvements that everyone wants to see in the interim,
the vote would be more or less a formality, not really necessary at all,
because we all know what will happen.

I cannot stress enough that you would not be wasting your time to
continue developing the JIT. Saying "it's this or nothing" is not a very
productive or sensible thing to do at this point.

You must already know that yourself, Nikita, and Bob are really the only
active contributors that are qualified to talk about technical aspects
of the JIT, to improve it, to find or fix bugs. You must also understand
that given the time necessary things will change; You are employed, at
least in part, to work on PHP, and nobody else (afaik) except Nikita is:
We have to find time in our weekends and late at night to read things
we're not familiar with at all, I've never been good at assembly myself,
and my knowledge here is lacking. I look forward to improving my
knowledge, I find it exciting, but it will take a long time, many many
weekends and nights, and 7.4 is simply too early. Even Nikita and Bob
are not comfortable enough to make changes right now, but are still
useful. What we're looking at then, is a bus factor of 1, for about the
next year, it may be as high as 3 or 4 by the time 7.4 is actually
released. There's not 1000 people familiar enough with the Zend of today
to find, fix and improve PHP, but 3 or 4 is just unreasonably low - this
is the reason I say it's dangerous. My words are not meant to be toxic,
at all.

For the last two and a bit years, I've been focused on being a release
manager, and haven't spent a lot of time working on patches like I used
too, I'm still familiar with zend at a low level, but you've just made
it 100x more complicated, and are twisting our arms to accept this
additional complexity, all the while saying you won't make improvements
and don't have time for other improvements that you've identified that
would widen the scope of the JIT considerably (ZTS), and lay the
groundwork for supporting other platforms (Windows).

7.3 was one of the worst releases for stability in recent years, and
regardless of whether you intend to disable the JIT by default, it's
going to be rolled out into production in whatever version of PHP it is
merged into, if what it is merged into is a production release of PHP,
you can't stop that with a configure switch or an INI setting, as has
already been pointed out by Nikita. Therefore, it's important that the
JIT is actually production ready and has a scope wide enough to justify
the additional complexity it brings to everything. I'm aware that you
think switching the JIT off is a solution to the tooling problems we
clearly have, but it is not a solution, people are going to expect their
tools to work with it, and saying "disable the JIT" or "disable opcache"
to end users is unacceptable. I realise you have more important things
to do right now than to concentrate on the issues that extension
maintainers have, but it's obvious that these issues need to be
addressed before we push the JIT onto the ecosystem. By withdrawing the
suggestion of merging into 7.4, and focusing our efforts on a really
great PHP 8, you give yourself and all those maintainers time to work
together and find solutions to these problems that are acceptable to us
all, time we all desperately need. yourself included. You also reduce
your own workload considerably by not having to concentrate on 7.4. You
also take away the worry of another unstable release in the 7 series,
which we cannot really afford to have if we don't want to damage
adoption rates of PHP 8.

Yesterday the suggestion of "preview" releases was made, previews of the
master branch, this is the best idea I have heard around deploying the
JIT to the world, those releases need not have a fixed schedule and in
no sense are production releases of PHP. I'll happily volunteer myself
to do that additional work and manage those releases while the 7.4
release managers concentrate on a stable 7.4, I'm quite sure that past
release managers will help me there too. We can then nominate permanent
managers for 8 as normal, and I/we will hand over to them a reasonably
stable, well tested JIT, that many of us are comfortable diagnosing and
pushing forward.

If you are interested in ZTS, you may invest time in implementation of
the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
if you start, because I may find time myself.

This is great to hear, but I've worked on the TSRM layer before, it was
myself that prepared for PHP 7 the original native-tls patch that was
proposed some time ago for PHP 5, subsequently Anatol had to do all the
heavy lifting, I understand it very well, but I'm not able to
confidently develop on Windows, just like you, I'm not that familiar
with Windows. Again, fixing these things are going to take time, and the
effort of many of us.

Time and commitment, is all I am asking for, without those my confidence
has evaporated, I'm sorry to say.

Hi,
> Morning all,
>
> This idea of an experimental feature as complex as a JIT is
dangerous. It
> is not finished, and dmitry has said he's not willing to put more
time into
> until it's merged. That's his prerogative, and it is ours to say
that we
> don't want unfinished software that only one or two people really
> understand in PHP. All of the rest of internals need all of the time
> between now and PHP 8 to educate ourselves on this so that we
function as
> well as we do now when it comes to finding and fixing bugs, and
pushing PHP
> forward.
Few years ago I was claimed for development PHPNNG privately, but that
time we delivered to @internals almost completed solution. Now you
don't
like the solution, because it's incomplete in your opinion (ZTS
support,
etc), and the development makes troubles...
If you are interested in ZTS, you may invest time in implementation of
the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
if you start, because I may find time myself.
I told, I'm not going to do any active JIT development at this point.
Why to waste time, if it's not going to be accepted...
However, I keep it in sync with master and PHP-7.4, fix reported
problems, respond to code review comments, etc (just check git commits
history).
In last email I asked for ideas for RFC improvement (like notes about
unsupported ZTS). May be it makes sense to add cons/pros for additional
PHP-7.4 proposal. May be write something more clear (I'm not a native
speaker).
But this "a bit toxic" discussion, at least, steals time from
constructive things.
Joe, please, don't take anything personally.
Despite I wrote above, I appreciate your involvement in PHP development
and respect your opinion regarding JIT, ZTS. etc.
Thanks. Dmitry.
> Merging the JIT into 7.4 puts a brick wall in the way of progress
> that none of us have the tools to climb over.
>
> I hear the argument about wanting to test, but anyone with sufficient
> expertise to test the JIT is capable of building the branch
available on
> github, we do not need to push out an incomplete product to the
entire
> world for the sake of that handful of individuals who will
actually test.
>
> I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
> current form, and would ask everyone to please think very
carefully about
> it, prior to supporting it.
>
> Thanks
> Joe
>
>
> On Thu, 14 Feb 2019 at 14:34, Arvids Godjuks
<[email protected] <mailto:[email protected]>>
> wrote:
>
>> чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas
<[email protected] <mailto:nicolas.grekas%[email protected]>
>>> :
>>
>>>> [...] I think that whether or not we include it in 7.4
>>>> is a tactical decision (and I'm not sure myself where I stand
on it),
>>> but I
>>>> do think there's a reasonable case for both directions.
>>>>
>>>
>>> If I may add some voice to Zeev's arguments, being able to play
with JIT
>> as
>>> early as possible would allow the community to experiment using
PHP in
>>> areas where it doesn't fit right now. Having to wait 2 more
years to
>>> discover that maybe it's useful to build some new libraries
could be a
>>> waste of time at the tactical level (there are other
technologies around
>>> that move fast also :) )
>>>
>>> Not to detract from the technical challenges of moving in this
direction,
>>> of course.
>>> Just my 2cts from a "userland" guy :)
>>>
>>> Nicolas
>>>
>>
>> Hello everyone,
>>
>> I agree with this sentiment and the general idea of shipping JIT as
>> experimental in 7.4 and required to build with a configure flag.
>> master for 8.0 is going to contain much more and be more
unstable and not
>> practical for testing what JIT can do at that point due to all other
>> features and improvements going into it like additional
optimizations and
>> platform support.
>> It will give me, as a userland developer, a platform where I can
actually
>> play with it early and on a stable platform. And I understand
what I'm
>> doing at that point.
>>
>> --
>> Arvīds Godjuks
>>
>> +371 26 851 664
>> [email protected] <mailto:[email protected]>
>> Skype: psihius
>> Telegram: @psihius https://t.me/psihius

I definitely don't think, I "just made it 100x more complicated".
I hate complication, and trying to make things simpler and more
efficient. This, sometime, involves new more or less isolated subsystems
like optimizer and now JIT. Of course, they look complex, if you are not
experienced in these areas. But PHP core may work without them.

Nobody will port their complex applications to PHP-8 preview, just to
try JIT. Having this possibility in PHP-7.4 would involve broader
auditory.

The majority of people uses PHP from pre compiled sources (99%+),

With 7.4 there are just two options:

we add jit as a flag called --enable-experimental-jit - which no
distribution will do, and you don't have additional exposure with this
approach.

or you add it as --enable-jit, and distributions might assume its
stable and ship it by default, causing potential stability problems.

Both cases are not preferrable to 8.0 master snapshots in my opinion.

Well, for production you probably are not gonna use JIT anyway with 7.4, so
not really an issue about distributions. But we have docker, so if there is
a docker image with the JIT - we can use that for testing and local
development.

I definitely don't think, I "just made it 100x more complicated".
I hate complication, and trying to make things simpler and more
efficient. This, sometime, involves new more or less isolated subsystems
like optimizer and now JIT. Of course, they look complex, if you are not
experienced in these areas. But PHP core may work without them.

Nobody will port their complex applications to PHP-8 preview, just to
try JIT. Having this possibility in PHP-7.4 would involve broader auditory.

Thanks. Dmitry.

Perhaps I missed this part, but is "port to PHP 8-preview" or "port to JIT"
even a thing? Presumably, just like with 7.0, any reasonably well-behaved
application would be able to run without modification or with only minor
modification on 8.0, no?

I mean, if someone wanted to try out their massive application to see if the
JIT helped it, why would it be more work than (psuedocode):

Shouldn't we introduce annotations instead of relying on doc comments?

Yeah I'm not too happy with that approach either. I would rather see
another way to do this and like you said; annotations is probably the
best way to go about it as introducing a new keyword is not very
suitable imo.

Understanding and adoptions of annotations (Doctrine mainly afaics)
have change. I think it is tricky to define it in a way that it can be
useful and adopted as a core language feature, meaning being flexible
enough to be extendable and usable as a base for userland extensions.
That latter part is the biggest challenge. What do the actual
users/authors of the current userland implementation think? (pls other
thread? :)

Best,

Pierre

@pierrejoye

In the past few weeks i have been mainly using hack-lang and the attributes API has changed as of 3.29 ( https://hhvm.com/blog/2018/10/22/hhvm-3.29.html - change actually landed on 4.0 instead ) and i think its a good approach that php can take too.

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an experimental
feature.

Can you give some information on if there are pre-conditions that must
hold for a function to be jitted, or quit conditions that force the JIT to
be reverted for a function? In addition, it would be helpful for testing if
there was a way to find out if a function was jitted, maybe through
ReflectionMethod/Function or opcache_get_status() ?

And as a follow up, the JIT seems to affect zend_execute_ex and
zend_execute_internal based profiling (tested with tideways_xhprof) in a
way that all Jitted functions are not called through those two hooks
anymore, and don't appear in profiling data anymore. Is that a correct
description? The number of parent=>child call entries drops from 88 to 12
in my sample code when jit is activated.

Is that a desired side-effect?

Opening this tree of the discussion again with my research findings on JIT

production tracing.

I want to discuss a few ways forward:

Joe prototyped a solution how to instrument userland code that is JIT
compatible right now without php-src changes. It swaps zend_op_array with
an additional zend_internal_function wrapper acting as a decorator for each
entry in CG(function_table) that is instrumented. Code for this approach
can be found here: https://github.com/beberlei/php-overload-poc/ - but it
requires some more work, specifically Joe said it must be turned into a
zend_extension to get fully working.

This approach would help with extensions that currently instrument very
specific functions (mysqli_query, curl_exec, ....) such as tideways,
dd_trace, NewRelics (and other APM vendors).

Downside is it requires to overwrite debug_backtrace to filter out the
double frames and potentially has problems with the ReflectionFunction /
ReflectionMethod API having subtly different behaviors for internal and
userland functions. And this would probably lead to problems when multiple
extensiosn use the same approach.

It would not work with full function profilers such as Blackfire, php-spx,
that don't know the functions they instrument, instrument all the
functions. I don't include xdebug in that list, because it is mostly used
in non production evnironments that don't use the JIT, but the other
profilers are explicitly for production usage.

It would also not work with extensions that allow developers to instrument
class+methods / functions at runtime, such as dd_trace [1] and tideways

Another approach could be to generalize this approach
stackdriver-debugger [2] has by modifying the AST to include the profiling
code. But having additional internal fucntion calls "profiler_start" +
"profiler_stop" there would have a lot more overhead than execute_ex
wrappers currently do. Alternatively the engine could introduce new opcodes
for enter/leave tracing that directly translate to a C call to newly
created hooks and could also get JIT support.

This could be generalized to the point where php-src provides the code for
the ast injection so that extensions could just re-use it. I think this
would be the cleanest approach.

Separating execute_ex from the desire to do tracing would be possible if
we introduce a new hook "zend_trace_function(int enterOrExit, const char
*class_name, const char *function_name, zval *args, zval *returnValue);" .
I am not sure if the JIT could actually call this hook, probably not
because args and returnValue might not be in zval representation. I haven't
looked this deeply into the JIT yet.

As a benefit this new hook would prevent tracing/profiling extensions from
forcing the VM to generate the more inefficient opcodes for function calls
by overwriting zend_execute_ex

A last solution for the specific function instrumentation (not feasible
for generic profilers though) would be an API to register functions that
extensions consider "@nojit" which extensions could do on MINIT:

This does not bring PHP to the level of performance where you could
reasonably implement, say, interpolated image resampling or a JPEG
decoder/encoder, correct?

This is still orders of magnitude slower than C, am I wrong?

Please don't think that I'm trying to shit on anybody's hard work, and
forgive me for asking, but how much maintenance overhead does the JIT add
to the language going forward?

Will this significantly slow down the development of every new language
feature?

If not, then by all means, please continue :-)

But if this is adding substantial maintenance overhead or significantly
increasing the barrier for contributions, I'd say, think very carefully
about this.

Developers are not picking a dynamic scripting language for the excellent
performance, unless we're talking near-C level performance (e.g. Lua-JIT
and, to my knowledge, not much else) and I don't get the impression this is
anywhere in that neighborhood?

Again, really not trying to bring down this very impressive piece of work -
but, as with any new language feature, we need to weigh complexity against
benefits, and I'm not convinced this kind of speed-up really opens PHP to
any new use-cases?

Being faster is always nice, but unless it's actually "fast", by which I
mean "fast enough to enable doing something new", it's only nice - it's not
necessarily a must.

For example, if this doesn't rival the performance of, say, WASM,
integration of a WASM engine might be a more worth while pursuit in the
long term.

Just wondering.

Please try not to see this post as aggressive or negative - I just hope
we're entering into such a major language change with eyes open? :-)

Hi Internals,
The RFC and implementation was updated once again.
https://wiki.php.net/rfc/jit
Now JIT supports PHP builds with compilers without GCC explicit
global register variables extension.
This means we support CLANG/LLVM (Tested on Linux. Should work on
Mac as well) and MSVC.
Complete Windows support is not implemented yet, but I don't see any
big problems anymore.
ZTS support might be implemented after implementation of proposed
TSRM API improvement.
Thanks. Dmitry.
________________________________
From: Dmitry Stogov <[email protected] <mailto:[email protected]>>
Sent: Wednesday, February 13, 2019 16:07
To: PHP internals
Subject: Re: [PHP-DEV] [RFC] JIT
Hi Internals,
According to comments, code reviews and discussions, JIT RFC was
extended with few new sections.
Please, consider to review the RFC once again.
https://wiki.php.net/rfc/jit
Any suggestion for RFC improvement are welcome.
I'm not going to invest significant time into JIT implementation
improvement itself, at this point. So, ideas are also welcome, but don't
expect to get them implemented tomorrow.
Thanks. Dmitry.
> Hi Internals,
>
>
> I'm glad to finally propose including JIT into PHP.
>
>
> https://wiki.php.net/rfc/jit
>
>
> In the current state it may be included both into PHP-8, where we are
> going to continue active improvement, and into PHP-7.4, as an
> experimental feature.
>
>
> Thanks. Dmitry.

Thanks to Anatol, who started working on Windows build and "enforced" me
to implement MSVC support :)

Owing to Dmitry's great work on this, the Windows part is now in a very good shape. Zend/bench.php shows at least 4x better performance with Opcache+JIT vs. just Opcache on current master. A dev snapshot x64/NTS of the today's jit-dynasm branch are available here

Hi Internals,
The RFC and implementation was updated once again.
https://wiki.php.net/rfc/jit
Now JIT supports PHP builds with compilers without GCC explicit
global register variables extension.
This means we support CLANG/LLVM (Tested on Linux. Should work on
Mac as well) and MSVC.
Complete Windows support is not implemented yet, but I don't see any
big problems anymore.
ZTS support might be implemented after implementation of proposed
TSRM API improvement.
Thanks. Dmitry.
________________________________
From: Dmitry Stogov <[email protected] <mailto:[email protected]>>
Sent: Wednesday, February 13, 2019 16:07
To: PHP internals
Subject: Re: [PHP-DEV] [RFC] JIT
Hi Internals,
According to comments, code reviews and discussions, JIT RFC was
extended with few new sections.
Please, consider to review the RFC once again.
https://wiki.php.net/rfc/jit
Any suggestion for RFC improvement are welcome.
I'm not going to invest significant time into JIT implementation
improvement itself, at this point. So, ideas are also welcome, but don't
expect to get them implemented tomorrow.
Thanks. Dmitry.
> Hi Internals,
>
>
> I'm glad to finally propose including JIT into PHP.
>
>
> https://wiki.php.net/rfc/jit
>
>
> In the current state it may be included both into PHP-8, where we are
> going to continue active improvement, and into PHP-7.4, as an
> experimental feature.
>
>
> Thanks. Dmitry.

Thanks to Anatol, who started working on Windows build and "enforced"
me to implement MSVC support :)

Owing to Dmitry's great work on this, the Windows part is now in a very
good shape. Zend/bench.php shows at least 4x better performance with
Opcache+JIT vs. just Opcache on current master. A dev snapshot x64/NTS of
the today's jit-dynasm branch are available here

Hi Internals,
The RFC and implementation was updated once again.
https://wiki.php.net/rfc/jit
Now JIT supports PHP builds with compilers without GCC explicit
global register variables extension.
This means we support CLANG/LLVM (Tested on Linux. Should work on
Mac as well) and MSVC.
Complete Windows support is not implemented yet, but I don't see any
big problems anymore.
ZTS support might be implemented after implementation of proposed
TSRM API improvement.
Thanks. Dmitry.
________________________________
From: Dmitry Stogov <[email protected] <mailto:[email protected]>>
Sent: Wednesday, February 13, 2019 16:07
To: PHP internals
Subject: Re: [PHP-DEV] [RFC] JIT
Hi Internals,
According to comments, code reviews and discussions, JIT RFC was
extended with few new sections.
Please, consider to review the RFC once again.
https://wiki.php.net/rfc/jit
Any suggestion for RFC improvement are welcome.
I'm not going to invest significant time into JIT implementation
improvement itself, at this point. So, ideas are also welcome, but don't
expect to get them implemented tomorrow.
Thanks. Dmitry.
> Hi Internals,
>
>
> I'm glad to finally propose including JIT into PHP.
>
>
> https://wiki.php.net/rfc/jit
>
>
> In the current state it may be included both into PHP-8, where we are
> going to continue active improvement, and into PHP-7.4, as an
> experimental feature.
>
>
> Thanks. Dmitry.

I guess this would be one benefit to having the JIT be an experimental
feature in PHP 7.4 - extensions will likely support it long before
they support PHP 8 which will make it possible to test a lot more
real-world use cases.

I guess this would be one benefit to having the JIT be an experimental
feature in PHP 7.4 - extensions will likely support it long before they support
PHP 8 which will make it possible to test a lot more real-world use cases.

Thanks for sharing this! Once the required extension becomes available, a snapshot could be created for the further tests. Otherwise I had Wordpress running and several other simple apps, so those can be used for the tests, too.

Now JIT also supports ZTS (checked on Linux and Windows).
Please, test and report problems.

So, complains about JIT compatibility matrix are satisfied.
It should be some incompatibilities with ZTS on Mac, but this easily
fixable.

I'll spend some additional time on code cleanup, and then start voting.

Ideas for RFC and code improvement are welcome.

I think this can still be done post RFC, but I am still very keen on
solving the tracing issue with a new unified API that:

avoids zend_execute overwrites (to keep a stackless VM)

works with VM and JIT

works with internal and userland functions

maybe allows some control for extension developers to run only on a
selective number of calls (this can be implemented with AST processor and
internal function handler overwrites).

has access to arguments and return value

And an API in either reflection or opcache to find out which
functions/methods are jitted would also be helpful.
Testing with the jit branch currently its very hard to verify that it
actually works without turning debug output on.