On 25.06.2018 at 14:30, Zeev Suraski 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. > > 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?
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
