Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] JIT »

[RFC] JIT

php.internals

Dmitry Stogov

7 years ago
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.

Albert Casademont Filella

7 years ago
Hi all, 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! Best, On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com> wrote:

Dmitry Stogov

7 years ago
On 1/31/19 1:15 PM, Albert Casademont wrote:
> Hi all, > > 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!
Better to try and provide feedback right now. You can get sources and build PHP from the link in RFC. https://github.com/zendtech/php-src/ Thanks. Dmitry.

Marcos Passos

7 years ago
JIT, FFI, covariant return types and typed properties: what a year for PHP. Thank you all for working on making PHP better and better. - Marcos Em qui, 31 de jan de 2019 às 08:54, Dmitry Stogov <dmitry@zend.com> escreveu:

Benjamin Morel

7 years ago
Just want to say that this is HUGE, thanks so much for the work done here, can't wait to try it out, hopefully this will land in PHP 7.4! Ben On Thu, 31 Jan 2019 at 10:44, Dmitry Stogov <dmitry@zend.com> wrote:

Nikita Popov

7 years ago
On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com> 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. >
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

Dmitry Stogov

7 years ago
On 1/31/19 7:01 PM, Nikita Popov wrote:
> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com > <mailto:dmitry@zend.com>> 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. > > > 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.
XDebug may work with JIT or opcache disabled.
> > I think those are the main points that come to mind right now...
Anyway, I'm mostly agree with all the points. There are two options :) - take the challenge and start developing JIT together - forget about JIT, because we are afraid Thanks. Dmitry.

Kalle Sommer Nielsen

7 years ago
Den tor. 31. jan. 2019 kl. 18.39 skrev Dmitry Stogov <dmitry@zend.com>:
> > > > On 1/31/19 7:01 PM, Nikita Popov wrote: > > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com > > <mailto:dmitry@zend.com>> 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. > > > > > > 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.
-- regards, Kalle Sommer Nielsen kalle@php.net

Zeev Suraski

7 years ago
On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen <kalle@php.net> 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? 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. Zeev

Chase Peeler

7 years ago
On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski <zeev@php.net> wrote:
> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen <kalle@php.net> > 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.
> 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. > > Zeev >
-- -- Chase chasepeeler@gmail.com

Larry Garfield

7 years ago
On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote:
> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski <zeev@php.net> wrote: > > On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen <kalle@php.net> > > > > 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. 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

Dmitry Stogov

7 years ago
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 <zeev@php.net> wrote: >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen <kalle@php.net> >>> >>> 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.

Joe Watkins

7 years ago
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'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. 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 <dmitry@zend.com> wrote:

Dmitry Stogov

7 years ago
On 2/1/19 11:55 AM, Joe Watkins wrote:
> 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'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.

Larry Garfield

7 years ago
On Friday, February 1, 2019 2:41:06 AM CST Dmitry Stogov wrote:
> On 2/1/19 3:29 AM, Larry Garfield wrote:
> > 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? --Larry Garfield

Zeev Suraski

7 years ago
On 1 Feb 2019, at 18:30, Larry Garfield <larry@garfieldtech.com<mailto:larry@garfieldtech.com>> wrote: 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: 1. 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. 2. 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. Zeev

Dmitry Stogov

7 years ago
On 2/1/19 7:30 PM, Larry Garfield wrote:
> On Friday, February 1, 2019 2:41:06 AM CST Dmitry Stogov wrote: >> On 2/1/19 3:29 AM, Larry Garfield wrote: > >>> 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. Thanks. Dmitry.

Kalle Sommer Nielsen

7 years ago
Den tor. 31. jan. 2019 kl. 19.04 skrev Zeev Suraski <zeev@php.net>:
> 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).
-- regards, Kalle Sommer Nielsen kalle@php.net

Ben Ramsey

7 years ago
On Thu, Jan 31, 2019, at 11:04, Zeev Suraski wrote:
> 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. -Ben

Zeev Suraski

7 years ago
> On 3 Feb 2019, at 7:17, Ben Ramsey <ben@benramsey.com> wrote: > >> On Thu, Jan 31, 2019, at 11:04, Zeev Suraski wrote: >> 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. Zeev

Lester Caine

7 years ago
On 03/02/2019 06:51, Zeev Suraski wrote:
>> 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.
-- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

Andrey Hristov

7 years ago
Hi, On 31.01.19 г. 18:47 ч., Kalle Sommer Nielsen wrote:
> Den tor. 31. jan. 2019 kl. 18.39 skrev Dmitry Stogov <dmitry@zend.com>: >> >> >> >> On 1/31/19 7:01 PM, Nikita Popov wrote: >>> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com >>> <mailto:dmitry@zend.com>> 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. >>> >>> >>> 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. >
Best, Andrey

Pierre Joye

7 years ago
On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov <dmitry@zend.com wrote:
> > > I don't see any problems with including JIT without Windows support. > Windows runs PHP much slower any way. >
How so? I tend to disagree here. Except if recent changes affect Windows indirectly (as in optimization done on linux only). 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.

Andrey Hristov

7 years ago
Pierre, On 1.02.19 г. 13:12 ч., Pierre Joye wrote:
> On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov <dmitry@zend.com wrote: > >> >> >> I don't see any problems with including JIT without Windows support. >> Windows runs PHP much slower any way. >> > > How so? I tend to disagree here. Except if recent changes affect Windows > indirectly (as in optimization done on linux only). > > 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 :)
>> >
Cheers, Andrey

Andi Gutmans

7 years ago
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. Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Andrey Hristov <php@hristov.com> Sent: Friday, February 1, 2019 3:49 AM To: Pierre Joye Cc: PHP internals Subject: Re: [PHP-DEV] [RFC] JIT Pierre, On 1.02.19 г. 13:12 ч., Pierre Joye wrote:
> On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov <dmitry@zend.com wrote: > >> >> >> I don't see any problems with including JIT without Windows support. >> Windows runs PHP much slower any way. >> > > How so? I tend to disagree here. Except if recent changes affect Windows > indirectly (as in optimization done on linux only). > > 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 :)
>> >
Cheers, Andrey
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Dmitry Stogov

7 years ago
On 2/1/19 2:12 PM, Pierre Joye wrote:
> > > On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov <dmitry@zend.com > <mailto:dmitry@zend.com> wrote: > > > > I don't see any problems with including JIT without Windows support. > Windows runs PHP much slower any way. > > > How so? I tend to disagree here. Except if recent changes affect Windows > indirectly (as in optimization done on linux only).
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. Thanks. Dmitry.

Levi Morrison

7 years ago
On Thu, Jan 31, 2019 at 9:01 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
> > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com> 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. > > > > 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.

Pierre Joye

7 years ago
On Sat, Feb 2, 2019, 12:46 AM Levi Morrison 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.
It must some changes needed for php or simply lack of time to test on MSVC. LibJit and DynAsm support it As

Derick Rethans

7 years ago
On Thu, 31 Jan 2019, Dmitry Stogov wrote:
> I'm glad to finally propose including JIT into PHP. > > https://wiki.php.net/rfc/jit
I don't see anywhere in this RFC how it would affect thigns that do sneaky things with internals, such as Xdebug. How is that going to be affected?
> 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.
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. cheers, Derick
-- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php, or become my Patron: https://www.patreon.com/derickr twitter: @derickr and @xdebug

Dmitry Stogov

7 years ago
On 1/31/19 8:08 PM, Derick Rethans wrote:
> On Thu, 31 Jan 2019, Dmitry Stogov wrote: > >> I'm glad to finally propose including JIT into PHP. >> >> https://wiki.php.net/rfc/jit > > I don't see anywhere in this RFC how it would affect thigns that do > sneaky things with internals, such as Xdebug. How is that going to be > affected? >
I suppose Xdebug should work on non-JIT-ed versions of the functions. Even JVM deoptimizes to bytecode when debugging. Thanks. Dmitry.

Derick Rethans

7 years ago
On Thu, 31 Jan 2019, Dmitry Stogov wrote:
> > > On 1/31/19 8:08 PM, Derick Rethans wrote: > > On Thu, 31 Jan 2019, Dmitry Stogov wrote: > > > >> I'm glad to finally propose including JIT into PHP. > >> > >> https://wiki.php.net/rfc/jit > > > > I don't see anywhere in this RFC how it would affect thigns that do > > sneaky things with internals, such as Xdebug. How is that going to be > > affected? > > > > I suppose Xdebug should work on non-JIT-ed versions of the functions. > Even JVM deoptimizes to bytecode when debugging.
So, in that case, I think I would need to be able to instruct the PHP JIT engine to be turned off. Perhaps through an API? Similarly, I think it might be useful for OPcache as well, as I am getting more people confused why some breakpoints don't work, or variables don't exist: https://bugs.xdebug.org/view.php?id=1609 cheers, Derick

Dmitry Stogov

7 years ago
On 1/31/19 9:12 PM, Derick Rethans wrote:
> On Thu, 31 Jan 2019, Dmitry Stogov wrote: > >> >> >> On 1/31/19 8:08 PM, Derick Rethans wrote: >>> On Thu, 31 Jan 2019, Dmitry Stogov wrote: >>> >>>> I'm glad to finally propose including JIT into PHP. >>>> >>>> https://wiki.php.net/rfc/jit >>> >>> I don't see anywhere in this RFC how it would affect thigns that do >>> sneaky things with internals, such as Xdebug. How is that going to be >>> affected? >>> >> >> I suppose Xdebug should work on non-JIT-ed versions of the functions. >> Even JVM deoptimizes to bytecode when debugging. > > So, in that case, I think I would need to be able to instruct the PHP > JIT engine to be turned off. Perhaps through an API? > > Similarly, I think it might be useful for OPcache as well,
Use zend_alter_ini_entry() to set "opcache.enable" to "0". Better to do it at RINIT. Thanks. Dmitry.

Sebastian Bergmann

7 years ago
Am 31.01.2019 um 18:08 schrieb Derick Rethans:
> 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

Zeev Suraski

7 years ago
On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann <sebastian@php.net> wrote:
> Am 31.01.2019 um 18:08 schrieb Derick Rethans: > > 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. Zeev

Rowan Collins

7 years ago
On Thu, 14 Feb 2019 at 09:43, Zeev Suraski <zeev@php.net> wrote:
> 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,
-- Rowan Collins [IMSoP]

Zeev Suraski

7 years ago
On Thu, Feb 14, 2019 at 12:17 PM Rowan Collins <rowan.collins@gmail.com> wrote:
> On Thu, 14 Feb 2019 at 09:43, Zeev Suraski <zeev@php.net> wrote: > >> 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. Zeev

Nicolas Grekas

7 years ago
> [...] 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

Arvids Godjuks

7 years ago
чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas <nicolas.grekas+php@gmail.com>:
> > [...] 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 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius

Joe Watkins

7 years ago
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. 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 <arvids.godjuks@gmail.com> wrote:

Dmitry Stogov

7 years ago
Hi, On 2/14/19 5:22 PM, Joe Watkins wrote:
> 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.

Rowan Collins

7 years ago
On Thu, 14 Feb 2019 at 13:34, Arvids Godjuks <arvids.godjuks@gmail.com> wrote:
> 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,
-- Rowan Collins [IMSoP]

Nikita Popov

7 years ago
On Thu, Feb 14, 2019 at 10:43 AM Zeev Suraski <zeev@php.net> wrote:
> On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann <sebastian@php.net> > wrote: > > > Am 31.01.2019 um 18:08 schrieb Derick Rethans: > > > 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). Nikita

Zeev Suraski

7 years ago
On Thu, Feb 14, 2019 at 12:19 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Thu, Feb 14, 2019 at 10:43 AM Zeev Suraski <zeev@php.net> wrote: > > > On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann <sebastian@php.net> > > wrote: > > > > > Am 31.01.2019 um 18:08 schrieb Derick Rethans: > > > > 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. Zeev

Dmitry Stogov

7 years ago
On 2/14/19 2:38 PM, Zeev Suraski wrote:
> On Thu, Feb 14, 2019 at 12:19 PM Nikita Popov <nikita.ppv@gmail.com> wrote: >> On Thu, Feb 14, 2019 at 10:43 AM Zeev Suraski <zeev@php.net> wrote: >>> On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann <sebastian@php.net>
>> * 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... Thanks. Dmitry.

Nikita Popov

7 years ago
On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com> 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 git@github.com: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). Nikita

Nikita Popov

7 years ago
On Fri, Feb 1, 2019 at 1:09 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com> 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 git@github.com: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). > > Nikita >
Another project that I would like to test is amp (git@github.com: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: 1) Amp\Test\AllTest::testPendingPromiseArray TypeError: Return value of Amp\Loop\Internal\TimerQueue::removeAndRebuild() must be an instance of Amp\Loop\Internal\TimerQueueEntry, null returned /home/nikic/amp/lib/Loop/Internal/TimerQueue.php:100 /home/nikic/amp/lib/Loop/Internal/TimerQueue.php:64 /home/nikic/amp/lib/Loop/NativeDriver.php:107 /home/nikic/amp/lib/Loop/Driver.php:134 /home/nikic/amp/lib/Loop/Driver.php:72 /home/nikic/amp/lib/Loop.php:84 /home/nikic/amp/test/AllTest.php:52 Here is the line that incorrectly gets a null: https://github.com/amphp/amp/blob/c6f8425473ecc1cfc6909cf42b39abb39a11c837/lib/Loop/Internal/TimerQueue.php#L100 Nikita

Dmitry Stogov

7 years ago
On 2/1/19 3:09 PM, Nikita Popov wrote:
> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com > <mailto:dmitry@zend.com>> 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 git@github.com: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. Thanks. Dmitry.

Dmitry Stogov

7 years ago
On 2/1/19 4:23 PM, Dmitry Stogov wrote:
> > > On 2/1/19 3:09 PM, Nikita Popov wrote: >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com >> <mailto:dmitry@zend.com>> 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 git@github.com: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.

Nikita Popov

7 years ago
On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov <dmitry@zend.com> wrote:
> > > On 2/1/19 4:23 PM, Dmitry Stogov wrote: > > > > > > On 2/1/19 3:09 PM, Nikita Popov wrote: > >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com > >> <mailto:dmitry@zend.com>> 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 git@github.com: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. Nikita

Dmitry Stogov

7 years ago
On 2/4/19 5:44 PM, Nikita Popov wrote:
> On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov <dmitry@zend.com > <mailto:dmitry@zend.com>> wrote: > > > > On 2/1/19 4:23 PM, Dmitry Stogov wrote: > > > > > > On 2/1/19 3:09 PM, Nikita Popov wrote: > >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com > <mailto:dmitry@zend.com> > >> <mailto:dmitry@zend.com <mailto:dmitry@zend.com>>> 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 git@github.com: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). Thanks. Dmitry.

Nikita Popov

7 years ago
On Mon, Feb 4, 2019 at 4:11 PM Dmitry Stogov <dmitry@zend.com> wrote:
> > > On 2/4/19 5:44 PM, Nikita Popov wrote: > > On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov <dmitry@zend.com > > <mailto:dmitry@zend.com>> wrote: > > > > > > > > On 2/1/19 4:23 PM, Dmitry Stogov wrote: > > > > > > > > > On 2/1/19 3:09 PM, Nikita Popov wrote: > > >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com > > <mailto:dmitry@zend.com> > > >> <mailto:dmitry@zend.com <mailto:dmitry@zend.com>>> 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 git@github.com: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: git clone git@github.com:amphp/hpack.git cd hpack composer install php-jit vendor/bin/phpunit Nikita

Dmitry Stogov

7 years ago
On 2/4/19 6:22 PM, Nikita Popov wrote:
> On Mon, Feb 4, 2019 at 4:11 PM Dmitry Stogov <dmitry@zend.com > <mailto:dmitry@zend.com>> wrote: > > > > On 2/4/19 5:44 PM, Nikita Popov wrote: > > On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov <dmitry@zend.com > <mailto:dmitry@zend.com> > > <mailto:dmitry@zend.com <mailto:dmitry@zend.com>>> wrote: > > > > > > > >     On 2/1/19 4:23 PM, Dmitry Stogov wrote: > >      > > >      > > >      > On 2/1/19 3:09 PM, Nikita Popov wrote: > >      >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov > <dmitry@zend.com <mailto:dmitry@zend.com> > >     <mailto:dmitry@zend.com <mailto:dmitry@zend.com>> > >      >> <mailto:dmitry@zend.com <mailto:dmitry@zend.com> > <mailto:dmitry@zend.com <mailto:dmitry@zend.com>>>> 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 git@github.com: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: > > git clone git@github.com:amphp/hpack.git > cd hpack > composer install > php-jit vendor/bin/phpunit > > Nikita
Fixed.

Nikita Popov

7 years ago
On Mon, Feb 4, 2019 at 3:44 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov <dmitry@zend.com> wrote: > >> >> >> On 2/1/19 4:23 PM, Dmitry Stogov wrote: >> > >> > >> > On 2/1/19 3:09 PM, Nikita Popov wrote: >> >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com >> >> <mailto:dmitry@zend.com>> 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 git@github.com: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 :) >
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): PHP: 3.7s PHP+optimizer: 3.2s PHP+optimizer+JIT: 2.4s So the speedup is ~1.3x rather than ~1.5x, which is still good. I also ran the hello-world.php example of https://github.com/amphp/http-server against wrk -c100 -d30 -t4 and got the following results: PHP: 9950 rps PHP+optimizer: 10750 rps PHP+optimizer+JIT: 11350 rps So in this case the improvement is about 5%. (This is the HTTP 1.1 server, HTTP 2 would also be interesting to try, but needs some more setup.) Nikita

Weirdan

7 years ago
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). PHP+optimizer (-dopcache.jit_buffer_size=0): 32.29s (100%) PHP+optimizer+JIT (-dopcache.jit_buffer_size=50000000): 30.72s (95.1%) PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=50000000 -dopcache.jit=1201): 29.95s (92.7%)

Dmitry Stogov

7 years ago
On 2/4/19 11:39 PM, Bruce Weirdan wrote:
> After figuring out that opcache.jit_buffer_size is specified in bytes > (not in megabytes, as RFC states)
Thanks for catching this. Fixed.
> I got ~5% speedup running > vimeo/psalm (static analyzer) on its own codebase with default > JIT flags and ~7.3% with minimal JIT (1201). > > PHP+optimizer (-dopcache.jit_buffer_size=0): 32.29s (100%) > PHP+optimizer+JIT (-dopcache.jit_buffer_size=50000000): 30.72s (95.1%) > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=50000000 > -dopcache.jit=1201): 29.95s (92.7%) >
It may be interesting to try -dopcache.jit=1235. It should JIT only hot functions and requires some warm-up. Thanks. Dmitry.

Weirdan

7 years ago
On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov <dmitry@zend.com> wrote:
> > PHP+optimizer (-dopcache.jit_buffer_size=0): 32.29s (100%) > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=50000000): 30.72s (95.1%) > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=50000000 > > -dopcache.jit=1201): 29.95s (92.7%) > > It may be interesting to try -dopcache.jit=1235. It should JIT only hot > functions and requires some warm-up.
For this use case 1201 was the fastest of all the options I tried (including 1235).

Eugene Leonovich

7 years ago
On Tue, Feb 5, 2019 at 6:06 PM Bruce Weirdan <weirdan@gmail.com> wrote:
> On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov <dmitry@zend.com> wrote: > > > PHP+optimizer (-dopcache.jit_buffer_size=0): 32.29s (100%) > > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=50000000): 30.72s (95.1%) > > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=50000000 > > > -dopcache.jit=1201): 29.95s (92.7%) > > > > It may be interesting to try -dopcache.jit=1235. It should JIT only hot > > functions and requires some warm-up. > > For this use case 1201 was the fastest of all the options I tried > (including 1235). > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Here are my results of benchmarking rybakit/msgpack.php: bench.php, w/o jit: Total 9.8220 4.3121 bench.php, opcache.jit=1235 opcache.jit_buffer_size=256M: Total 8.7255 3.3350 bench2.php, w/o jit: pure msgpack: 2.2818 sec pure msgpack packed: 2.1717 sec bench2.php, opcache.jit=1235 opcache.jit_buffer_size=256M: pure msgpack: 1.5221 sec pure msgpack packed: 1.4739 sec Details: https://gist.github.com/rybakit/bb551f962b706a9e08c995cf5ed9762f
-- Thank you and best regards, Eugene Leonovich

Andrew Faulds

7 years ago
Dmitry Stogov 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. >
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. Thanks, Andrea

Benjamin Eberlei

7 years ago
On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com> 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? 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() ?

Benjamin Eberlei

7 years ago
On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei <kontakt@beberlei.de> wrote:
> > > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com> 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? 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?

Dmitry Stogov

7 years ago
On 2/5/19 1:48 AM, Benjamin Eberlei wrote:
> > > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei <kontakt@beberlei.de > <mailto:kontakt@beberlei.de>> wrote: > > > > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com > <mailto:dmitry@zend.com>> 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). $ perf record php -d opcache.huge_code_pages=0 -d opcache.jit_debug=0x10 bench.php $ perf report Thanks. Dmitry.

Benjamin Eberlei

7 years ago
On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov <dmitry@zend.com> wrote:
> > > On 2/5/19 1:48 AM, Benjamin Eberlei wrote: > > > > > > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei <kontakt@beberlei.de > > <mailto:kontakt@beberlei.de>> wrote: > > > > > > > > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com > > <mailto:dmitry@zend.com>> 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). > > $ perf record php -d opcache.huge_code_pages=0 -d opcache.jit_debug=0x10 > bench.php > $ perf report >
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.

Dmitry Stogov

7 years ago
On 2/5/19 12:40 PM, Benjamin Eberlei wrote:
> > > On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov <dmitry@zend.com > <mailto:dmitry@zend.com>> wrote: > > > > On 2/5/19 1:48 AM, Benjamin Eberlei wrote: > > > > > > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei > <kontakt@beberlei.de <mailto:kontakt@beberlei.de> > > <mailto:kontakt@beberlei.de <mailto:kontakt@beberlei.de>>> wrote: > > > > > > > >     On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov > <dmitry@zend.com <mailto:dmitry@zend.com> > >     <mailto:dmitry@zend.com <mailto:dmitry@zend.com>>> 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.
It's easily possible to disable JIT-ing by implementing @nojit (it's pity, we didn't get attributes). Thanks. Dmitry.

Benjamin Eberlei

7 years ago
On Tue, Feb 5, 2019 at 11:45 AM Dmitry Stogov <dmitry@zend.com> wrote:
> > > On 2/5/19 12:40 PM, Benjamin Eberlei wrote: > > > > > > On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov <dmitry@zend.com > > <mailto:dmitry@zend.com>> wrote: > > > > > > > > On 2/5/19 1:48 AM, Benjamin Eberlei wrote: > > > > > > > > > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei > > <kontakt@beberlei.de <mailto:kontakt@beberlei.de> > > > <mailto:kontakt@beberlei.de <mailto:kontakt@beberlei.de>>> wrote: > > > > > > > > > > > > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov > > <dmitry@zend.com <mailto:dmitry@zend.com> > > > <mailto:dmitry@zend.com <mailto:dmitry@zend.com>>> 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. >
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. > > It's easily possible to disable JIT-ing by implementing @nojit (it's > pity, we didn't get attributes). >
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. ZEND_API extern int (*opcache_jit_accept_handler)(zend_string *class_name, zend_string *function_name); Then i can overwrite it in my own extension: int tideways_jit_accept_handler(zend_string *class_name, zend_string *function_name) { if (zend_hash_key_exists(TRG(callbacks), class_name)) { return DENY; } if (!class_name && zend_hash_key_exists(TRG(callbacks), function_name)) { return DENY; } return original_jit_accept_handler(class_name, function_name); } Problem with this hook would be that it needed to be available in Zend/ and not in ext-opcache so i can trust this global variable to exist in every compile such as zend_execute_ex.

Niklas Keller

7 years ago
> > 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.
Shouldn't we introduce annotations instead of relying on doc comments? Regards, Niklas

Kalle Sommer Nielsen

7 years ago
Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller <me@kelunik.com>:
> 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.
-- regards, Kalle Sommer Nielsen kalle@php.net

Dmitry Stogov

7 years ago
On 2/5/19 10:31 PM, Kalle Sommer Nielsen wrote:
> Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller <me@kelunik.com>: >> 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. >
Attributes were proposed ~3 years ago. https://wiki.php.net/rfc/attributes There were few other releted proposals. But they didn't pass. Thanks. Dmitry.

Pierre Joye

7 years ago
On Wed, Feb 6, 2019 at 3:17 PM Dmitry Stogov <dmitry@zend.com> wrote:
> On 2/5/19 10:31 PM, Kalle Sommer Nielsen wrote: > > Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller <me@kelunik.com>: > >> 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. > > > > Attributes were proposed ~3 years ago. > > https://wiki.php.net/rfc/attributes > > There were few other releted proposals. > But they didn't pass.
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

azjezz

7 years ago
Hello internals. Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, February 6, 2019 9:23 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> On Wed, Feb 6, 2019 at 3:17 PM Dmitry Stogov dmitry@zend.com wrote: > > > On 2/5/19 10:31 PM, Kalle Sommer Nielsen wrote: > > > > > Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller me@kelunik.com: > > > > > > > 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. > > > > Attributes were proposed ~3 years ago. > > https://wiki.php.net/rfc/attributes > > There were few other releted proposals. > > But they didn't pass. > > 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 > > -------------------- > > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
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. I have no experience with C so i don't know how this would work out for PHP, but i made a gist with a simple example on how it would be in : https://gist.github.com/azjezz/918e333646d4f4070ab0be4cb41a81de

Benjamin Eberlei

7 years ago
On Mon, Feb 4, 2019 at 11:48 PM Benjamin Eberlei <kontakt@beberlei.de> wrote:
> > > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei <kontakt@beberlei.de> > wrote: > >> >> >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com> 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? 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: 1. 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 2. 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. 3. 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 4. 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: opcache_jit_mark_nojit_func("my_function"); opcache_jit_mark_nojit_method("MyClass", "method"); This would allow extensions to always see these calls in zend_execute_ex callbacks. @Dmitry: What do you think about a path forward here for a solution that enables production tracing? [1] https://github.com/DataDog/dd-trace-php/blob/master/src/DDTrace/Integrations/PDO/PDOIntegration.php#L44 [2] https://github.com/GoogleCloudPlatform/stackdriver-debugger-php-extension/blob/master/stackdriver_debugger_ast.c

Dmitry Stogov

7 years ago
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. On 1/31/19 12:43 PM, Dmitry Stogov wrote:

Björn Larsson

7 years ago
Den 2019-02-13 kl. 14:07, skrev Dmitry Stogov:
> 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. > > On 1/31/19 12:43 PM, Dmitry Stogov 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. >>
First, tnx for the excellent work. I think this will be a key driver for PHP 8 uptake. Mention market aspect in the section "The Case for JIT Today"? Secondly I wonder if preloading of e.g. a framework would allow JIT to work more efficiently and give even better performance? r//Björn Larsson

Dmitry Stogov

7 years ago
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 <dmitry@zend.com> 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. On 1/31/19 12:43 PM, Dmitry Stogov wrote:

Joe Watkins

7 years ago
Thanks for all the effort Dmitry, it's looking in much better shape. Cheers Joe On Fri, 22 Feb 2019 at 13:18, Dmitry Stogov <dmitry@zend.com> wrote:

Dmitry Stogov

7 years ago
Thanks to Anatol, who started working on Windows build and "enforced" me to implement MSVC support :) On 2/22/19 3:21 PM, Joe Watkins wrote:

Anatoliy Belsky

7 years ago
Hi,
> -----Original Message----- > From: Dmitry Stogov <dmitry@zend.com> > Sent: Friday, February 22, 2019 1:49 PM > To: Joe Watkins <krakjoe@gmail.com> > Cc: PHP internals <internals@lists.php.net>; Anatol Belski <ab@php.net> > Subject: Re: [PHP-DEV] [RFC] JIT > > 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 https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190301/ Regards Anatol

Dmitry Stogov

7 years ago
JIT also works for non-ZTS PHP Windows builds now. Thanks. Dmitry. ________________________________ From: Anatol Belski <weltling@outlook.de> on behalf of Anatol Belski <ab@php.net> Sent: Friday, March 1, 2019 3:47:07 PM To: Dmitry Stogov; Joe Watkins Cc: PHP internals Subject: RE: [PHP-DEV] [RFC] JIT Hi,
> -----Original Message----- > From: Dmitry Stogov <dmitry@zend.com> > Sent: Friday, February 22, 2019 1:49 PM > To: Joe Watkins <krakjoe@gmail.com> > Cc: PHP internals <internals@lists.php.net>; Anatol Belski <ab@php.net> > Subject: Re: [PHP-DEV] [RFC] JIT > > 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 https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190301/ Regards Anatol

Anatoliy Belsky

7 years ago
I've uploaded a build from the latest branch state https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190305/, NTS/x64/SSE2/PGO. For PGO training, I've omitted some apps like Drupal/Symfony, as they're not yet compatible with 8.0, still a slight improvement with Zend/bench.php does show. Thanks Anatol

Theodore Brown

7 years ago
On Tuesday, March 5, 2019 3:52 PM, Anatol Belski <ab@php.net> wrote: > > On Thursday, January 31, 2019 12:43 PM, Dmitry Stogov 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. > > On Tuesday, March 5, 2019 3:38 PM, Dmitry Stogov <dmitry@zend.com> wrote: > > > JIT also works for non-ZTS PHP Windows builds now. > > > > Thanks. Dmitry. > > I've uploaded a build from the latest branch state > https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190305/, > NTS/x64/SSE2/PGO. For PGO training, I've omitted some apps like > Drupal/Symfony, as they're not yet compatible with 8.0, still a > slight improvement with Zend/bench.php does show. > > Thanks > > Anatol I downloaded the Windows build and added the following settings to php.ini: opcache.jit_buffer_size=10000000 opcache.jit=1205 I'm not sure if these are ideal settings or not, but they produced a nearly 3x speed improvement in the spectral-norm benchmark with $n=100 (https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-php-1.html). Unfortunately I can't test with our real-world app since it relies on the SQL Server extension (https://github.com/Microsoft/msphpsql) which doesn't support PHP 8 yet. 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, Theodore Brown

Anatoliy Belsky

7 years ago
Hi Theodore,
> -----Original Message----- > From: Theodore Brown <theodorejb@outlook.com> > Sent: Thursday, March 7, 2019 5:11 PM > To: Anatol Belski <ab@php.net>; Dmitry Stogov <dmitry@zend.com>; PHP > internals <internals@lists.php.net> > Cc: Joe Watkins <krakjoe@gmail.com> > Subject: Re: [PHP-DEV] [RFC] JIT > > On Tuesday, March 5, 2019 3:52 PM, Anatol Belski <ab@php.net> wrote: > > > > On Thursday, January 31, 2019 12:43 PM, Dmitry Stogov 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. > > > > On Tuesday, March 5, 2019 3:38 PM, Dmitry Stogov <dmitry@zend.com> > wrote: > > > > > JIT also works for non-ZTS PHP Windows builds now. > > > > > > Thanks. Dmitry. > > > > I've uploaded a build from the latest branch state > > https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190305/, > > NTS/x64/SSE2/PGO. For PGO training, I've omitted some apps like > > Drupal/Symfony, as they're not yet compatible with 8.0, still a slight > > improvement with Zend/bench.php does show. > > > > Thanks > > > > Anatol > > I downloaded the Windows build and added the following settings to php.ini: > opcache.jit_buffer_size=10000000 > opcache.jit=1205 > > I'm not sure if these are ideal settings or not, but they produced a nearly 3x > speed improvement in the spectral-norm benchmark with $n=100 > (https://benchmarksgame- > team.pages.debian.net/benchmarksgame/program/spectralnorm-php- > 1.html). > > Unfortunately I can't test with our real-world app since it relies on the SQL > Server extension (https://github.com/Microsoft/msphpsql) > which doesn't support PHP 8 yet. > > 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. Regards Anatol

Dmitry Stogov

7 years ago
Hi Internals, https://wiki.php.net/rfc/jit 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. Thanks. Dmitry. On 1/31/19 12:43 PM, Dmitry Stogov wrote:

Benjamin Eberlei

7 years ago
On Fri, Mar 15, 2019 at 10:53 AM Dmitry Stogov <dmitry@zend.com> wrote:
> Hi Internals, > > https://wiki.php.net/rfc/jit > > 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.

Anatol Belski

7 years ago
Hi, New Windows builds are available here https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190315/ . Anyone interested, especially usage with Apache, are encouraged to test hard :) Thanks Anatol