On Thu, Jan 31, 2019 at 9:01 AM Nikita Popov <nikita....@gmail.com> wrote: > > 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
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
