Comprehensive interpretation of php8.0 version optimization and improvements

Unless you have been living under a rock, or living in the past, you will realize that JIT is entering PHP 8: Vote Today ended quietly. The vast majority of people agreed to merge to PHP8, so this is official. This article comprehensively explains the optimization and improvement of the php8.0 version.

PHP8 official announcement "PHP 8 is coming! The PHP team has released its first beta version, Alpha 1 of confusion and dig into how it works (but only a little bit because I don't want to bore you).

Since I don't know who I'm talking to, I'll start with simple questions and work my way up to complex ones, which you can skip if you're already sure you know the answer to the question in the title That part. . .

What is JIT?

PHP implements a virtual machine, a virtual processor, which we call Zend VM. PHP compiles human-readable scripts into instructions (we call them opcodes) that the virtual machine can understand. This execution stage is what we call "compile time". During the "runtime" phase of execution, the virtual machine (Zend VM) executes the code's instructions (opcodes). This all works great, tools like APC (in the past) and OPCache (now) can cache the code's instructions (opcodes) so that "compile time" only happens when it must.

First, there is a line of code that explains what JIT is:

Just-in-time

is a compiler strategy that accepts an intermediate representation of the code and Convert this to architecture-dependent machine code at runtime for timely execution.

In PHP, this means that the JIT will use the instructions generated by Zend VM as an intermediate representation and emit architecture-dependent machine code, so the host of the code is no longer ZendVM, but the CPU.

Why does PHP need JIT?

Before PHP 7.0, the focus of the PHP internal community was performance, which was brought about by healthy competition brought about by Facebook's HHVM project. Most of the core changes in PHP 7.0 were included in the PHPNG patch, which greatly improved the way PHP utilized memory and CPU on its core, and since then, everyone of us has been forced to focus on performance. Since PHP 7.0, there have been some performance improvements, optimization of

HashTable

(PHP's core data structure), Zend VM specialization of certain opcodes, certain sequences of Compiler specialization, and ongoing improvements to OPCache's optimizer component. . . There's so much else besides that, it's so boring.

It's a hard truth that these optimizations can only take us so far and we are rapidly approaching, or may have hit a brick wall in our ability to improve it further.

NOTE:

When we say, "We can't improve it any more," what we really mean is, "We have to make trade-offs to further improve it no longer looks like is attractive". . . Whenever we discuss performance optimization, we are discussing trade-offs. Often, there is a trade-off between simplicity and performance. We all like to think that the simplest code is the fastest code, but in the modern world of C programming, this is not the case. The fastest code is usually code that is prepared to take advantage of architecture-dependent intrinsics or platform (compiler)-dependent intrinsics. Simplicity does not guarantee the best performance. . .

At this time, PHP's JIT functionality seems to be the best way to get more performance from PHP.

Will JIT make my website faster?

Possible, not obvious. Maybe not the answer you expected: In general, applications written in PHP are

I/O bound

,

JIT

on the CPU Works best on code that binds . What exactly does "I/O and CPU binding" mean?

When we want to describe the general performance characteristics of a piece of code or an application, we use the terms I/O bound and

CPU bound

. The simplest way to put it is:

If we can improve (reduce, optimize) the I/O it does, then a piece of I/O bound code will run faster.

• A piece of CPU-bound code will run faster if we can improve (reduce, optimize) the instructions the CPU is executing, or (magically) increase the clock speed of the CPU :)

• A piece of code or an application can be I/O bound, CPU bound, or equally bound to both CPU and I/O.

• Generally speaking, PHP applications tend to be I/O bound - what slows them down is the I/O they are performing - connecting, reading and writing to databases, Caches, files, sockets, etc.

#What does CPU-bound PHP look like?

Due to the nature of most PHP applications, many PHP programmers are not familiar with CPU-bound code - their job is often to connect to some database, or maybe a cache, do some Works lightweight and outputs a html/json/xml response.

You might look around the code base and find a lot of code that has nothing to do with I/O, or even code that calls functions that are completely disconnected from I/O, and get confused. I seem to be implying that this is not the case. There is no need to make your application CPU bound, even though there may be more lines of code handling non-I/O than I/O.

PHP is actually quite fast, it is one of the fastest interpreted languages ​​in the world. There is no significant difference between the Zend VM calling a function that has nothing to do with I/O and making the same call in machine code.

There is obviously a difference, but the fact is that machine code has a calling convention, Zend VM has a calling convention, machine code has a prologue, Zend VM has a prolog: calling something in a Zend opcode c_level_function() Or machine code has no significant impact on the performance of the calling application - although it does seem to have a large impact on that call.

Note: The calling convention roughly refers to a series of instructions executed before entering another function, and the prologue refers to a series of instructions executed when entering another function: in In both cases, the calling convention pushes the parameters onto the stack and the prologue pops them off the stack.

What about loops, tail calls and X? I hear you ask: PHP is actually very smart, and with OPCache's optimizer component enabled, it's as if your code is magically transformed into the most efficient form you can write.

Now it is important to note that the JIT does not change the calling convention of Zend functions, rather than the convention established by the VM - Zend must be able to switch between JIT and VM mode at any time, so the decision was made to retain the convention established by the VM Calling convention. So when the JIT is running, those calls everywhere are not significantly sped up.

If you want to see what CPU bound PHP code looks like, take a look at the Zend/bench.php file... This is obviously a extreme CPU code example, but it It should let us know that the real highlight of JIT is in the field of mathematics.

Does PHP make the ultimate trade-off for faster math?

No, we did this to expand the scope of PHP, and it's pretty big.

In the opinion of this very biased PHP developer, if you are a web programmer in 2019 and you have not considered using PHP in your next project, then you are doing the wrong web thing.

Improving the ability to perform math faster in PHP, at first glance, seems to be a very narrow scope.

However, this actually opens the door to machine learning, 3D rendering, 2D (GUI) rendering, and data analysis (to name just a few).

Why can't we use it in PHP 7.4?

I just called JIT the "ultimate trade-off", and I think it is: it is arguably one of the most complex compiler strategies ever devised, perhaps the most complex. Introducing JIT is introducing considerable complexity.

If you asked Dmitry (the author of JIT) if he made PHP complex, he would say "No, I hate complexity" (this is a direct quote).

Ultimately, complexity is what we don't understand, and currently, there are very few internal developers (less than a few) who really understand JIT implementation.

PHP 7.4 is moving quickly, and merging into php7.4 will leave us with a version of PHP that fewer than a few people can debug, fix, or improve (in any practical sense). For those who voted against merging into PHP 7.4, this situation is unacceptable.

In the time between now and PHP 8, many of us will be trying to understand the JIT in our spare time:

We still have some features to implement and need to be reworked for PHP 8 To write tools, first we must understand JIT. We need this time and are extremely grateful that a majority of voters saw fit to give it to us.

Complexity is not a synonym for terrible:

Complexity can be beautiful, just like a nebula, JIT is that kind of complexity. In principle, you can fully understand something complex and only slightly reduce its apparent complexity. In other words, even if there were 20 internal developers as familiar with JIT as Dmitry, it wouldn't really change the complexity of JIT.

Will PHP development slow down?

There is no reason to think that is the case. We have enough time to say with confidence that by the time PHP 8 is generally available, enough of us will be familiar with JIT to at least fix bugs and move PHP forward The development aspect was able to function as it does today.

When trying to tie this to the point that JIT is inherently complex, consider that much of the time we spend introducing a new feature is actually spent discussing that feature. For most features, or even fixes, the code can take minutes or hours to write, and discussions to take weeks or months. In rare cases, the code for a feature may take hours or days to write, but in these rare cases, discussions always take longer.

For detailed analysis of PHP8, please refer to "PHP8 New Features: Detailed Graphical and Text Explanation of JIT" "How much improvement has the performance of PHP 8 seen? 》

This article is directly translated from php Chinese website: https://blog.krakjoe.ninja/2019/03/php-gr8.html

The above is the detailed content of Comprehensive interpretation of php8.0 version optimization and improvements. For more information, please follow other related articles on the PHP Chinese website!