Den tor. 31. jan. 2019 kl. 18.39 skrev Dmitry Stogov <dmi...@zend.com>: > > > > 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.
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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
