Benchmarking the JIT… again.

I my previous video ( • Trying out the JIT in ... ) I checked out new JIT features in PHP 8.4. I also did some benchmarks, but were they actually accurate?

[@StrangerWolf-x6z]

Very grateful. It's interesting to follow you and observe the experiments. I wish you to get well as soon as possible

[@havokgames8297]

My feeling is that its okay for the first version of the JIT to not make much difference. It should have reduced the maintenance overhead a lot for the PHP team, and opened up the ability to easier optimise it in the future. Once they prove the performance hasn't degraded, and that there aren't many bugs, then they could easier add new optimisations. JIT's can get really really advanced such as is seem in .NET and Java. I doubt PHP will get all the way there, but I expect to see more performance unlocked in 8.4 and 8.5 etc.

[@DanielOpitz]

I think JIT adds another layer of complexity. The performance improvements are (in most cases) within a range of measurement tolerance. Removing JIT could bring fewer potential for bugs and it might also simplify the life of the "PHP-SRC" developers to bring new features to the language.

[@giorgio5127]

php should have an official asynchronous built in server for production in a way that the jit could be used or share an optimized version of code between processes in some way

[@apostnikov]

Curious about RPS for PHP 8,4) thank you sharing update!

[@tizianschmidlin5411]

I'm not sure you read ab correctly, but as far as I'm concerned, 7.36 reqs/sec is way more than 1.74 reqs/sec, almost by a factor 5. So yeah, it makes a difference I'd say.

[@phpannotated]

Yeah more RPS is better. How should I read ab differently then?

[@ddruganov]

You should try run tests for popular frameworks They have an absolute buttload of initialization code that runs on every request so that might be something hugely optimized by the jit

[@phpannotated]

Good idea!