PHP 2^3

> 3. Foreign Function Interface support. 

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

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

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

> On Jun 25, 2018, at 7:30 AM, Zeev Suraski <zeev@zend.com> 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. >

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

> > Thoughts? >