On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmi...@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
