Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103935
MIME-Version: 1.0
References: <DM6PR02MB59326E10841277F34E4EFF75BF910@DM6PR02MB5932.namprd02.prod.outlook.com>
 <CAF+90c-Ck7zgU+Z=VX8ewny2s=xrr5RYRC86r_0FJ_gFUM-cmw@mail.gmail.com> <8d9dffd5-ea2c-e642-b777-4a4fd76b261a@zend.com>
In-Reply-To: <8d9dffd5-ea2c-e642-b777-4a4fd76b261a@zend.com>
Date: Thu, 31 Jan 2019 18:47:44 +0200
Message-ID: <CAJW__o2JZ_E3UpoanaFNEEM8ufWhHzsJDEdYhecfe7639U4-oA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] JIT
From: kalle@php.net (Kalle Sommer Nielsen)

Den tor. 31. jan. 2019 kl. 18.39 skrev Dmitry Stogov <dmitry@zend.com>:
>
>
>
> On 1/31/19 7:01 PM, Nikita Popov wrote:
> > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com
> > <mailto: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).
>
> 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
kalle@php.net