Hi,
On 31.01.19 г. 18:47 ч., Kalle Sommer Nielsen wrote:
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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
