Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102438
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.173 as permitted sender)
MIME-Version: 1.0
References: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <CAJHtznzVSPLLvGJW471GoKbBE7uB5oLYJ+8Lq-=vYSP-LHeYww@mail.gmail.com>
 <CAESVnVpC8KyHP4rOm=Ne_MfOC2Nr_jB_RKUKDDAkFdbTggeV3Q@mail.gmail.com> <4719624.u8nS1KoLlB@vulcan>
In-Reply-To: <4719624.u8nS1KoLlB@vulcan>
Date: Mon, 25 Jun 2018 22:12:22 +0300
Message-ID: <CAJHtznzPE88XzvwPYArstyuF2mMKE6G7yP7Lp=yo4E4GYuidVw@mail.gmail.com>
To: larry@garfieldtech.com
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000e970b7056f7c2935"
Subject: Re: [PHP-DEV] PHP 2^3
From: vsuraski@gmail.com (Zeev Suraski)

--000000000000e970b7056f7c2935
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 25, 2018 at 8:52 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Monday, June 25, 2018 11:16:31 AM CDT Sara Golemon wrote:
>
> > > First, I'll admit that there's definitely some of that happening.  But
> to
> > > paraphrase my daughters - "I didn't start it!".  In other words -
> people
> > > are very actively looking for ways to run PHP in a Node-like manner,
> and
> > > with the shift towards micro-services - I don't think it's a fad.  I
> > > think we need to go there if we are to stay relevant.
> >
> > Fair point.  I've certainly had discussions with Liz Smith and even
> > been on Zend sponsored podcasts discussing ways we might "appify" PHP.
> > But, and perhaps I'm just a bit more skeptical of the microservices
> > train, I think we should be judicious in our pursuit of the new
> > hotness. That's all.  Most of my response was centered on what felt
> > like a rush.  Factoring in that entire paragraph about having a thin
> > 7.4 release with a subsequent 8.0 GA alleviates my concerns a great
> > deal.
>
> When we speak of "typical web loads" not getting much benefit here, are we
> really talking about CGI-style "reboot every request" type loads rather
> than
> "IO-bound work"?  Because it's been observed many times in the past that
> one
> of the most expensive parts of a modern PHP app is simply booting up,
> initializing all of the services, wiring everything together...  and then

throwing it away 100 ms later.  If a JIT would make it more viable to pre-
> start a web process (there are various all-user-space implementations in
> the
> wild already) so that an incoming request already had a fully booted system
>
> with container initialized and stuff, that could have a huge impact on web
>
> loads, even without going all-in on Node-style async.
>


I thought I'd be given the benefit of doubt regarding having a clue about
performance of PHP workloads... :)

On point, the initialization cycle isn't radically different with JIT.
Initializing the request is pretty similar, as is the stage of loading
classes.  The current JIT implementation doesn't bring substantial
performance gains with most real world apps we tested - as they simply
don't seem to spend too much in pure PHP logic (discounting the loading of
classes).  Of course - your mileage may vary, and it's not outside the
realm of possibility that certain apps that are CPU-heavy in either their
initilization or execution would benefit - perhaps even greatly - from
JIT.  It may also depend on the specific CPU and a lot of other factors.
When people start testing it in the wild I guess we'll have a better view.

What will definitely bring benefit to real world workloads is preloading,
which (if we manage to do it) will dramatically reduce the per-request
initialization stage.  It could bring us much of the benefit of async-IO
long running processes without sacrificing the isolation advantages of the
traditional PHP execution model.  It will likely also play nicely with
JIT.  But this is floors upon floors of speculation - we'll have to see...


Question from the peanut gallery: why would 7.4 need to be a deprecation-
> mostly release?  Is the concern that it would make merging to the engine
> changes in 8.0 harder?


Certainly, but even without it - it's going to be hard enough to release 8
with its features within 2-2.5 years. It will be impossible to do it while
spending most of that time working on other releases.  I don't think people
realize just how ambitious these bulletpoints are - to pull off in ~24
months (gross).  It took us, IIRC, approximately 18 months from the point
we published phpng and until PHP 7.0 was ready - as we focused exclusively
on it.  We're not in a very different stage with JIT right now, but we're
throwing in several other radical improvements with far reaching
implications - async and preloading (and that's before others pitched in
their ideas).

We have finite resources, and honestly, the resources we have that can work
on these deliverables are very scarce.  We need to choose are battles.

Zeev

--000000000000e970b7056f7c2935--