Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] PHP 2^3

Posted by Zeev Suraski 
Zeev Suraski
[PHP-DEV] PHP 2^3
June 25, 2018 02:40PM
As I mentioned a few days ago I intended to send it slightly later - but as Nikita brought up the topic of PHP 8, this is probably as good a time as any to start the discussion.

Please note: The goal of this email isn't to discuss in detail each and every topic that's mentioned, but rather to establish whether we want to move to focus on PHP 8 as we go beyond PHP 7.3, based on some of the research projects and PoCs we've been working on.

There are several areas that I think we should invest in in the next major version:

1. JIT. As most of you probably know, we've invested heavily in re-doing JIT on top of the PHP 7 infrastructure. There are good news and bad news. The good news is that - like the JIT POC we did back in 2014 - the results for CPU intensive workloads are remarkable. The bad news is that it doesn't significantly move the needle for typical Web workloads.
That said, unlike 2014 - where we had another avenue to go after, this time we believe that JIT doesn't improve the performance of typical Web workloads simply because the bottleneck there is no longer PHP code execution.
However, I still think we should still include JIT in the next major version of PHP for at least 2 reasons:
- It will open the door for new types of workloads for PHP (non Web)
- It may open the door for new built-in functionality being written in PHP - for more secure code (e.g. a PHP unserialize() implementation, instead of one in C)
In addition, it's always possible that we're missing something in our benchmarks and that there are real world Web workloads that would actually benefit from the speedup.
One thing worth noting is that in all likelihood, we'd want to make OPcache (or at least large parts of it) a part of the core engine (and no longer a separate extension) as a part of the JIT effort.
- (bonus) Combined with other things we're experimenting with, the compound effect may still result in better performance for Web apps.
To get a feel for the performance gains we're talking about here, I recorded a benchmark comparing PHP 7.0 and the JIT PoC, available here:
https://www.youtube.com/watch?v=dWH65pmnsr

2. Better support long-running, async-based, microservices-focused execution model. It's probably no secret that one of the key reasons Node is gaining popularity is because it can handle a huge number of concurrent connections issuing relatively lightweight requests very efficiently - which is a good match for modern microservices based architectures. There are already several projects available for PHP that aim to provide similar functionality - most notably ReactPHP and more recently Swoole.
The main thing that is missing is that most of PHP's IO doesn't support async execution. What I think we should do is add as much support for async IO as possible across the various extensions and streams - so that using something like Swoole would become practical for more use cases. More specifically - the goal would be to provide extension authors with mechanisms that they can use to make their extensions/functions optionally asynchronous, without having to tackle the job entirely on their own. While we've done some research into this area, it requires a lot more research - but I'm cautiously optimistic that it can be done. We would potentially want to use libuv for this task, and potentially rewrite or otherwise refactor parts of the PHP streams system.

3. Foreign Function Interface support. Essentially, make it very easy to connect PHP to native code libraries written in C or C++ without having to write an extension. Now, I realize this may not sound like much more than an extension - however, I think that if we look at the potential impact and not just the complexity of implementation - this is actually quite strategic. This can open the door for PHP to be used a lot more often in conjunction with 'bleeding edge' technologies, such as AI and Machine Learning, and not just ones existing today - but kind of 'future proof' it for whatever technologies emerge down the road. Dmitry brought that up on the mailing list already, and he's made quite a bit of progress there. He actually spent the last couple of weeks writing TensorFlow bindings for PHP, and wrote what's probably the first Neural Network in PHP - recognizing handwritten digits with 98% precision (https://github.com/dstogov/php-tensorflow/blob/master/test_nmist_01.php). I think that especially combined with JIT - this can make PHP a real powerhouse for executing CPU intensive apps, while not compromising on developer productivity. By the way, to make it go truly fast (especially in conjunction with JIT), we'll likely want this to actually be merged into the core engine as well, and not as a separate extension.

4. Preloading support. We've discussed this at a high level numerous times, but if we end up introducing JIT into PHP 8 as I hope we will, preloading support can very nicely complement it. It will effectively enable the development of PHP-based "extensions" - instead of just C based (or FFI based) ones. With JIT, the penalty for writing logic in PHP would go down dramatically - and it would obviously offer benefits as far as both simplicity and security are concerned. In addition - preloading can actually speed things up very substantially for Web based apps, as it may allow us to resolve certain dependencies at compile time (mainly inheritance) in compile-time instead of runtime.

Now, two things I should mention that this list is/isn't:


* It's incomplete - i.e., the fact a certain feature isn't on it does not preclude its inclusion in PHP 8
* It's not set in stone - we'll of course have to have RFCs for each of these ideas, and we may also very well fail to implement some of them to satisfactory levels

What this list is - a collection of directions around which we've performed varying amounts of research (some of them quite a lot, like JIT), that I think is strong grounds for us to start discussing a PHP 8 timeline, and making PHP 7.3 the last feature release in the PHP 7.x family. If we had to come up with an educated guess as to when PHP 8 could be ready to be released based on the abovementioned featureset, we're probably talking about 2-2.5yrs away (i.e. mid/late 2020). We can also consider having a very slim PHP 7.4 release sometime in 2019 that wouldn't add any functionality, but that would give us an opportunity to deprecate anything that we missed in 7.3 that truly requires deprecation - while still allowing folks to prepare for 8.0 ahead of time.

My aim with this email is to both gauge the sentiment of shifting focus towards PHP 8 after the 7.3 release, as well as directional feedback regarding the various bulletpoints. If there's positive feedback, I think the next step may be to draft a 'PHP 8 as the next feature release of PHP' RFC, with perhaps provisions for a deprecation-only 7.4, and then continue with each of the above proposals (as well as any others) separately. We can also try to include a timeline in it, but I think it has to have provisions to be delayed (to a certain limit) in case things take longer to research/develop/stabilize.

Thoughts?

Zeev
Johannes Schlüter
Re: [PHP-DEV] PHP 2^3
June 25, 2018 04:20PM
On Mo, 2018-06-25 at 12:30 +0000, Zeev Suraski wrote:
> 3. Foreign Function Interface support. 

Related to this on a non-PHP-code and strategic matter I would like to
rethink PECL. Currently maintenance and installing extensions using it
is a pita. This should be doable in a nicer way. 
(i.e. pecl pointing directly to Git(Hub) repos, similar to composer, a
way to install precompiled binaries, probably using a more narrow
stable API, better reporting of dependency issues, with the new
execution model of your point 2 also better integration with composer,
....)

johannes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski
Re: [PHP-DEV] PHP 2^3
June 25, 2018 04:20PM
On Mon, Jun 25, 2018 at 3:31 PM Zeev Suraski <[email protected]> wrote:

> 1. JIT. As most of you probably know, we've invested heavily in re-doing
> JIT on top of the PHP 7 infrastructure. There are good news and bad news.
> The good news is that - like the JIT POC we did back in 2014 - the results
> for CPU intensive workloads are remarkable. The bad news is that it
> doesn't significantly move the needle for typical Web workloads.
> That said, unlike 2014 - where we had another avenue to go after, this
> time we believe that JIT doesn't improve the performance of typical Web
> workloads simply because the bottleneck there is no longer PHP code
> execution.
> However, I still think we should still include JIT in the next major
> version of PHP for at least 2 reasons:
> - It will open the door for new types of workloads for PHP (non Web)
> - It may open the door for new built-in functionality being written in
> PHP - for more secure code (e.g. a PHP unserialize() implementation,
> instead of one in C)
> In addition, it's always possible that we're missing something in our
> benchmarks and that there are real world Web workloads that would actually
> benefit from the speedup.
> One thing worth noting is that in all likelihood, we'd want to make
> OPcache (or at least large parts of it) a part of the core engine (and no
> longer a separate extension) as a part of the JIT effort.
> - (bonus) Combined with other things we're experimenting with, the
> compound effect may still result in better performance for Web apps.
> To get a feel for the performance gains we're talking about here, I
> recorded a benchmark comparing PHP 7.0 and the JIT PoC, available here:
> https://www.youtube.com/watch?v=dWH65pmnsr
>
> Argh - the URL was trimmed - that's the correct one:

https://www.youtube.com/watch?v=dWH65pmnsrI

Zeev
Sara Golemon
Re: [PHP-DEV] PHP 2^3
June 25, 2018 04:30PM
On Mon, Jun 25, 2018 at 7:30 AM, Zeev Suraski <[email protected]> wrote:
> As I mentioned a few days ago I intended to send it slightly later - but as Nikita brought up the topic of PHP 8, this is probably as good a time as any to start the discussion.
>
> Please note: The goal of this email isn't to discuss in detail each and every topic that's mentioned, but rather to establish whether we want to move to focus on PHP 8 as we go beyond PHP 7.3, based on some of the research projects and PoCs we've been working on.
>
With the above paragraph in mind, I would say yes; This laundry list
sounds like major bump worthy items. However I'm going to throw some
negatives in here and probably start longer threads separately on my
concerns with specific items.

1/ Pushing 8.0 as 7.3 + 1 means we're going to rush deprecations into
7.3 which is already in fire-hose mode of last-minute, under-planned
"hey I want this toy" requests. Yes, deprecations are a little bit
more sweaty ice cube in terms of late deprecations being lower risk
that late additions, but it's still turning into a rushed thing during
a season when some folks are off on holiday break. The FF is in
Summer in part *because* this is a bad time to introduce RFCs.

2/ In several of theses cases we're talking about something that's not
even fully scoped out yet. Async, for example, "requires a lot more
research". Yes, that research can probably be completed and turned
into an implementation in the 1.5 years we have till the Nov 2019 GA
(whatever version that ends up being), but there are multiple items on
this list which are not (seemingly) fully fleshed out.

3/ When I read phrases like "open the door for new types of workloads
for PHP (non Web)", and "one of the key reasons Node is gaining
popularity", and " 'bleeding edge' technologies, such as AI and
Machine Learning" I smell a trend of chasing the new hotness and
worrying about factors other than making PHP the best language for the
Web. Growing PHP is great, and evolving it into new areas is also
potentially quite good, but we *have* history showing what happens
when we come up with something new to chase after that then turns out
to be underwhelming, undermaintained, and underutilized. I've also
seen what a JIT does in terms of additional complexity, it's not
pretty.

4/ When the $(%* did we body swap, because it's not quite full
turnabout, but I'm suddenly having flashbacks of "give the language a
rest". :)


Please don't construe this response as entirely negative. As I said
in other replies, I'm actually quite excited about these new things
and the directions they open up, and it may be that you and Dimitri
have been spending quite a lot of time thinking about them and their
implications to the language going forward. However, like the NG
branch prior to 7.0, most of this appears to lack any sort of plan for
those of us not in your private email threads. Yes, we've discussed
all of them at one point or another, but apart from the JIT, there's
been no obvious signs of work on any of them, which brings me back to
being concerned about 7.3 suddenly being flagged as the last 7.x
release within mere DAYS of its planned feature freeze branch date
without warning.

Possible alternative. Still aim for Nov 2019 GA of 8.0, but have a
7.4 in parallel with it. This (sort of) happened with 4.4 being
released between 5.0 and 5.1 (I know, not quite the same). This would
give us a couple advantages:

1/ Take our time with these last-minute "deprecate all the things"
RFCs that have suddenly popped up.
2/ Have an escape hatch to delay 8.0 till Nov 2020 if implementations
for the big stuff aren't quite ready for whatever reason rather than
being forced to push them to 9.0

Downsides, obvious: More merges for bugfixes and RM overhead, plus
Remi and Stephen's time with Fedora/Win32 builds. We did this for the
5.x-7.x jump, I say we can do it here.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ralph Schindler
Re: [PHP-DEV] PHP 2^3
June 25, 2018 05:00PM
On 6/25/18 9:13 AM, Johannes Schlüter wrote:
> On Mo, 2018-06-25 at 12:30 +0000, Zeev Suraski wrote:
>> 3. Foreign Function Interface support.
>
> Related to this on a non-PHP-code and strategic matter I would like to
> rethink PECL. Currently maintenance and installing extensions using it
> is a pita. This should be doable in a nicer way.

Is it worthwhile to also consider some form of safe runtime registration
of extensions (or extension-like whatever that looks like in a JIT
model).. A la dl()?

I realize in today's age of containerized projects (1 php install per
project, everything owned by root per-se) makes PHP with esoteric
extensions much easier, it still would be nice if I could composer
install a specific version of an extension; like xdebug in a
require-dev, or require one of the new kafka extensions at the project
level.

-ralph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski
Re: [PHP-DEV] PHP 2^3
June 25, 2018 05:10PM
Thanks for taking the time to respond!

On Mon, Jun 25, 2018 at 5:27 PM Sara Golemon <[email protected]> wrote:

> 1/ Pushing 8.0 as 7.3 + 1 means we're going to rush deprecations into
> 7.3 which is already in fire-hose mode of last-minute, under-planned
> "hey I want this toy" requests. Yes, deprecations are a little bit
> more sweaty ice cube in terms of late deprecations being lower risk
> that late additions, but it's still turning into a rushed thing during
> a season when some folks are off on holiday break. The FF is in
> Summer in part *because* this is a bad time to introduce RFCs.
>

Note that I did propose that we actually have a thin depredations-only PHP
7.4 (to give credit where credit's due, that's Dmitry's idea). This gives
us ample time without having to rush deprecations into 7.3

2/ In several of theses cases we're talking about something that's not
> even fully scoped out yet. Async, for example, "requires a lot more
> research". Yes, that research can probably be completed and turned
> into an implementation in the 1.5 years we have till the Nov 2019 GA
> (whatever version that ends up being), but there are multiple items on
> this list which are not (seemingly) fully fleshed out.
>

I think it's entirely unreaslitic (or remarkably optimistic if you prefer)
to think we'd have this done in under 18 months. There's still tons of
work we'd want to do in the JIT front, the work is entirely ahead of us as
far as async and preloading are concerned - and that's without even
factoring in the amount of time that discussions would take nor the fact
we're likely to still be busy with 7.3 for quite some time. Releasing it
at the end of 2019 effectively means we can squeeze such a huge version in
the same timeline we took for incredibly smaller versions like 7.1, 7.2 or
7.3. I think we're good, but we're not THAT good :) I also don't think
there's anything 'sacred' about releasing at the end of a particular year.


> 3/ When I read phrases like "open the door for new types of workloads
> for PHP (non Web)", and "one of the key reasons Node is gaining
> popularity", and " 'bleeding edge' technologies, such as AI and
> Machine Learning" I smell a trend of chasing the new hotness and
> worrying about factors other than making PHP the best language for the
> Web. Growing PHP is great, and evolving it into new areas is also
> potentially quite good, but we *have* history showing what happens
> when we come up with something new to chase after that then turns out
> to be underwhelming, undermaintained, and underutilized. I've also
> seen what a JIT does in terms of additional complexity, it's not
> pretty.
>

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.

With JIT - it's bit of a mixed bag. After so many efforts went into it and
we managed to get something pretty nice going - it was also a bit of a
solution looking for a problem. That's where the idea of expanding PHP to
other areas came from. And to be perfectly honest - it's not that I
invented this approach either - people have been using PHP for non-Web
workloads since forever. Plus, we're still hopeful that it would show
benefits for the Web world, especially in conjunction with preloading and
the fact it'll enable PHP-based built-in functions (which is another thing
we've wanted for a long time).

With FFI, I think the risks are low and the potential benefits are
substantial. Out of the major ideas, this is probably the one I'm mentally
least attached to - but here too, I see few downsides to doing it.

4/ When the $(%* did we body swap, because it's not quite full
> turnabout, but I'm suddenly having flashbacks of "give the language a
> rest". :)


People evolve :)


>
> Please don't construe this response as entirely negative. As I said
> in other replies, I'm actually quite excited about these new things
> and the directions they open up, and it may be that you and Dimitri
> have been spending quite a lot of time thinking about them and their
> implications to the language going forward. However, like the NG
> branch prior to 7.0, most of this appears to lack any sort of plan for
> those of us not in your private email threads. Yes, we've discussed
> all of them at one point or another, but apart from the JIT, there's
> been no obvious signs of work on any of them, which brings me back to
> being concerned about 7.3 suddenly being flagged as the last 7.x
> release within mere DAYS of its planned feature freeze branch date
> without warning.
>

I'm not taking your comments negatively at all! I do want to point out
that this time around everything we did was done in public as much as we
could - including both JIT and FFI. There hasn't been any meaningful
progress beyond some conference-style brainstorming regarding preloading
and async, virtually all of the work is ahead of us here. If this sounds
like it's messy, it's because it kind of is - because it's a lot more of a
plan-for-a-plan than it is an actual plan. Again, the main goal here is to
gauge the level of willingness of people to say that PHP 8 is going to be
the next feature release of PHP after 7.3, and to allocate a longer
timeline for us to successfully deliver it than the standard yearly cadence
(as was pretty much always the case with major versions). We will of
course discuss each and every one of the ideas separately. Of course, in
theory it's possible we'd shoot down all of the different ideas - but I'm
at least hopeful that wouldn't be the case and we'd have enough material
(both from these ideas and perhaps others) to release a major version
within 2-2.5 years.

Possible alternative. Still aim for Nov 2019 GA of 8.0, but have a
> 7.4 in parallel with it. This (sort of) happened with 4.4 being
> released between 5.0 and 5.1 (I know, not quite the same). This would
> give us a couple advantages:
>
> 1/ Take our time with these last-minute "deprecate all the things"
> RFCs that have suddenly popped up.
> 2/ Have an escape hatch to delay 8.0 till Nov 2020 if implementations
> for the big stuff aren't quite ready for whatever reason rather than
> being forced to push them to 9.0


I still think that Dmitry's idea that we have a deprecation-only 7.4
sometime in 2019 makes sense. If we really wanted to we could make it a
deprecation+some extras version, but I'm concerned about fragmenting our
scarce resources. I don't think the sky will fall in case we take 18-24
months between our last 7.x feature release and 8.0. We've had that
between 5.6 and 7.0 and I think it worked pretty well.

Thanks for the feedback!

Zeev
Sara Golemon
Re: [PHP-DEV] PHP 2^3
June 25, 2018 06:20PM
On Mon, Jun 25, 2018 at 9:58 AM, Zeev Suraski <[email protected]> wrote:
> Note that I did propose that we actually have a thin depredations-only PHP
> 7.4 (to give credit where credit's due, that's Dmitry's idea). This gives
> us ample time without having to rush deprecations into 7.3
>
I apologize. I had missed that in my initial reading, but you
certainly did propose that (or rather, Dimitry did, I suppose).
I agree with this tack.

> I think it's entirely unreaslitic (or remarkably optimistic if you prefer)
> to think we'd have this done in under 18 months. There's still tons of work
> we'd want to do in the JIT front, the work is entirely ahead of us as far as
> async and preloading are concerned - and that's without even factoring in
> the amount of time that discussions would take nor the fact we're likely to
> still be busy with 7.3 for quite some time. Releasing it at the end of 2019
> effectively means we can squeeze such a huge version in the same timeline we
> took for incredibly smaller versions like 7.1, 7.2 or 7.3. I think we're
> good, but we're not THAT good :) I also don't think there's anything
> 'sacred' about releasing at the end of a particular year.
>
Yeah, like I said, I must have completely missed that entire
paragraph. Mid-2020, following a late-2019 release of a "light" 7.4
with deprecations is reasonable, though I don't think it'd be such a
bad idea if we kept it on schedule to GA 8.0 with all the goodies in
Nov 2020. As alluded, I kind of like that FF happens in the summer
when things *should* be relatively slow otherwise.

> 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.

> With JIT - it's bit of a mixed bag. After so many efforts went into it and
> we managed to get something pretty nice going - it was also a bit of a
> solution looking for a problem. That's where the idea of expanding PHP to
> other areas came from. And to be perfectly honest - it's not that I
> invented this approach either - people have been using PHP for non-Web
> workloads since forever. Plus, we're still hopeful that it would show
> benefits for the Web world, especially in conjunction with preloading and
> the fact it'll enable PHP-based built-in functions (which is another thing
> we've wanted for a long time).
>
Right. And I'll add that although this same thing is true of HHVM's
JIT (that it's actually kind of naff on common web workloads), it's
also true that taking the wider view which includes things like whole
program analysis (a factor of which is the pre-loading you mentioned)
does make the usability of the JIT more impactful. I would also be
the last to argue against the ability to deliver some of PHP's
standard library in script form. There are even places where this can
provide a marginal, but non-zero gain over C implementations since
marshaling between internals and user-space code can be avoided, or
branches within the implementation can be elided by the optimizer. Ya
can't optimize what you can't see, and the optimizer can't see AoT
compiled C code.

Again, not arguing against any of these things in their own right. I
certainly appreciate the work that Dimitry and you and putting into
making this happen. My only concern (and I'll admit it's slightly
spurred by Niki's last minute proposal for typed properties) is timing
and our proximity to PHP-7.3's branch point.

> Again, the main goal here is to
> gauge the level of willingness of people to say that PHP 8 is going to be
> the next feature release of PHP after 7.3, and to allocate a longer timeline
> for us to successfully deliver it than the standard yearly cadence (as was
> pretty much always the case with major versions).
>
And based on the timetable that I realize I should have seen but
missed, you've got my vote.

> I still think that Dmitry's idea that we have a deprecation-only 7.4
> sometime in 2019 makes sense. If we really wanted to we could make it a
> deprecation+some extras version, but I'm concerned about fragmenting our
> scarce resources. I don't think the sky will fall in case we take 18-24
> months between our last 7.x feature release and 8.0. We've had that between
> 5.6 and 7.0 and I think it worked pretty well.
>
I'm not against some features for 7.4. I'd even say Niki's typed
properties (which isn't a minor change) can slot in there happily
enough. But we can dig in deeper over time on that. Maybe he gets it
into 7.3? ¯\_(ツ)_/¯

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Johannes Schlüter
Re: [PHP-DEV] PHP 2^3
June 25, 2018 06:40PM
On Mo, 2018-06-25 at 09:58 -0500, Ralph Schindler wrote:
> On 6/25/18 9:13 AM, Johannes Schlüter wrote:
> >
> > On Mo, 2018-06-25 at 12:30 +0000, Zeev Suraski wrote:
> > >
> > > 3. Foreign Function Interface support.
> > Related to this on a non-PHP-code and strategic matter I would like
> > to rethink PECL. Currently maintenance and installing extensions
> > using it is a pita. This should be doable in a nicer way.
> Is it worthwhile to also consider some form of safe runtime
> registration  of extensions (or extension-like whatever that looks
> like in a JIT model).. A la dl()?
>
> I realize in today's age of containerized projects (1 php install per
> project, everything owned by root per-se) makes PHP with esoteric 
> extensions much easier, it still would be nice if I could composer 
> install a specific version of an extension; like xdebug in a 
> require-dev, or require one of the new kafka extensions at the
> project level.
>

For a goal I agree, I however see hurdles on the way (need to avoid
startup costs on each request, eventually need to handle use of
different versions of the extension on subsequent requests) I believe a
more narrow and stable extension API might be a start for that.

johannes


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski
Re: [PHP-DEV] PHP 2^3
June 25, 2018 07:40PM
On Mon, Jun 25, 2018 at 7:16 PM Sara Golemon <[email protected]> wrote:

> Yeah, like I said, I must have completely missed that entire
> paragraph. Mid-2020, following a late-2019 release of a "light" 7.4
> with deprecations is reasonable, though I don't think it'd be such a
> bad idea if we kept it on schedule to GA 8.0 with all the goodies in
> Nov 2020. As alluded, I kind of like that FF happens in the summer
> when things *should* be relatively slow otherwise.
>

Well, my guesstimate for the timeline was actually 2-2.5yrs from now, so
that's ranging from mid 2020 to late 2020. You have a point that releasing
in summer isn't the smartest thing to do, so planning to hit later in that
year probably makes sense. I think we should probably keep ourselves some
flexibility on the final date as we see how the different projects progress
- perhaps September through December 2020.

And based on the timetable that I realize I should have seen but
> missed, you've got my vote.
>

Awesome!


> > I still think that Dmitry's idea that we have a deprecation-only 7.4
> > sometime in 2019 makes sense. If we really wanted to we could make it a
> > deprecation+some extras version, but I'm concerned about fragmenting our
> > scarce resources. I don't think the sky will fall in case we take 18-24
> > months between our last 7.x feature release and 8.0. We've had that
> between
> > 5.6 and 7.0 and I think it worked pretty well.
> >
> I'm not against some features for 7.4. I'd even say Niki's typed
> properties (which isn't a minor change) can slot in there happily
> enough. But we can dig in deeper over time on that. Maybe he gets it
> into 7.3? ¯\_(ツ)_/¯
>
> Personally I don't think that's 7.3 material, even when factoring out my
dislike for scalar properties in the way they're currently implemented, and
I think there's value in putting something as substantial as that in the
major version as another 'attraction point' for people to migrate. I'm
sure we'll discuss it thoroughly...

By the way, perhaps weak STH are another thing we can revisit for 8 - looks
like there were quite a few surprised folks out there regarding their
current behavior, and that implementing them closer to the old Coercive STH
RFC might be useful (without affecting the strict STH). Not sure I have
the mental strength for that though :)

Zeev
Larry Garfield
Re: [PHP-DEV] PHP 2^3
June 25, 2018 08:00PM
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 am, of course, possibly talking out of my butt here. Please advise if so.)

> > I still think that Dmitry's idea that we have a deprecation-only 7.4
> > sometime in 2019 makes sense. If we really wanted to we could make it a
> > deprecation+some extras version, but I'm concerned about fragmenting our
> > scarce resources. I don't think the sky will fall in case we take 18-24
> > months between our last 7.x feature release and 8.0. We've had that
> > between 5.6 and 7.0 and I think it worked pretty well.
>
> I'm not against some features for 7.4. I'd even say Niki's typed
> properties (which isn't a minor change) can slot in there happily
> enough. But we can dig in deeper over time on that. Maybe he gets it
> into 7.3? ¯\_(ツ)_/¯
>
> -Sara

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? Something else? I guess I'm missing why a 7.4 that
adds warnings about "stop doing this now so your code works in 8" would
conflict with a 7.4 that also adds whatever routine functionality or
improvements get developed in the meantime. (Typed properties or otherwise.)

Historical note: If we view PHP 5.3 as PHP 6 (which it was in any meaningful
sense), then PHP's had a remarkably consistent ~5 year run for each major
version for quite some time now. That would put November 2020 as the natural,
expected release date for 8.0, which especially if it's signaled now would
give everyone ample time to prepare and expect it right on schedule.

Also, while uptake of new PHP versions is still way slower than the release of
new PHP versions, at least based on the Composer data that Jordi releases it's
getting steadily better over time. The reasons for that are likely complex
but we're a long long way from the days when the GoPHP5 project was needed.
:-) (And good riddance to those days.)

--Larry Garfield
Zeev Suraski
Re: [PHP-DEV] PHP 2^3
June 25, 2018 09:20PM
On Mon, Jun 25, 2018 at 8:52 PM Larry Garfield <[email protected]>
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
Aaron Piotrowski
Re: [PHP-DEV] PHP 2^3
June 25, 2018 10:00PM
> On Jun 25, 2018, at 7:30 AM, Zeev Suraski <[email protected]> wrote:
>
>
> 2. Better support long-running, async-based, microservices-focused execution model. It's probably no secret that one of the key reasons Node is gaining popularity is because it can handle a huge number of concurrent connections issuing relatively lightweight requests very efficiently - which is a good match for modern microservices based architectures. There are already several projects available for PHP that aim to provide similar functionality - most notably ReactPHP and more recently Swoole.
> The main thing that is missing is that most of PHP's IO doesn't support async execution. What I think we should do is add as much support for async IO as possible across the various extensions and streams - so that using something like Swoole would become practical for more use cases. More specifically - the goal would be to provide extension authors with mechanisms that they can use to make their extensions/functions optionally asynchronous, without having to tackle the job entirely on their own. While we've done some research into this area, it requires a lot more research - but I'm cautiously optimistic that it can be done. We would potentially want to use libuv for this task, and potentially rewrite or otherwise refactor parts of the PHP streams system.
>

Regarding async, are you referring to the Fiber extension? In my opinion, fibers would be the best approach for async in PHP. After using async/await in other languages, it doesn't offer a significant gain over what's already possible in PHP with generator-based coroutines in Amp. Using the fiber extension and a green-thread library that resumes fibers based on promise resolution [1], we've been able to write async code without the need for yield or await [2], with async functions having proper return types (i.e. not promise, but the type the promise would resolve to). Joel Wurtz has also put together a PoC of using Doctrine asynchronously using the fiber extension and Amp [3].

A new major may not be strictly necessary to introduce this feature, but it would ease introducing new keywords for awaiting IO and "promisifying" a function using fibers to allow simultaneous IO. These keywords could be async and await, though they would be used differently than JavaScript or other languages. See an example in the green-thread library [4], where the await() function uses Fiber::yield() to wait for promise resolution, and async() creates a promise from a function using await(). I would propose using keywords in place of these two functions.

I successfully am using Amp's http-server library with several other Amp libraries to run a website using long-running processes under PHP 7.2. I've seen no issues with memory leaks, crashing processes, or other unexpected behaviors. I think PHP is absolutely ready to shine in environments outside of per-request SAPIs. Core support for async is one of the few ingredients missing.

Aaron Piotrowski

[1] https://github.com/amphp/green-thread
[2] https://github.com/amphp/byte-stream/tree/ext-fiber
[3] https://github.com/joelwurtz/doctrine-async
[4] https://github.com/amphp/green-thread/blob/e13327a84be67d289aec87984f9d5c8e1fddd471/examples/simultaneous-async.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Larry Garfield
Re: [PHP-DEV] PHP 2^3
June 25, 2018 10:50PM
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
Zeev Suraski
RE: [PHP-DEV] PHP 2^3
June 25, 2018 11:40PM
> -----Original Message-----
> From: Larry Garfield [mailto:[email protected]]
> Sent: Monday, June 25, 2018 11:43 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] PHP 2^3
>
> 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?

The reality of things is that very few patches make it into the engine
without the (very few) core engine developers closely reviewing them, and
sometimes greatly refactoring them. It might feel like it's happening
automatically, but it doesn't - it's a lot of effort.
Separately, it wouldn't or at least shouldn't be "Dmitry figuring out
async". It needs to be a group effort, which I'm sure Dmitry would greatly
contribute to - especially around the infrastructure - but then there'll
likely be the group effort of async-enabling our various extensions.
Letting the core devs do the heavy lifting while the rest are playing with
other things isn't a very nice or sustainable strategy. And as unpopular as
this may be, this should (IMHO) be primarily up to the core devs who are in
fact doing the heavy lifting - we need to design the development schedule to
make their job the easiest, as it's already remarkably tough.

> 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.

As I mentioned elsewhere I do see value in it even if it's a
deprecation-only version, effectively a 7.3.(n+1) with deprecations, where
migration costs are no different than to any other 7.3.x (i.e. very low,
guaranteed), and you get a version that can ease you into PHP 8 around a
year ahead of time. We could even just introduce a certain switch allowing
you to enable these deprecations in a real 7.3.x release, without calling it
7.4 now that I think of it.

Note that it's not just about the raw amount of coding or discussion hours -
it's also about the state of mind. If our top goal after 7.3 is to release
8.0 - I'm sure people can figure out ways to help this cause. If we have
two concurrent projects, people would go for their comfort zones.

Zeev



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] PHP 2^3
June 25, 2018 11:50PM
On 25/06/2018 21:42, Larry Garfield wrote:
>> 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.


I keep coming back recently to the idea of native support for "packages"
or "modules":

- a bunch of classes edited as separate files, but loaded "in one hit",
rather than autoloaded one class at a time
- a more "solid" namespace, e.g. visible in Reflection
- configuration of declare()-style directives that apply to the whole module
- "module private" visibility for classes (and maybe, later, methods,
although the phrase "private protected" [1] makes my head hurt)

I think this would fit naturally with preloading, and making OpCache
(and JIT) more central to the engine, and fits more naturally with where
things like Composer and PHP-FIG have taken the language.

It might even link to FFI - maybe a module linking to C functions in a
certain way could act as a light-weight, dynamically-loadable, extension.

I realise I'm dreaming now, and don't expect this to all suddenly appear
in 8.0, but I wonder if it's worth exploring as a framework to build
around / toward?


[1]:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/access-modifiers

Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alice Wonder
Re: [PHP-DEV] PHP 2^3
June 26, 2018 01:20AM
On 06/25/2018 07:13 AM, Johannes Schlüter wrote:
> On Mo, 2018-06-25 at 12:30 +0000, Zeev Suraski wrote:
>> 3. Foreign Function Interface support.
>
> Related to this on a non-PHP-code and strategic matter I would like to
> rethink PECL. Currently maintenance and installing extensions using it
> is a pita. This should be doable in a nicer way.
> (i.e. pecl pointing directly to Git(Hub) repos, similar to composer, a
> way to install precompiled binaries, probably using a more narrow
> stable API, better reporting of dependency issues, with the new
> execution model of your point 2 also better integration with composer,
> ...)
>
> johannes
>

As a packager github is a fracking nightmare.

Frequently what we do is include a hash of the release tarball in our
build and require that it matches so that people rebuilding our package
(e.g. to add a patch they need) don't have to trust us, they can use our
build spec file but fetch the upstream source themselves, and the hash
matches lets them know that what they fetched from upstream is identical
to what the initial packager used.

But with github getting the url to the actual download is tricky and
often breaks and also I've seen the hash from the release tarball on
github differ from the hash the release tarball on the project site
numerous times.

git is for code management but when a release it tagged, creation of the
source tarball should be done by the developer, and released by the
developer, preferably with sha256 or sha512 sums posted in an easy to
find location (which github doesn't do)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] PHP 2^3
June 26, 2018 10:10AM
On 26/06/18 00:14, Alice Wonder wrote:
> git is for code management but when a release it tagged, creation of the
> source tarball should be done by the developer, and released by the
> developer, preferably with sha256 or sha512 sums posted in an easy to
> find location (which github doesn't do)

Or run Hg to handle the packaging ... although I started a sync of
php-src of my Hg clone last week, and it's still only 12841 of 20519
commits in and still running. Access to the web view is down currently
until I work out how to make that work with PHP7 :(

Anybody remember when it was easy to sort out just which tools one used?
Nowadays with the range of languages all using different methods and
everybody pushing their own agendas, it WOULD be nice to have a simple
solution to the web based framework that we can rely on for the next ten
years ... and not have to be proficient in several languages to make a
set of tools work.

And I'm waiting for the demand for Oracle's java subscription to allow
me to continue to use Eclipse as the main IDE ...

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Johannes Schlüter
Re: [PHP-DEV] PHP 2^3
June 26, 2018 04:40PM
On Mo, 2018-06-25 at 16:14 -0700, Alice Wonder wrote:
> As a packager github is a fracking nightmare.
>
> Frequently what we do is include a hash of the release tarball in our
> build and require that it matches so that people rebuilding our
> package (e.g. to add a patch they need) don't have to trust us, they
> can use our build spec file but fetch the upstream source themselves,
> and the hash matches lets them know that what they fetched from
> upstream is identical  to what the initial packager used.
>
> But with github getting the url to the actual download is tricky and 
> often breaks and also I've seen the hash from the release tarball on 
> github differ from the hash the release tarball on the project site 
> numerous times.

Well, with git the url is repository URL+hash. A tarball not
necessarily bring rebuildability. I have seen different projects
replacing tarballs without changing version numbers etc.

Anyways those are details to be discussed outside this specific thread.

My point is that PECL is in a bad state from usability, both for
extension authors as well as users and I think a "PHP 8" headline might
be a good time to redefine this. But this needs work (and I also
directly say that I can't promise much time myself) so if others share
the pain and want to solve/improve this, I'd be happy to help
coordinating this.

johannes


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Dmitry Stogov
Re: [PHP-DEV] PHP 2^3
June 26, 2018 06:40PM
hi Aaron,


On Jun 25, 2018 10:49 PM, Aaron Piotrowski <[email protected]> wrote:

> On Jun 25, 2018, at 7:30 AM, Zeev Suraski <[email protected]> wrote:
>
>
> 2. Better support long-running, async-based, microservices-focused execution model. It's probably no secret that one of the key reasons Node is gaining popularity is because it can handle a huge number of concurrent connections issuing relatively lightweight requests very efficiently - which is a good match for modern microservices based architectures. There are already several projects available for PHP that aim to provide similar functionality - most notably ReactPHP and more recently Swoole.
> The main thing that is missing is that most of PHP's IO doesn't support async execution. What I think we should do is add as much support for async IO as possible across the various extensions and streams - so that using something like Swoole would become practical for more use cases. More specifically - the goal would be to provide extension authors with mechanisms that they can use to make their extensions/functions optionally asynchronous, without having to tackle the job entirely on their own. While we've done some research into this area, it requires a lot more research - but I'm cautiously optimistic that it can be done. We would potentially want to use libuv for this task, and potentially rewrite or otherwise refactor parts of the PHP streams system.
>

Regarding async, are you referring to the Fiber extension? In my opinion, fibers would be the best approach for async in PHP. After using async/await in other languages, it doesn't offer a significant gain over what's already possible in PHP with generator-based coroutines in Amp. Using the fiber extension and a green-thread library that resumes fibers based on promise resolution [1], we've been able to write async code without the need for yield or await [2], with async functions having proper return types (i.e. not promise, but the type the promise would resolve to). Joel Wurtz has also put together a PoC of using Doctrine asynchronously using the fiber extension and Amp [3].

Febers/couroutines is one of the goals.
Another possible goal — event-loop primitives for internal extensions (e.g. async DB queries)
I think, we don't need async/await keywords or promises implementation in core
Anyway, as an expert in async PHP, you should tell us, what you really need from the PHP core...
I would be glad to hear your oppinion.

Thanks. Dmitry.



A new major may not be strictly necessary to introduce this feature, but it would ease introducing new keywords for awaiting IO and "promisifying" a function using fibers to allow simultaneous IO. These keywords could be async and await, though they would be used differently than JavaScript or other languages. See an example in the green-thread library [4], where the await() function uses Fiber::yield() to wait for promise resolution, and async() creates a promise from a function using await(). I would propose using keywords in place of these two functions.

I successfully am using Amp's http-server library with several other Amp libraries to run a website using long-running processes under PHP 7.2. I've seen no issues with memory leaks, crashing processes, or other unexpected behaviors. I think PHP is absolutely ready to shine in environments outside of per-request SAPIs. Core support for async is one of the few ingredients missing.

Aaron Piotrowski

[1] https://github.com/amphp/green-thread
[2] https://github.com/amphp/byte-stream/tree/ext-fiber
[3] https://github.com/joelwurtz/doctrine-async
[4] https://github.com/amphp/green-thread/blob/e13327a84be67d289aec87984f9d5c8e1fddd471/examples/simultaneous-async.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Niklas Keller
Re: [PHP-DEV] PHP 2^3
June 26, 2018 10:40PM
Hey Dmitry,

>
> hi Aaron,
>
>
> On Jun 25, 2018 10:49 PM, Aaron Piotrowski <[email protected]> wrote:
>
> > On Jun 25, 2018, at 7:30 AM, Zeev Suraski <[email protected]> wrote:
> >
> >
> > 2. Better support long-running, async-based, microservices-focused execution model. It's probably no secret that one of the key reasons Node is gaining popularity is because it can handle a huge number of concurrent connections issuing relatively lightweight requests very efficiently - which is a good match for modern microservices based architectures. There are already several projects available for PHP that aim to provide similar functionality - most notably ReactPHP and more recently Swoole.
> > The main thing that is missing is that most of PHP's IO doesn't support async execution. What I think we should do is add as much support for async IO as possible across the various extensions and streams - so that using something like Swoole would become practical for more use cases. More specifically - the goal would be to provide extension authors with mechanisms that they can use to make their extensions/functions optionally asynchronous, without having to tackle the job entirely on their own. While we've done some research into this area, it requires a lot more research - but I'm cautiously optimistic that it can be done. We would potentially want to use libuv for this task, and potentially rewrite or otherwise refactor parts of the PHP streams system.
> >
>
> Regarding async, are you referring to the Fiber extension? In my opinion, fibers would be the best approach for async in PHP. After using async/await in other languages, it doesn't offer a significant gain over what's already possible in PHP with generator-based coroutines in Amp. Using the fiber extension and a green-thread library that resumes fibers based on promise resolution [1], we've been able to write async code without the need for yield or await [2], with async functions having proper return types (i.e. not promise, but the type the promise would resolve to). Joel Wurtz has also put together a PoC of using Doctrine asynchronously using the fiber extension and Amp [3].
>
> Febers/couroutines is one of the goals.
> Another possible goal — event-loop primitives for internal extensions (e.g. async DB queries)
> I think, we don't need async/await keywords or promises implementation in core
> Anyway, as an expert in async PHP, you should tell us, what you really need from the PHP core...
> I would be glad to hear your oppinion.
>
> Thanks. Dmitry.

Fibers are the major feature we're looking forward to, because it
allows async I/O in places that do not account for async, e.g. also
re-using interfaces designed for sync applications. Apart from that,
we want to avoid the boilerplate we currently have to write, i.e.
Amp\call wrapping a generator function.

We think that a methodless "Promise" / "Awaitable" type + fibers
implemented with keywords are the preferred way over the current Fiber
draft in the long run.

Fibers allow for transparent async I/O, which means we could maybe
transparently upgrade file_get_contents and others to use async I/O in
future versions, but something like that obviously needs an event-loop
in core.

That said, it's definitely something we want to push to PHP 8, but
nothing that has to be discussed in too much detail in this thread.

Regards, Niklas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Dmitry Stogov
Re: [PHP-DEV] PHP 2^3
June 27, 2018 08:50AM
Hi Niklas,

On Jun 26, 2018 11:36 PM, Niklas Keller <[email protected]> wrote:
Hey Dmitry,

>
> hi Aaron,
>
>
> On Jun 25, 2018 10:49 PM, Aaron Piotrowski <[email protected]> wrote:
>
> > On Jun 25, 2018, at 7:30 AM, Zeev Suraski <[email protected]> wrote:
> >
> >
> > 2. Better support long-running, async-based, microservices-focused execution model. It's probably no secret that one of the key reasons Node is gaining popularity is because it can handle a huge number of concurrent connections issuing relatively lightweight requests very efficiently - which is a good match for modern microservices based architectures. There are already several projects available for PHP that aim to provide similar functionality - most notably ReactPHP and more recently Swoole.
> > The main thing that is missing is that most of PHP's IO doesn't support async execution. What I think we should do is add as much support for async IO as possible across the various extensions and streams - so that using something like Swoole would become practical for more use cases. More specifically - the goal would be to provide extension authors with mechanisms that they can use to make their extensions/functions optionally asynchronous, without having to tackle the job entirely on their own. While we've done some research into this area, it requires a lot more research - but I'm cautiously optimistic that it can be done. We would potentially want to use libuv for this task, and potentially rewrite or otherwise refactor parts of the PHP streams system.
> >
>
> Regarding async, are you referring to the Fiber extension? In my opinion, fibers would be the best approach for async in PHP. After using async/await in other languages, it doesn't offer a significant gain over what's already possible in PHP with generator-based coroutines in Amp. Using the fiber extension and a green-thread library that resumes fibers based on promise resolution [1], we've been able to write async code without the need for yield or await [2], with async functions having proper return types (i.e. not promise, but the type the promise would resolve to). Joel Wurtz has also put together a PoC of using Doctrine asynchronously using the fiber extension and Amp [3].
>
> Febers/couroutines is one of the goals.
> Another possible goal — event-loop primitives for internal extensions (e.g. async DB queries)
> I think, we don't need async/await keywords or promises implementation in core
> Anyway, as an expert in async PHP, you should tell us, what you really need from the PHP core...
> I would be glad to hear your oppinion.
>
> Thanks. Dmitry.

Fibers are the major feature we're looking forward to, because it
allows async I/O in places that do not account for async, e.g. also
re-using interfaces designed for sync applications. Apart from that,
we want to avoid the boilerplate we currently have to write, i.e.
Amp\call wrapping a generator function.

We already have ext/fiber proposal and additioal branch implementing stack-full fibers.
I think, we'll build fibers in the PHP core reusing this work, keeping the proposed API and behavior.


We think that a methodless "Promise" / "Awaitable" type + fibers
implemented with keywords are the preferred way over the current Fiber
draft in the long run.

This is too abstract.
What keywords do you like for fibers and why do we need them?
Why do we need Promise/Awaitable in the core?
If you have concrete solution (just API), lets discuss it in separate email thread.


Fibers allow for transparent async I/O, which means we could maybe
transparently upgrade file_get_contents and others to use async I/O in
future versions, but something like that obviously needs an event-loop
in core.

May be yes, may be not. Event-loop may be implemented in PHP, but perform integration with internal functions, through special interface (e.g. allow internal function to post compltion events into the event queue). Anyway, there is no any formed plan about event-loop in core. I hope, the experience of AMP team, would help us to make good decision. And I count on Bob, regarding implementation.

Thanks. Dmitry.


That said, it's definitely something we want to push to PHP 8, but
nothing that has to be discussed in too much detail in this thread.

Regards, Niklas
Aaron Piotrowski
Re: [PHP-DEV] PHP 2^3
June 27, 2018 06:20PM
> On Jun 27, 2018, at 1:48 AM, Dmitry Stogov <[email protected]> wrote:
>
> Hi Niklas,
>
> Fibers are the major feature we're looking forward to, because it
> allows async I/O in places that do not account for async, e.g. also
> re-using interfaces designed for sync applications. Apart from that,
> we want to avoid the boilerplate we currently have to write, i.e.
> Amp\call wrapping a generator function.
>
> We already have ext/fiber proposal and additioal branch implementing stack-full fibers.
> I think, we'll build fibers in the PHP core reusing this work, keeping the proposed API and behavior.
>

I concur with Niklas - Fibers are the major feature needed, the stack-full branch in particular. Being able to reuse so much existing PHP code is particularly exciting. Most modern, testable PHP code performing IO should allow for async IO implementations, since IO should be mockable to be properly tested.

>
> We think that a methodless "Promise" / "Awaitable" type + fibers
> implemented with keywords are the preferred way over the current Fiber
> draft in the long run.
>
> This is too abstract.
> What keywords do you like for fibers and why do we need them?
> Why do we need Promise/Awaitable in the core?
> If you have concrete solution (just API), lets discuss it in separate email thread.

Niklas and/or I will put something together and start a new thread.

Regards,
Aaron Piotrowski
Yasuo Ohgaki
Re: [PHP-DEV] PHP 2^3
September 20, 2018 10:30PM
On Mon, Jun 25, 2018 at 9:30 PM, Zeev Suraski <[email protected]> wrote:
>
> Thoughts?
>

Since PHP 8 is going to open more doors for general purpose scripting
usages, how about reconsidering "Default embed mode always"?
i.e. Execute PHP script without "<?php"

https://wiki.php.net/rfc/nophptags
https://wiki.php.net/rfc/source_files_without_opening_tag

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net
Sorry, only registered users may post in this forum.

Click here to login