Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103927
MIME-Version: 1.0
References: <DM6PR02MB59326E10841277F34E4EFF75BF910@DM6PR02MB5932.namprd02.prod.outlook.com>
In-Reply-To: <DM6PR02MB59326E10841277F34E4EFF75BF910@DM6PR02MB5932.namprd02.prod.outlook.com>
Date: Thu, 31 Jan 2019 17:01:18 +0100
Message-ID: <CAF+90c-Ck7zgU+Z=VX8ewny2s=xrr5RYRC86r_0FJ_gFUM-cmw@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000010fd8a0580c3246e"
Subject: Re: [PHP-DEV] [RFC] JIT
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000010fd8a0580c3246e
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@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

--00000000000010fd8a0580c3246e--