On 1/31/19 7:01 PM, Nikita Popov wrote: > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmi...@zend.com > <mailto: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).
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. > > Regards, > Nikita
