PHP 8: what to expect. Letter of Zeev Suraski

Hi, my name is Nikolay Krapivny, I lead the server-side development department at Badoo. In Badoo, PHP is one of the main languages ​​and most of the business logic of our system is written in it. Therefore, we follow the news from the world of PHP, actively participate in the development of the language and try to develop a community around PHP .

Today I would like to share a translation of the letter from Zeev Suraski , one of the founders of Zend Technologies, which outlines the further development of PHP and sheds light on what we can expect in PHP 8.

I was going to write about this a little later, but since I’ve raised the topic of PHP 8, it seems it’s time to start a discussion.

I emphasize that the purpose of this letter is not to discuss in detail every change I mentioned, but rather to consolidate our plans: are we going after 7.3 to focus on PHP 8, which is based on some of our research projects and experimental designs.

There are a number of areas for the development of which, I think, it is necessary to direct resources in the next major version.

JIT

Probably many of you know that we have spent a lot of effort on implementing JIT over the PHP 7 infrastructure. There is good and bad news. Good: as was the case with the experiments with JIT, which we carried out in 2014, we obtained impressive results of benchmarks with heavy CPU loads. And the bad news is that the JIT for our tests does not give a big win on typical web loads.

In other words, unlike the situation in 2014, we believe that JIT will not improve performance when handling typical web workloads, since the execution of PHP code is no longer a bottleneck.

But I still think that we need to include JIT in the next major version of PHP. At least for two reasons:

• This will allow PHP to handle new types of workloads (not the web).
  
• This allows you to write for PHP a new built-in functionality that will increase the security of the code (for example, a PHP implementation unserialize()instead of the C version).
  

In addition, there is always the possibility that we are missing something in our benchmarks, and that there are web loadings that will speed up processing ( note Badoo: a good example. At our scale, CPU consumption is critical, we do a lot of CPU consumption optimization and usually we greatly benefit from language optimizations ).

It is worth noting that, in all likelihood, as part of our work on JIT, we will want to make OPcache (or at least most of it) an element of the main engine, rather than a separate extension.

• (Bonus) in combination with some other developments, it can still improve the performance of web applications.
  

So that you understand the performance gains in question, I recorded a comparison of PHP 7.0 benchmarks and experimental JIT development: https://www.youtube.com/watch?v=dWH65pmnsrI

Asynchrony

We need to concentrate on improving the support for the long-running (asynchronous performance model focused on microservices). Probably, it is no secret that one of the main reasons for the popularity of Node.js is its ability to very effectively handle a huge number of simultaneous connections that generate relatively light queries. This fits well with the features of modern microservice architectures. There are already several projects that implement similar functionality in PHP, for example, ReactPHP and the more recent Swoole.

But the main problem is that most of the input-output operations in PHP do not support asynchronous execution. I think we need to add as much as possible support for asynchronous I / O in various extensions and threads to expand the range of tasks where it makes sense to use tools like Swoole. More precisely, the authors of extensions should be offered mechanisms that they could use to implement the optional asynchrony of their extensions / functions without doing all the work themselves. We have already done some research in this direction, and much more needs to be done, but I am optimistic. Perhaps to solve this problem, we take libuv, and, perhaps, rewrite or refactor some parts of the PHP stream system.

Foreign Function Interface

This will allow you to connect PHP to native libraries written in C or C ++, without the need to create an extension. I understand that this may not look much better than extensions, but if you evaluate not only the complexity of the implementation, but also the possible impact of this innovation, then its scale will become clear. This will allow far more frequent use of PHP in conjunction with "advanced" technologies, such as artificial intelligence and machine learning; And not only with the already existing today - this is a kind of "groundwork" for future use with the technologies that will appear. Dmitry ( note: Dmitry Stogov) has already achieved some results in this direction. The last couple of weeks he spent on creating TensorFlow bindings for PHP, and wrote, apparently, the first neural network in PHP: it recognizes handwritten numbers with an accuracy of 98% . I think that in combination with JIT this will turn PHP into a real workhorse for executing heavy applications without compromising the productivity of developers. By the way, in order for this mechanism to work really quickly (especially when paired with JIT), we will most likely combine it with the main engine, and we will not make it a separate extension.

Preloading support

We have discussed this several times at a high level, but if we implement JIT in PHP 8, then support for preloading can supplement it well. It will allow you to develop "extensions" in PHP, not only in C (or FFI). In combination with JIT, the cost of writing logic in PHP will drop dramatically, and this will be better in terms of both simplicity and security. In addition, preloading can significantly increase the speed of web applications, because we can resolve certain dependencies (mostly inheritance) during compilation, not execution.(note: Dmitry Stogov gave us a more specific description of this idea: “The idea is to load PHP scripts when PHP starts; the functions and classes defined in them will be available to all request servers without any include / require. In essence, this gives the ability to write standard PHP libraries. ”A discussion of this can be read here .)

I note that this list:

• Incomplete. If a feature is not mentioned here, this does not mean that it will not be in PHP 8.
  
• Not carved in stone. Of course, we need to have an RFC for each of the ideas mentioned, but we may not be able to cope with the implementation of some of these ideas.
  

This list is a series of areas in which we have conducted certain studies (in some of them even very serious ones, as is the case with JIT), and which are a solid basis for starting the discussion about PHP 8 and turning PHP 7.3 into the latest release in the PHP 7 family. x. If we had to formulate assumptions about the availability of PHP 8 for release on the basis of all the above, it will probably be in 2-2.5 years (that is, the middle / end of 2020). We can also discuss a very modest release of PHP 7.4 somewhere in 2019, in which the new functionality will not be added, but which will allow us to declare obsolete (deprecate) everything that really deserves, and that we forgot to declare obsolete in PHP 7.3, to allow everyone to prepare in advance for PHP 8.

With the help of this letter, I would like to understand the attitude to the transfer of efforts to create PHP 8 after the release of 7.3, as well as listen to your opinion on the above features. If the feedback is positive, I think the next step would be to write the RFC “PHP 8 as the next PHP feature release,” with possible provisions for 7.4; and then a separate discussion of all the above (as well as other) innovations. We can try to formulate a certain schedule, but some items can be shifted to the right (up to a certain limit) if their research / development / refinement takes more time.

From myself I would add that it is joyful to see the active development of the language in recent years and the team’s sound desire to work both on performance and on “generalizing” the language and improving its capabilities. All areas of work look promising, especially interesting for us are the improvements in CPU consumption and the ability to work with asynchronous I / O.

And what do you think about the described plans for PHP 8 and the prospects for PHP as a whole? Share your thoughts in the comments.