Trying out the JIT in PHP 8.4

[@phpannotated]

I made a followup with some more benchmarks to address some of the questions in the comments: kzbin.info/www/bejne/a4PIpH6odtOjeNk 🚀

[@DigitalLobstershow]

Am excited for php8.4 🎉

[@batfeats]

I've personally seen much better performance from JIT in my CLI benchmarks, but the opcache needs to primed before taking measurements.

[@bedramtamang1439]

Awesome experiment

[@awabomer]

Hi, beautiful content. I would like to suggest you add time stamps to be able to watch the segments for people with less patience for long videos, thanks

[@phpannotated]

Didn't I do that? Or do you mean more? Thanks!

[@barneylaurance1865]

I think the start of "What is JIT?" as slightly wrong and misleading. Saying that PHP is normally interpreted whereas Java is compiled, but PHP can be interpreted with the JIT makes it sounds like there couldn't be JIT's in Java. But Java also has JIT compilers. Both PHP and Java are in fact compiled to byte code. The PHP compiler is just better at hiding than the java one (by being fast, being bundled with the engine and running on demand, and only saving the output in a cache and running it, not saving it into any file intended for saving permanently) The JIT in both PHP and Java is not for compiling from source code - it's for compiling from byte code to machine code.

[@mehdi-vl5nn]

yes ,Java and C# both utilize JIT (Just-In-Time) compilation. They compile to IL (Intermediate Language), which is then interpreted initially, and later the JIT optimization occurs. Similarly, in JavaScript, at least in V8, a comparable process takes place.

[@StrangerWolf-x6z]

Thx for the investigations and test. Actually looks like there are no reasons to use JIT at the moment for boost performance.

[@phpannotated]

Well, let's see if anyone in the comments tells me whether I messed something up before drawing definitive conclusions though!

[@martinh4982]

I have no idea how these things work, but a couple of thoughts spring to mind: 1) I imagine the JIT has a load of instrumentation code in order to recognise when, if, and how something needs to be optimised. That won't be cost free and if nothing can be optimised it could lead to degraded performance. 2) It might be worth trying some highly CPU intensive pure PHP code to see if you get any improvement from the JIT.

[@phpannotated]

True! I did the highly CPU intensive part in my previous benchmark by generating a mandlebrot; there it has a huge effect. Unfortunately, a mandlebrot isn't really useful in real life apps :p

[@DanielOpitz]

I have not tested it, but I think JIT could improve performance for long-running process with intensive operations. So maybe the PHP shared nothing architecture is not the right use-case.

[@phpannotated]

Possibly!

[@pierrejoye]

I am not sure "very very" small in the right outcome reading one of the bench, that's almost 9%~. At the stage where php is, this is a pretty good improvement. And yes, it won't help for apps doing mostly IOs anyway, but that's not where jit will do good :)

[@apostnikov]

I bet it has no effect because you're using built-in server which only populates buffer but does not actually use it

[@phpannotated]

That _might_ be the case, although the CLI experiment should in theory work

[@mtdr3]

I believe the slowest thing in phpstan is it's file operations. I think that is not a good benchmark.

[@phpannotated]

That is a good point! Although I do remember the PHP 8.0 discussions where static analysers were mentioned as one of the possible areas the JIT would help.

[@vrontogatos]

JIT couple of years? Maybe you mean decades?

[@feelingfun5149]

Maybe testing JIT with only 50 requests is not a good idea?

[@phpannotated]

Why not? If it doesn't affect 50 request, it shouldn't affect 1000 either. The JIT could potentially optimise small parts of your code within a request, not requests as a whole

[@373323]

it seems to produce any significant difference , might as well not be part of the code base , it's a useless feature as it stands today