Re: PHP 2^3

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