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:
- 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
-
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. -
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.
-
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
- 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
- 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
- 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 ladl()?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
- 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)
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
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
- 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 PHPunserialize()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=dWH65pmnsrArgh - the URL was trimmed - that's the correct one:
https://www.youtube.com/watch?v=dWH65pmnsrI
Zeev
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
Thanks for taking the time to respond!
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
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
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
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
On Mon, Jun 25, 2018 at 8:52 PM Larry Garfield larry@garfieldtech.com
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 systemwith 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
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 thenthrowing 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
systemwith 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
-----Original Message-----
From: Larry Garfield [mailto:larry@garfieldtech.com]
Sent: Monday, June 25, 2018 11:43 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 2^3That'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
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?
Regards,
--
Rowan Collins
[IMSoP]
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.
Why not stick with our yearly release cycle, and ship 7.4.0 in Dec 2019
and 8.0.0 in Dec 2020?
--
Christoph M. Becker
On Mon, Jun 25, 2018 at 5:57 PM Christoph M. Becker cmbecker69@gmx.de
wrote:
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.Why not stick with our yearly release cycle, and ship 7.4.0 in Dec 2019
and 8.0.0 in Dec 2020?
We could and I think we should, but I don't think 7.4 should be a feature
release - but rather another release where we can deprecate things without
rushing them into 7.3, and at the same time provide people with a smoother
upgrade path to 8.0 (even though as you know, I'm not the biggest fan of
compatibility breakages...). We've never been successful at working on two
active-development branches at the same time, and with the resource levels
we have - I don't think it's practical.
To be perfectly honest, I don't think our userbase for the most part is
actually consuming the feature releases at nearly the frequency that we're
producing them. It's a healthy release cycle, but I really don't think
that there would be any meaningful downside to have two years between the
last feature-release 7.x and 8.0.
Zeev
On Mon, Jun 25, 2018 at 5:57 PM Christoph M. Becker cmbecker69@gmx.de
wrote: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.Why not stick with our yearly release cycle, and ship 7.4.0 in Dec 2019
and 8.0.0 in Dec 2020?We could and I think we should, but I don't think 7.4 should be a feature
release - but rather another release where we can deprecate things without
rushing them into 7.3, and at the same time provide people with a smoother
upgrade path to 8.0 (even though as you know, I'm not the biggest fan of
compatibility breakages...). We've never been successful at working on two
active-development branches at the same time, and with the resource levels
we have - I don't think it's practical.
I think it makes sense for big engine changes that you described but I
don't think this should be the case for features in core extensions and
SAPI's. The thing is that some of us are not going to work on those big
changes for various reasons. Personally I work mainly on fpm, openssl as
well as some other stuff and just don't have time to do anything else atm.
My features are not really so big that they should wait 2 years. The thing
is that this type of changes won't usually conflict with engine changes so
there should be no reason to delay it.
So I think it would be good idea to lock the engine (possibly create a
special branch for all the new changes into it) and release 7.4 and maybe
7.5 (in case 8.0 is not ready in time) with just deprecations and features
in extensions and SAPI's.
Cheers
Jakub
I think it makes sense for big engine changes that you described but I
don't think this should be the case for features in core extensions and
SAPI's. The thing is that some of us are not going to work on those big
changes for various reasons. Personally I work mainly on fpm, openssl as
well as some other stuff and just don't have time to do anything else atm.
My features are not really so big that they should wait 2 years. The thing
is that this type of changes won't usually conflict with engine changes so
there should be no reason to delay it.So I think it would be good idea to lock the engine (possibly create a
special branch for all the new changes into it) and release 7.4 and maybe
7.5 (in case 8.0 is not ready in time) with just deprecations and features
in extensions and SAPI's.
This was my first thought as well, but considering the changes that PHP
7 required for all extensions, working on 7.4 and 8.0 simultaneously
may easily lead to hard to resolve merge conflicts, and even to subtle
breakages.
However, instead of locking 7.4 for everything but deprecations in
advance, we may consider to decide on a case-by-case basis if a new
feature should target 7.4 or 8.0.
--
Christoph M. Becker
On Wed, Jun 27, 2018 at 2:10 PM, Christoph M. Becker cmbecker69@gmx.de
wrote:
I think it makes sense for big engine changes that you described but I
don't think this should be the case for features in core extensions and
SAPI's. The thing is that some of us are not going to work on those big
changes for various reasons. Personally I work mainly on fpm, openssl as
well as some other stuff and just don't have time to do anything else
atm.
My features are not really so big that they should wait 2 years. The
thing
is that this type of changes won't usually conflict with engine changes
so
there should be no reason to delay it.So I think it would be good idea to lock the engine (possibly create a
special branch for all the new changes into it) and release 7.4 and maybe
7.5 (in case 8.0 is not ready in time) with just deprecations and
features
in extensions and SAPI's.This was my first thought as well, but considering the changes that PHP
7 required for all extensions, working on 7.4 and 8.0 simultaneously
may easily lead to hard to resolve merge conflicts, and even to subtle
breakages.
Well it was mainly about changing the zval but I guess it won't be the same
for 8.0 unless there are some plans for big breaking changes. It would
probably make sense to reconsider in that case but if the ABI stays the
same or the changes are minimal, then it shouldn't block new features to
the extensions IMO. In terms of SAPI's like FPM, it's a bit different as it
is mostly independent code and most of the features can be released without
any conflict even if the engine ABI changes considerably.
Cheers
Jakub
- 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
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:
- 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
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.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.
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?
7.3 is in RC stage, and we're already targeting 7.4 (the “Typed
Properties 2.0”[1] and “Deprecations for PHP 7.4”[2] RFCs, for
instance), so in my opinion, we should lay out the roadmap for PHP 8 as
soon as possible. Otherwise we may have to postpone PHP 8 even further,
and/or risk to create confusion.
If desired I could aid in drafting a respective RFC.
[1] https://wiki.php.net/rfc/typed_properties_v2
[2] https://wiki.php.net/rfc/deprecations_php_7_4
--
Christoph M. Becker
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