Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104400
MIME-Version: 1.0
References: <DM6PR02MB59326E10841277F34E4EFF75BF910@DM6PR02MB5932.namprd02.prod.outlook.com>
 <alpine.DEB.2.21.1901311706560.19683@singlemalt.home.derickrethans.nl>
 <01178c69-e021-3865-689c-00c3a1902574@php.net> <CAJHtznzm3rb+XfaaAfFVuo-_yOA+TveRhGBNZQRXYtp38yJugg@mail.gmail.com>
In-Reply-To: <CAJHtznzm3rb+XfaaAfFVuo-_yOA+TveRhGBNZQRXYtp38yJugg@mail.gmail.com>
Date: Thu, 14 Feb 2019 11:19:23 +0100
Message-ID: <CAF+90c88r+3JLwasoX5hjpauwHtmM9QAStzJ6WiBZ4k=RfkvdQ@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000017a4730581d7ffd2"
Subject: Re: [PHP-DEV] [RFC] JIT
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000017a4730581d7ffd2
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 14, 2019 at 10:43 AM Zeev Suraski <zeev@php.net> wrote:

> On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann <sebastian@php.net>
> wrote:
>
> > Am 31.01.2019 um 18:08 schrieb Derick Rethans:
> > > I do not believe that something major like this should make it into any
> > > PHP 7.x release. Having it as experimental new feature in the
> master/PHP
> > > 8.0 branch makes the most sense to me.
> >
> > ACK
> >
>
> Does it mean that when PHP 8.0 comes out (in roughly two years' time most
> probably), we'd be saying this is experimental?  Or that only in the
> meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs before
> it's released, we'd say it's experimental but will remove that tag by the
> time 8.0 is released?
>

I don't think we can really answer that question at this point in time.
That depends on how stable and compatible the JIT is by the time PHP 8.0
comes around. But having it as a non-experimental feature should definitely
the goal, and I also think this is possible.


> If it's the former - I don't think we should go in this direction.  If we
> decide that it's sensible to have it - I think we should work to ensure
> that it's production ready by the time PHP 8.0 is released.  Offering it as
> something experimental (i.e. not for production) in 7.4 can help us with
> that goal, as it will make it easier for a wider range of people to
> experiment with it and provide feedback.  I can't think of any
> technological downsides to including it as experimental in 7.4 - there's a
> slight "marketing" downside (it will be less of a shiny new thing in PHP
> 8.0), but personally I think the feedback we're likely to get is worth it.
>

There a number of downsides to including it in PHP 7.4:

 * First and foremost for me: Maintenance. We are only shortly after
branching, and the PHP 7.4 and PHP 8.0 branches already have some
significant divergences (e.g. in object handler APIs). I don't expect that
this is going to be get as bad as PHP 5 vs PHP 7 internals, but I would
also very much prefer not having to maintain a new large and complex chunk
of code against two different major engine versions.

* Marketing: As you already mentioned yourself, adding a JIT is a great
marketing point. I think that PHP 7 was quite successful from a marketing
perspective, because it had a nice blend of major performance wins, some
long-awaited features and a few incompatibilities. It would be great if we
could repeat this with PHP 8, and I think that having a JIT and some major
language feature (say generics) would be a great drive to upgrade. Adding
the JIT earlier as an experimental feature would dilute this a lot.

* Stability / Compatibility: While we can mark features as experimental all
we want, let's fact it: If it exists, it's going to end up in production. I
would prefer to only publicize the JIT once it is stable, and also
importantly, has good integration with 3rd party extensions. Basically
"just works". I know that Joe has been testing some of this exts (like pcov
and pthreads) and their interaction with the JIT, and also been talking to
some other maintainers of "low-level" extensions like profilers. From what
I understood, quite some work will be needed to allow integration (beyond
just disabling the JIT).

Nikita

--00000000000017a4730581d7ffd2--