Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102443 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 41426 invoked from network); 25 Jun 2018 20:42:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jun 2018 20:42:41 -0000 Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 66.111.4.26 out2-smtp.messagingengine.com Received: from [66.111.4.26] ([66.111.4.26:57031] helo=out2-smtp.messagingengine.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C9/AE-50433-0C3513B5 for ; Mon, 25 Jun 2018 16:42:40 -0400 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9D9E8214AC for ; Mon, 25 Jun 2018 16:42:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 25 Jun 2018 16:42:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=OJQXj5prefPDudQbCu1MPTg2/msiC KznLwbAVjnobRI=; b=ir/CarAzD/41TuIJp1uA1kwiA6/r1SOMGTvuLTvOG/M/P fK4Nl+My6A81BnVc6W6AfFqdAXyPEEyezlembdPMH7eRbEKSVVVk7jYPWPw+lH2M CoOCdHw07hw2lqo04qbi1fOAaifdmCrdUi8aLt/AuxOve9EDETj7rM9v/5tniKrE R2X4mmmoCMPTLPPWc6KdqQtvZ+LjGCh+CdxK8aHEJS6h6O9AiOwPYFnaVBZWu6kO WR8CqAoOEuT+eKT5vppqWeUYfHZADy5vYU4rw5POtQQ/FssVYR4G4C1gjkm2B5UB jfZhv79ofwarHbEP0ih0SzGI6a1enqqW+ugBG7Uog== X-ME-Proxy: X-ME-Sender: Received: from vulcan.localnet (216-80-30-152.s3222.c3-0.frg-cbr1.chi-frg.il.cable.rcncustomer.com [216.80.30.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 0B6DF10260 for ; Mon, 25 Jun 2018 16:42:36 -0400 (EDT) To: internals@lists.php.net Date: Mon, 25 Jun 2018 15:42:33 -0500 Message-ID: <28344669.tbARPPRcEQ@vulcan> In-Reply-To: References: <4719624.u8nS1KoLlB@vulcan> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart30011292.BmVnZbvIPJ"; micalg="pgp-sha512"; protocol="application/pgp-signature" Subject: Re: [PHP-DEV] PHP 2^3 From: larry@garfieldtech.com (Larry Garfield) --nextPart30011292.BmVnZbvIPJ Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Monday, June 25, 2018 2:12:22 PM CDT Zeev Suraski wrote: > > 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... :) Understanding it yourself, yes. Clarifying what it is you're talking about in this particular context, no. :-P > 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... This is more what I'm talking about. A way to get a process up to "all my service objects are created, my code is parsed, my events are registered, etc.", and then save that state and do the usual shared-nothing after that without having to repeat that part. I agree that's likely several layers up from where we're talking, but if it's a potential thing that could be done then that's a good argument for doing this thing now. > 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 That's certainly a good argument for the people doing deep engine work to focus on that, but there's ample non-core-team people who would be totally useless in stabilizing a JIT that could have other things to add. I'm thinking of if, say, SammyK comes back with another trailing comma RFC again, or someone not already busy with async details manages to figure out a performant way to do property accessors, etc. Would those be actively blocked from 7.4? Or would those be fine as long as it doesn't distract you and Dimitry from figuring out async? If they're OK, then yay, we're on the same page. If not, then we're basically guaranteeing that no one is going to bother using 7.4 (thus rendering the whole "deprecation release" useless) and losing a lot of momentum from people interested in improving the language in ways other than the core runtime/ compiler logic. --Larry Garfield --nextPart30011292.BmVnZbvIPJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEE/ph/GXfY8v0YwFBp4MMKwDFxYXcFAlsxU7kACgkQ4MMKwDFx YXeYXwgAmYkvGQTHE8vTG3xGjixZEIW4soC47UEkf5Fss8Ts30hgdlXzS8it7ytw slLa7M3PmoQQ+JB7yuLyN8qbqAF92+A8dRN4SLhncgJDKN0wRvjuUfx79oytkw2k MZOzivipvDJX1fUNtcQgnO6L5CMTUn6RNpo48gi8SCShPpyZpzW+wivq42R2q8bd LAd/MOzDDOg9eZ2AGnkGTzngehBxOUdC8+0MVp5HL7Lk+wnHxXlD4Bjh11LCxC/G sM9hN9JdycrZ6PmfvJ/fCyffKGnOrk9cD56LlOOYvBQyRAXGiiG0PI3j5q7XpjGl a/19GhVaE1UZdK4q+TQ54ktv3zMJzA== =be0K -----END PGP SIGNATURE----- --nextPart30011292.BmVnZbvIPJ--