Deep Dive into PHP 8's JIT

https://thephp.website/en/issue/php-8-jit/

by nawarian • 6 years ago

100 63 6 years ago

untog• 6 years ago

Tiny nitpick: the article describes JavaScript as an interpreted language without JIT when most major JS engines do have JIT optimisation. It’s difficult to make this call about any language with more than one implementation.

But anyway, kudos to the PHP folks for yet another improvement. It’s been a long time since I used it but I’m continually impressed by how far it’s come. And it’s a useful test to how flexible a developer is willing to be to ask them to code some PHP, there are fewer and fewer reasons against it these days other than personal style preference.

viraptor2• 6 years ago

The whole idea of "language X is interpreted/compiled" is a simplification I wish people were more careful with.

Cpython is interpreted, pypy has JIT, mypyc is compiled. It's the implementation, or even implementation's specific runtime options that decide about things like that, not the language.

userbinator• 6 years ago

The statement would be far more accurate as "language X is [almost always/sometimes/often/commonly/etc.] interpreted/compiled". Unfortunately a lot of people seem to like speaking in absolutes.

C can be interpreted too: https://en.wikipedia.org/wiki/CINT

coldtea5• 6 years ago

Well, the idea being that CPython is 99% of what people use, and the other are nearly irrelevant projects...

agumonkey• 6 years ago

PHP's story really is something to remember as to show no matter how low you start, in a fertile soil, you can grow long and far.

nawarian5• 6 years ago

I should probably add this kind of thing to the article then. It is nearly impossible to state "Language X is compiled/interpreted/jitted".

I didn't explicitly say that JS doesn't come with JIT, because I'd be putting Node.JS and every browser engine in the same bag. I simply can't be sure about all of them.

I'll add very soon this caveat that the dialect (js, php, python) doesn't really matter and make it clear that I'm talking about engines, possibly directly point to them.

I hope you understand, though, that I wanted to make JIT as a concept understandable. The language comparisons are secondary.

Thanks a lot for your feedback!

google234123• 6 years ago

Didn't Facebook also develop is JIT for their PHP? Or have they moved on frmo PHP?

tyingq2• 6 years ago

Hack/HHVM no longer has a goal to be PHP compatible, but it looks pretty much the same. It does have a JIT: https://hhvm.com/blog/2027/faster-and-cheaper-the-evolution-...

ksec2• 6 years ago

Do we know anyone outside of Facebook uses Hack/HHVM in production?

freelancercv• 6 years ago

"PHP as fast as C" - People who are in php language development may die laughing reading this statement.

Truth can be harsh, but people sometime overvalue to such an extent is hard to understand.

chubot4• 6 years ago

What I've noticed is that JITs often can reach C speed in workloads like this:

    sum = 0
    for i in xrange(n):
      for j in xrange(i):
        sum += A[i][j]

And when they reach that milestone, some people call it "as fast as C".

Never mind that that's not what people actually write in Python or PHP. It's a synthetic benchmark, not a real workload.

The workloads in those languages are generally oriented around strings, hash tables, and function/method calls.

And the JITs don't seem to do nearly as good a job there. I tested PyPy on Oil [1] a few years ago, and it made it slower, not faster. And it used more memory. (Though PyPy is an amazing project in many respects.)

[1] https://www.oilshell.org

remram• 6 years ago

This is not what people write in Python or PHP, but this is what people write in C extensions for Python or PHP. Having your JIT be that fast allows you to forego those extensions and write the low-level hot loops in the same language, and that's a huge improvement.

You usually don't care how your matrix multiplication/regex matching/unicode normalization/JSON parsing is implemented, but people had to make those, and they are users of the language too.

Even though it might not change the bottom-line for your high-level app.

rovr138• 6 years ago

What I want to see a benchmark like this one, https://kinsta.com/blog/php-benchmarks/

I think a workload like this is more common in the PHP world. Not saying that others don’t exist, but handling routing, queries, cached content is very different from simply doing mathematical/memory intensive applications.

jashmatthews9• 6 years ago

This is sort of contradictory but at the same time as expected speed up on "realistic" code isn't as big it's also easier for JIT compiling VMs to optimize high level abstractions than something like C.

JIT compilers have different optimizations available like:

Fast inlined heap allocation (normally much faster than malloc/free). V8 even does allocation combining

Transparent ropes for strings

High level alias analysis for hash tables and objects

Inlining dynamic dispatched functions and dynamically loaded functions

bouncycastle• 6 years ago

Well, most of php is just calling C functions. So if they add a JIT to that, it could be a believable claim. Why not?

jashmatthews9• 6 years ago

No implementation of a language as dynamic as something like PHP has ever managed it in practice. TruffleRuby uses Java for particularly performance sensitive parts. JSC relies on calling C++ or "intrinsics" which are hand-written IR snippets of code to JIT.

pjmlp3• 6 years ago

The irony of "as fast as C" comparison, is that anyone doing 8 and 16 bit coding on home micros remembers how lousy C compilers used to be (like most other high level languages), to the point that any junior Assembly developer could easily write much better code.

Any language can eventually reach that point with enough money, time, and in C's case doing 200+ optimizations with unexpected results.

coldtea5• 6 years ago

Well, most of PHP is calling into C functions (all the standard libs), and as for the rest a JIT can absolutely be as fast (or faster, due to micro-optimizations, profiling, knowledge of non-aliasing, etc) than C.

So there's nothing really funny about it....

CountHackulus• 6 years ago

I definitely misread this title as the P8 JIT that IBM was working on for a while.

ksec2• 6 years ago

May be everyone on HN has Adblock/ PiHole on.

But this Blog, a single page has 5 Google Ads in it. I dont mind one or two, top and bottom. But 5, right in the middle of every section.

iKevinShah• 6 years ago

I am out of advertising for a long time so I might not be aware but back in 2009s-10s, Adsense had a limit for 3 ads per page.

Is that not a thing anymore? Genuinely curious

Edit: Yes, some initial searches reveal that it's not a thing anymore.

geek_at• 6 years ago

Blogs like these are the main reason to use ad blocks. And from their perspective: everyone using adblocks is the reason they need 5 ads on the site

nawarian5• 6 years ago

Hey man, author here. Thanks for the feedback. I recently added adsense there and I'm testing with the amount of ads in the page. Currently I'm letting AdSense decide how many ads it should place and where.

But if you believe the amount is so harmful for your experience, don't worry. I'll be more than glad to reduce this amount.

Cheers!

rurban• 6 years ago

Not a deep dive, a rather very shallow dive.

Deep dives were handled before: https://wiki.php.net/rfc/jit And its discussion https://externals.io/message/103903

pjmlp3• 6 years ago

Unless we are speaking about Java before Java 1.2, it is definitely not interpreted, there are plenty of JIT and AOT implementations without any kind of interpretation step.

Since 25 years, time to learn that implementations and languages are not the same.

ptx• 6 years ago

Good point, but are there really "plenty" of Java implementations that lack an interpreter? There's Graal and Excelsior JET for AOT. Any others? Which implementations do JIT without any interpretation?

nawarian5• 6 years ago

I might be wrong here, as I'm not so close to Java development. But a language implementing JIT, at least to me, is interpreted.

Could you please point an implementation detail where a JIT-capable engine doesn't include interpretation in its runtime?

In every case, thanks a lot for your feedback!

jashmatthews9• 6 years ago

V8 had only baseline compilation until much later https://v8.dev/blog/ignition-interpreter

It's not super exotic to do this.

pjmlp3• 6 years ago

Well, from CS compiler theory point of view it is not.

For example in .NET, MSIL goes directly into a pipeline that produces native. You can easily validate that RyuJIT has no interpretation.

Or for example, watchOS applications packaged with bitcode, get JIT compiled at installation time.

fetbaffe• 6 years ago

There is a small error in the text. When describing the opcache.jit setting it shows examples where the third flag is set to 5, eg 1255, but the table of possible values for the third flag, 'T - JIT trigger', goes from 0 to 4.

nawarian5• 6 years ago

Thanks a lot! I blindly fetched this from the reference mentioned there. I'll update this as soon as I have time (probably during this week) and also let the author of the referenced post know about it.

jashmatthews9• 6 years ago

This article is actually now quite out of date as PHP has switched to a tracing JIT which appears to be heavily based on LuaJIT.

https://github.com/php/php-src/pull/5874

https://github.com/php/php-src/commit/4bf2d09edeb14467ba7955...

pansa22• 6 years ago

Any ideas why they’ve moved from a method-based JIT to tracing?

AFAIK tracing JITs are generally inferior to method-based ones, which is why none of the major JavaScript engines use tracing. Their only advantage seems to be (relative) simplicity, which is essential for the lightweight LuaJIT but not for PHP.

MaxBarraclough• 6 years ago

That doesn't sound right. How would a trace-based JIT be easier to implement? There was a research project which made HotSpot into a trace-based JIT. It reported both faster compilation times, and superior quality of generated code.

(I don't know if the HotSpot folks ever considered adopting the changes.)

http://www.ssw.jku.at/Research/Papers/Haeubl11/

jashmatthews9• 6 years ago

The method JIT they built before failed to provide any improvements on a real world app. Building a JIT compiler for a dynamic language that's actually faster than a fast interpreter is quite tricky!

There's a lot more to it than just compiling what the interpreter does. CRuby's JIT has a different approach using C templating rather than Dynasm and templating/context threading but it also fails to improve performance much for the same reasons.

Tracing JITs are really good at optimizing a small scope. What a tracing JIT does with recording a single path of linear control flow the method JITs also try to do with branch profiling and pruning.

It works really well for a particular style of Lua. For a language like Ruby or PHP it's a lot harder to make a tracing JIT work well on existing code.

The main problem is tail duplication causes the number of traces to increase exponentially with each branch. You have to either have trace heuristics which keep the traces very short or go half way to a method JIT and build a control flow graph.

I got to the tail explosion problem building a tracing JIT for CRuby and gave up.

nawarian5• 6 years ago

Thank you all for sharing your comments and thoughts. I'm unfortunately out of time today, but I'll try to address your comments asap :)

Cheers!

Deep Dive into PHP 8's JIT

Related Stories