Hi Brent, > I'm wondering about the state of PHP's JIT these days. I understand that > Dmitry is still working on his standalone JIT IR framework [1] that's being > used by PHP, and that Arnaud is maintaining it from the Foundation/PHP side? > In my own benchmarks, done in PHP 8.0 and PHP 8.4; I cannot seem to get any > meaningful performance gain from the JIT in web applications or in tools like > PHPStan. [2][3][4]
To be fair, the first web benchmark in [2] shows a 9% improvement with the tracing JIT enabled. But the benchmark seems very unstable: The second run gives a widely different number for the baseline, but I would expect that number to be very close to the first run. However I confirm that the JIT provides no improvements on PHPStan at all currently. > The question I'm left with is whether the JIT is worth the hassle? Assuming > the JIT's existence impacts the complexity of internal development, I wonder > if it wouldn't be better to deprecate it in a future PHP version? To be > clear, I'm assuming the JIT impacts internal development — maybe that's > wrong? Perhaps I'm missing a real-life use case that benefits significantly > from the JIT as well? If performance is an important feature, then we need a JIT in the long term. Other VMs have shown that JITs can have spectacular performances in practice. The reason our JIT is not bringing much benefits yet is that it's still in a very early stage, especially on the frontend side. The alternative would be to rely entirely on interpreter improvements, but it's already state of the art, and we are way past the point of diminishing returns: it's unlikely that we can make as much improvements with the interpreter alone than with a JIT. Also it's likely that work on the JIT has a better cost/benefit ratio at this point. Regarding the impact of the JIT on internal development, I believe that it's relatively low: * The JIT is known to be a bit unstable yet, and there are occasional JIT bug reports, but these affect only the JIT and deployments with JIT enabled * Changes to the VM are likely to require changes to the JIT as well, but this is not the majority of the work * Language changes, such as those proposed in RFCs, often require JIT changes as well. But RFCs are not required to implement JIT changes before voting, so this only adds overhead on accepted RFCs. This represents a very small fraction of the work required on an RFC. * Other changes don't usually need to care about the JIT Best Regards, Arnaud
