PHP 8.0 JIT Is Offering Very Compelling Performance Ahead Of Its Alpha

[ddriver]

So why isn't everybody writing things in hand tuned assembler?

For the same reason nobody makes things out of atoms. The perf difference between assembly and a proper ahead of time compiled language is negligible. The perf difference between a compiled language and php is about 30x.

Yes, it probably won't matter if you are running a single crummy website on an off the shelf server, but if you are running a large scale operation, you certainly do not want to be 30 times worse than the optimal, because that directly translates to a 30x greater infrastructure cost, if not even higher.

But try and see the world beyond the tip of your nose. On a global scale, all web services would need 30x higher maintenance, and would have a 30x higher environmental footprint. In the end, all those costs apply to the end user, one way or another.

And lastly, high performance language do not necessarily need to be slower to develop in. Throwing extra money and hardware at inefficient code... that's what the money making industry likes, and that is also the reason the standards for code quality are abysmally low. But I am sure you never felt like software runs like a sloth or is needlessly bloated, right? Just like you never felt bad for being strong-armed into making additional purchases that could have been avoided. Yes, one does have to balance priorities, but in the end you do have to try to make the best of what you got, throwing money at problems is never a good solution.

[boxie]

For the same reason nobody makes things out of atoms. The perf difference between assembly and a proper ahead of time compiled language is negligible. The perf difference between a compiled language and php is about 30x.

Yes, it probably won't matter if you are running a single crummy website on an off the shelf server, but if you are running a large scale operation, you certainly do not want to be 30 times worse than the optimal, because that directly translates to a 30x greater infrastructure cost, if not even higher.

But try and see the world beyond the tip of your nose. On a global scale, all web services would need 30x higher maintenance, and would have a 30x higher environmental footprint. In the end, all those costs apply to the end user, one way or another.

And lastly, high performance language do not necessarily need to be slower to develop in. Throwing extra money and hardware at inefficient code... that's what the money making industry likes, and that is also the reason the standards for code quality are abysmally low. But I am sure you never felt like software runs like a sloth or is needlessly bloated, right? Just like you never felt bad for being strong-armed into making additional purchases that could have been avoided. Yes, one does have to balance priorities, but in the end you do have to try to make the best of what you got, throwing money at problems is never a good solution.

So there is a point on the optimisation curve (effort vs reward) that you are happy to define as "optimal" (building stuff out of atoms is a step too far, as well as hand written assembler). Is writing low level library code to use SIMD/AVX instructions across multiple platforms past the point of optimal for you? How much of a framework are you willing to tolerate?

Something like Golang makes the dev experience rather easy (until you start needing to peak under the covers) but comes with a very large binary size and possibly an rather large list of libraries? This is compiled and speedy - but not as fast or small as writing the application in pure C without a framework.

But then if you are not using a framework you have other overheads including maintenance and bug fixes that you have to do yourself.

Then with compiled languages, the development overhead can be painful too - with PHP you write, alt tab and refresh and the result is there, sub 1 second. When using a compiled language (depending on hacks) you have to compile the project and then run it - giving that a performance penalty, leading to a bad developer expiernce


----

As for the 30x slower thing, I believe it is wrong, I would accept 2-10x slower, depending on which web framework used. But again, the slower frameworks have more features that make developing and maintaining easier / faster / less error prone.

Lastly, throwing $ at hardware is a valid solution - sure it does cost more in hardware costs but as part of a total cost it justified.


---

In summary, how fast a program handles performance is not the only thing that matters and there are massive costs that ramp up quickly when going for performance.

Where you choose to buy in on the optimisation curve is a function of the projects goals. 99% of projects are not "Web/Google/Facebook/Microsoft Scale" and spending $ on engineering a super fast solution does not always meet the requirements of the project.

As developers we should try and achieve good performance for the project and there are oh so many tools in our toolbox before "Just rewrite it in compiled language X" becomes a thing

[GreenReaper]

This could be great if the execution of PHP is the blocker The reality is that this will be true in some cases, but perhaps not all that many.

It'd be nice to think that it'll speed up some of the slower frameworks out there. However, we must temper expectations for big wins in real-life use-cases, as where performance really matters, such as image processing, it often mattered enough to use a module or some other compiled tool for it already

This seems to be true for JIT in general. PostgreSQL added JIT relatively recently, and in some cases it can be useful. But often they are non-optimized cases to start with. If you have a well-indexed query, it's quite likely that the JIT pass will just slow things down slightly. And if you have a transactional system of such queries, turning it off can be a good idea.

[royce]

You can write APIs in PHP using certain frameworks with response times in the sub 5ms range, depending on what it does. That's usually way more than enough for 99% of the use cases for PHP, and a drop in the bucket of network latency between clients and servers that aren't local to each other. If you need faster, there are better languages for the job.

[IntrusionCM]

Optimal performance is the least amount of computational resources possible to produce the desired result. You are welcome.

Well... Let me make it a bit more obvious: From a theoretical point, you can definitely strive to achieve this. In reality, this is non solvable.

I chose the stack overflow comparison for a reason: When performance really matters, you'll have to take a very close look at all variables.

And that's what's missing on stackoverflow.... I seldom see a stackoverflow entry where eg the build environment / target environment, throughput (QPS / RPS .... whatever) is defined.

It's... abstract. In most cases following blindly stackoverflow leads to eg the situation that someone optimized for an server with an interconnect / fibre channel, > 10 K connections per minute, > 256 GB of RAM, ... while in reality they have only an 4G shared virtual root server.

Choose the right tool - for the right job. And when optimizing - take a look at what you have before starting pointless optimization or over optimize.

I programmed in Java / C / C++ / C# / PHP / Python... Every language has it's good and it's bad sides.

And I learned in every specific language that there are specific pitfalls that might even correlate to a specific OS / hardware / environment.

You cannot make "one thing go everywhere fast"... But you can make it run "everywhere as fast as possible with compromises".

(e.g. JAVA has finally with JDK 14 an NUMA aware GC... G1GC... and NUMA is definitely not a new thing)

I suppose google engineers are also all a bunch of dumb screeching monkeys for striving to develop data structures and algorithms, aimed at squeezing every last percent of cpu time and ram utilization from their c++ code, little do they know they can just switch to jitted php and forget their petty concerns of optimal performance.

Quite the opposite. Google didn't focus alone on C++. Never did, never will do.
Google did the right thing concerning optimization: They looked at all the variables and started inventing specific solutions for specific problems.

Especially GO is a good example of this: https://talks.golang.org/2012/splash.article

[Jabberwocky]

And in another 15 years they will go for an ahead of time compiler... Even at 4x improvement, jitted php is nowhere near optimal perf.

I agree with your statement, but less than 1% of programmers can produce optimal performing code given the time frames they have. This will give those unfortunate enough to have PHP code base an advantage. That said, there certainly other languages (&frameworks) that allow you to write "more optimal" code with less experience, in less time, with less bugs, and with more readable code.

I've worked for financial institutions that copy paste from github without reading code and work too fast to refactor, while another random mobile app company spent orders of magnitude more time on code quality, reviews and testing. Both companies had very passionate motivated employees, the biggest difference was (micro) management/KPIs. I've heard that it's worse at government agencies, but I don't have internal first hand experience. What's the takeaway from this verbose observation? The standards you set and principles that you follow are important also how well you understand that principles. You expect financial and government to have good standards due to the amount of resources available, but (up to a certain degree) throwing money at the problem unfortunately does not necessarily solve it.

When senior executives of an organization do not properly arm themselves with adequate depth of understanding to terms such as “Lean” and “Agile,” they end up not only lumping them together, they urge the organization to then “fail fast, fail often.” If we're "Lean" we must "fail fast, fail often." Or, if we're "Agile" we must "fail fast, fail often."

Either way, it then defeats their real intention. The unintended consequence is employee chaos.

-- https://www.forbes.com/sites/danpont...st-fail-often/

The only software that I have come across that was designed well while using PHP (IMO) was MediaWiki and it's really old. I doubt that PHP would be the language of choice had it been redesigned today. MediaWiki is also extremely easy to cache, so most performance arguments are irrelevant.

I also agree with GreenReaper about frameworks, it's certainly not something to ignore when measuring performance in a "real world" scenario.

These ideas are relatively old (~8 years), but still very valid regarding web: https://cirw.in/blog/time-to-move-on and https://12factor.net/ (docker has made this much easier).

[benjiro]

For the same reason nobody makes things out of atoms. The perf difference between assembly and a proper ahead of time compiled language is negligible. The perf difference between a compiled language and php is about 30x.

Its painful to see this type of misinformation and frankly nonsense.

* PHP by default serves requests by checking cache, checks files, loading all the classes, makes connections, runs the requests, returns the result and then drops all the work it did.
* Repeat all the steps above!!!!

When you compare a language like Go, those fancy benchmarks looks great ( aka 10X ) performance difference for micro-services etc. But this is literally comparing apples vs aliens.

The main reason Go as a compile language is "faster", is because it does this:

* Go: You start the executable, it starts it http server, makes connections, gets request, return result, gets request, return result, gets request, return result, ...

Notice how it does not reload everything? Because unlike default PHP, it does not do fire-and-forget.

If you take PHP and install Swoole or Workerman or whatever solution, it does this:

* PHP: You start the executable, it starts it http server, makes connections, gets request, return result, gets request, return result, gets request, return result, ...

All of a sudden, PHP is the same speed as Go, pushing out 10 times as many requests then before.

Where Go has a advantage, is if the code is highly mathematical. A spot that PHP 8.0 is heavily reducing with the JIT. While it will never reach Go levels on pure mathematical code ( PHP loses speed because of its user friendly features and hated features by compiler guys ) but for Web content and Micro-Services, PHP can easily competed these days with Go and other languages. You just need to know what to use.

Do not belief me?

https://www.techempower.com/benchmar...l=zg21hb-f&a=2

Notice how Go and PHP results are darn close and at worst 3x ( echo world ). Native PHP results are bad because of the issues mentioned above.

Only people with out of data information, do do not know how PHP works and make senseless comparisons with compile language, despite both by default using a totally different approach to serving data. Its like all those fools who keep spewing "PHP Sucks" with examples from the PHP 5.X days, that are long time invalid...

There has been some pressure on the PHP developers to finally upgrade the build in HTTP server to allow this type of "Go like" behavior by default.