Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104401
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=M/zmlm4ad79O5zikdx4i0eHhAGar+1zV0yc/jXJepQNvug8e+DXquc4wyU0ihI
	Juh8cU6KGNTWkofbFueFLKWhw93edtQIwMG/VcwouZbRbNPllplkF48H5HPL2SvU
	ZO89SvCt9M3oRcs4sXFPfXX+JQavvePIGaiwoVsWdMjYA=;
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> <CAF+90c88r+3JLwasoX5hjpauwHtmM9QAStzJ6WiBZ4k=RfkvdQ@mail.gmail.com>
In-Reply-To: <CAF+90c88r+3JLwasoX5hjpauwHtmM9QAStzJ6WiBZ4k=RfkvdQ@mail.gmail.com>
Date: Thu, 14 Feb 2019 13:38:44 +0200
Message-ID: <CAJHtznwp87f7Za6-k+RDK9zfi0cEwnoCKGjUVZpRZDjhOp4Q1Q@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007479bf0581d91a2c"
Subject: Re: [PHP-DEV] [RFC] JIT
From: zeev@php.net (Zeev Suraski)

--0000000000007479bf0581d91a2c
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 14, 2019 at 12:19 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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.
>

Agreed.


> > 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.
>

That's a valid point, but given we're only a few months away from
feature-completing 7.4, as well as the general direction that most probably
more substantial changes will make it into 8.0 - I don't know that the
initial investment in a 7.4 version of JIT (and the marginal cost of then
maintaining it) would be too big.  I believe Dmitry's proposing that while
realizing the bulk of the work will fall on his shoulders if we decide to
do it.


> * 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.
>

We both agree that if we include JIT in 7.4 it will dilute from the 'shiny
new thing' aspect of it when it's available in 8.0.  That said -
realistically, it seems that JIT will not be as revolutionary as phpng was
in terms of real world performance impact, so if I had to guess - migration
to 8 it would be a lot slower than the migration to 7 (the motivation to
upgrade to 7 in the vast majority of companies I came across was
predominantly around performance;  new features were a nice bonus).

* 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).


I'm not too worried about it finding itself into production, as long as we
make it clear that it's not ready for it.  People who run experimental
software in production are typically quite aware of the risk they're
taking, and often they are quite determined too - so they might be the ones
who check out Dmitry's code as it is today without waiting for our RFCs
anyway.  It's also quite reasonable that an experimental feature won't work
with every last extension (as long as they're not super mainstream like
MySQL or curl).

Either way, I think the decision whether to include it in 7.4 or not is
tactical.  It's gaining wider testing exposure, at the expense of losing
some 'sexiness' of a shiny new feature in 8.0.  I see both approaches as
entirely valid.

Zeev

--0000000000007479bf0581d91a2c--