Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104433
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>
 <CALKiJKqCbdC=dW0Ng5BHXRBkGd+FfDFQHYK-skcwwxEV7FCFAQ@mail.gmail.com>
 <CAJHtznwFpRt1=iYp2jmiGgz4Nrhy1EP_XPhbeZvvoDReqi8LAw@mail.gmail.com>
 <CAOWwgp=Q0zTwVe9=1Hv_GfrJQOxHaWTZu4mX+wHyoKn3ZQ71LA@mail.gmail.com>
 <CAL0xaBFSEEnzFWhwZFsud3xEFEABBm8J0i92e8LF7EhVgnDSKg@mail.gmail.com>
 <CAOwTYAswpD50Wp2VCpfugFx9b_rTUwZd7hWgsfTjoec_jBDZgA@mail.gmail.com> <d720f65e-99a9-c90c-cb10-768e9b61ebe0@zend.com>
In-Reply-To: <d720f65e-99a9-c90c-cb10-768e9b61ebe0@zend.com>
Date: Fri, 15 Feb 2019 09:56:34 +0100
Message-ID: <CAOwTYAsD2i6Q0cwR1ktmZm_JBCLq8fp9rxG1ggkhdWHiLiqpOg@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>, Nicolas Grekas <nicolas.grekas+php@gmail.com>, 
	Zeev Suraski <zeev@php.net>, Rowan Collins <rowan.collins@gmail.com>, 
	Internals <internals@lists.php.net>, Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000070a1000581eaf4a6"
Subject: Re: [PHP-DEV] [RFC] JIT
From: krakjoe@gmail.com (Joe Watkins)

--00000000000070a1000581eaf4a6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Morning Dmitry,

> I told, I'm not going to do any active JIT development at this point.
> Why to waste time, if it's not going to be accepted...

At this point, *nobody* can imagine that PHP 8 will not have a JIT, there
is no sense in saying or thinking you would be wasting your time.

If you opened a vote for the JIT to be accepted in PHP 8, and committed to
making the improvements that *everyone* wants to see in the interim, the
vote would be more or less a formality, not really necessary at all,
because we all know what will happen.

I cannot stress enough that you would not be wasting your time to continue
developing the JIT. Saying "it's this or nothing" is not a very productive
or sensible thing to do at this point.

You must already know that yourself, Nikita, and Bob are really the only
active contributors that are qualified to talk about technical aspects of
the JIT, to improve it, to find or fix bugs. You must also understand that
given the time necessary things will change; You are employed, at least in
part, to work on PHP, and nobody else (afaik) except Nikita is: We have to
find time in our weekends and late at night to read things we're not
familiar with at all, I've never been good at assembly myself, and my
knowledge here is lacking. I look forward to improving my knowledge, I find
it exciting, but it will take a long time, many many weekends and nights,
and 7.4 is simply too early. Even Nikita and Bob are not comfortable enough
to make changes right now, but are still useful. What we're looking at
then, is a bus factor of 1, for about the next year, it may be as high as 3
or 4 by the time 7.4 is actually released. There's not 1000 people familiar
enough with the Zend of today to find, fix and improve PHP, but 3 or 4 is
just unreasonably low - this is the reason I say it's dangerous. My words
are not meant to be toxic, at all.

For the last two and a bit years, I've been focused on being a release
manager, and haven't spent a lot of time working on patches like I used
too, I'm still familiar with zend at a low level, but you've just made it
100x more complicated, and are twisting our arms to accept this additional
complexity, all the while saying you won't make improvements and don't have
time for other improvements that you've identified that would widen the
scope of the JIT considerably (ZTS), and lay the groundwork for supporting
other platforms (Windows).

7.3 was one of the worst releases for stability in recent years, and
regardless of whether you intend to disable the JIT by default, it's going
to be rolled out into production in whatever version of PHP it is merged
into, if what it is merged into is a production release of PHP, you can't
stop that with a configure switch or an INI setting, as has already been
pointed out by Nikita. Therefore, it's important that the JIT is actually
production ready and has a scope wide enough to justify the additional
complexity it brings to everything. I'm aware that you think switching the
JIT off is a solution to the tooling problems we clearly have, but it is
not a solution, people are going to expect their tools to work with it, and
saying "disable the JIT" or "disable opcache" to end users is unacceptable.
I realise you have more important things to do right now than to
concentrate on the issues that extension maintainers have, but it's obvious
that these issues need to be addressed before we push the JIT onto the
ecosystem. By withdrawing the suggestion of merging into 7.4, and focusing
our efforts on a really great PHP 8, you give yourself and all those
maintainers time to work together and find solutions to these problems that
are acceptable to us all, time we all desperately need. yourself included.
You also reduce your own workload considerably by not having to concentrate
on 7.4. You also take away the worry of another unstable release in the 7
series, which we cannot really afford to have if we don't want to damage
adoption rates of PHP 8.

Yesterday the suggestion of "preview" releases was made, previews of the
master branch, this is the best idea I have heard around deploying the JIT
to the world, those releases need not have a fixed schedule and in no sense
are production releases of PHP. I'll happily volunteer myself to do that
additional work and manage those releases while the 7.4 release managers
concentrate on a stable 7.4, I'm quite sure that past release managers will
help me there too. We can then nominate permanent managers for 8 as normal,
and I/we will hand over to them a reasonably stable, well tested JIT, that
many of us are comfortable diagnosing and pushing forward.

> If you are interested in ZTS, you may invest time in implementation of
> the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
> if you start, because I may find time myself.

This is great to hear, but I've worked on the TSRM layer before, it was
myself that prepared for PHP 7 the original native-tls patch that was
proposed some time ago for PHP 5, subsequently Anatol had to do all the
heavy lifting, I understand it very well, but I'm not able to confidently
develop on Windows, just like you, I'm not that familiar with Windows.
Again, fixing these things are going to take time, and the effort of many
of us.

Time and commitment, is all I am asking for, without those my confidence
has evaporated, I'm sorry to say.

Cheers
Joe






On Fri, 15 Feb 2019 at 09:06, Dmitry Stogov <dmitry@zend.com> wrote:

> Hi,
>
> On 2/14/19 5:22 PM, Joe Watkins wrote:
> > Morning all,
> >
> > This idea of an experimental feature as complex as a JIT is dangerous. =
It
> > is not finished, and dmitry has said he's not willing to put more time
> into
> > until it's merged. That's his prerogative, and it is ours to say that w=
e
> > don't want unfinished software that only one or two people really
> > understand in PHP. All of the rest of internals need all of the time
> > between now and PHP 8 to educate ourselves on this so that we function =
as
> > well as we do now when it comes to finding and fixing bugs, and pushing
> PHP
> > forward.
>
> Few years ago I was claimed for development PHPNNG privately, but that
> time we delivered to @internals almost completed solution. Now you don't
> like the solution, because it's incomplete in your opinion (ZTS support,
> etc), and the development makes troubles...
>
> If you are interested in ZTS, you may invest time in implementation of
> the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
> if you start, because I may find time myself.
>
> I told, I'm not going to do any active JIT development at this point.
> Why to waste time, if it's not going to be accepted...
> However, I keep it in sync with master and PHP-7.4, fix reported
> problems, respond to code review comments, etc (just check git commits
> history).
>
> In last email I asked for ideas for RFC improvement (like notes about
> unsupported ZTS). May be it makes sense to add cons/pros for additional
> PHP-7.4 proposal. May be write something more clear (I'm not a native
> speaker).
>
> But this "a bit toxic" discussion, at least, steals time from
> constructive things.
>
> Joe, please, don't take anything personally.
> Despite I wrote above, I appreciate your involvement in PHP development
> and respect your opinion regarding JIT, ZTS. etc.
>
> Thanks. Dmitry.
>
>
> > Merging the JIT into 7.4 puts a brick wall in the way of progress
> > that none of us have the tools to climb over.
> >
> > I hear the argument about wanting to test, but anyone with sufficient
> > expertise to test the JIT is capable of building the branch available o=
n
> > github, we do not need to push out an incomplete product to the entire
> > world for the sake of that handful of individuals who will actually tes=
t.
> >
> > I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
> > current form, and would ask everyone to please think very carefully abo=
ut
> > it, prior to supporting it.
> >
> > Thanks
> > Joe
> >
> >
> > On Thu, 14 Feb 2019 at 14:34, Arvids Godjuks <arvids.godjuks@gmail.com>
> > wrote:
> >
> >> =D1=87=D1=82, 14 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 14:54, =
Nicolas Grekas <
> nicolas.grekas+php@gmail.com
> >>> :
> >>
> >>>> [...] I think that whether or not we include it in 7.4
> >>>> is a tactical decision (and I'm not sure myself where I stand on it)=
,
> >>> but I
> >>>> do think there's a reasonable case for both directions.
> >>>>
> >>>
> >>> If I may add some voice to Zeev's arguments, being able to play with
> JIT
> >> as
> >>> early as possible would allow the community to experiment using PHP i=
n
> >>> areas where it doesn't fit right now. Having to wait 2 more years to
> >>> discover that maybe it's useful to build some new libraries could be =
a
> >>> waste of time at the tactical level (there are other technologies
> around
> >>> that move fast also :) )
> >>>
> >>> Not to detract from the technical challenges of moving in this
> direction,
> >>> of course.
> >>> Just my 2cts from a "userland" guy :)
> >>>
> >>> Nicolas
> >>>
> >>
> >> Hello everyone,
> >>
> >> I agree with this sentiment and the general idea of shipping JIT as
> >> experimental in 7.4 and required to build with a configure flag.
> >> master for 8.0 is going to contain much more and be more unstable and
> not
> >> practical for testing what JIT can do at that point due to all other
> >> features and improvements going into it like additional optimizations
> and
> >> platform support.
> >> It will give me, as a userland developer, a platform where I can
> actually
> >> play with it early and on a stable platform. And I understand what I'm
> >> doing at that point.
> >>
> >> --
> >> Arv=C4=ABds Godjuks
> >>
> >> +371 26 851 664
> >> arvids.godjuks@gmail.com
> >> Skype: psihius
> >> Telegram: @psihius https://t.me/psihius
> >>
> >
>

--00000000000070a1000581eaf4a6--