JIT: Hibernate JIT to disk for use with pre-built containers

[iamacarpet]

Description

Idea:

Support hibernating the JIT cache to disk.

Why?:

When building containers that contain both the PHP runtime and application code (that isn’t going to change once built into the container), a lot of CPU cycles are wasted re-warming the opcache/JIT every time a version of the container starts, even though the code will always remain the same.

In a large distributed container based platform like Lambda, App Runner, App Engine or Cloud Run, there are significant performance gains & cost savings to be realised by being able to pre-warm the JIT at container build time, then load it from disk at container startup.

How?:

Would it be possible to dump the JIT/opcache memory to disk?

While also having the option to load that dump at startup?

It could be controlled via ini options, which could be set on the PHP CLI as arguments when dumping the memory at build time.

[iluuu1994]

Hi @iamacarpet. Opcache can be persisted to disk, it works in the way you describe. See:

https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.file-cache

That's not currently an option for jitted code though. I'll defer to @dstogov on whether that is possible. Serializing assembly would be platform specific, so potentially something that would need to be added to dstogov/ir.

[iamacarpet]

Thanks @iluuu1994 ,

I was just reading that, after spotting it after already opening the issue :).

Thanks so much for confirming it doesn’t dump the JIT’d code - that wasn’t clear anywhere.

While we wait for @dstogov , is there any benefit from using this for opcache, if PHP will then use JIT at runtime? i.e. is it layered and opcache is the first layer, then the JIT runs - or does one supersede the other?

[iluuu1994]

is there any benefit from using this for opcache, if PHP will then use JIT at runtime?

Yes. Before opcodes can be jitted, they first need to be built by compiling the source files. So you're at least speeding up the first half.

While we wait for dshafik

Think you linked the wrong person there.

[iamacarpet]

Think you linked the wrong person there.

Oh nuts! That you for spotting that! Edited :).

Yes. Before opcodes can be jitted, they first need to be built by compiling the source files. So you're at least speeding up the first half.

Perfect, I’ll give it a try and see if we can measure an increase in performance - if we can, hopefully bringing the JIT into the equation is something we can do in a future release.

Thanks for the help so far!

[cmb69]

For what it's worth, a couple of years ago I've measure file_cache vs no OPcache on Windows/NTFS, and there was no performance difference. That might be different for other platforms/filesystems, though.

Anyhow, I think you're actually looking for ahead-of-time compilation.

[iluuu1994]

@cmb69 What did you measure? Cold start? I think it's safe to say PHP will never have ahead-of-time compilation.

[kocoten1992]

I think facebook call it Jump-Start.

[cmb69]

What did you measure?

That was a full benchmark against a couple of downstream projects, similar to Máté's benchmark. There had been a warm-up phase upfront. Main problem on Windows is reading (small) files – super slow. WinCache might have sped that up, but never tried it.

[iluuu1994]

Does that mean files were already read from file cache into shm? Or did you disable shm and compare the performance of file cache w/o shm vs. no cache at all?

[cmb69]

Or did you disable shm and compare the performance of file cache w/o shm vs. no cache at all?

That. (opcache.file_cache_only=1)

[iluuu1994]

Thank you! While I'm surprised that's not faster on Windows, it might be on Linux. But I haven't measured it myself.

[dstogov]

iamacarpet we don't plan to serialize JIT code to disc.

cmb69 I think, file_cache_only vs no-opcache should make speed improvement on Windows s well. It may be insignificant for a single request, but for a number of requests to some fat Symfony app running on FastCGI PHP server I would expect good results.

[cmb69]

The general test environment consisted of 4 VMs:

• a database server (MySQL) which had already prepared demo databases
• a Webserver (IIS) with a couple of demo applications
• 2 clients

The clients used wcat to perform the tests. That included a warmup phase (in seconds) and a actual measurement phase (in seconds). That was typically run to test performance of RC1 vs latest GA, and GA vs RC1. The results were than published, e.g. https://windows.php.net/downloads/snaps/ostc/pftt/perf/7.4.12-7.4.13RC1.html. As you can see, SHM OPcache made a serious perf improvement (WP got almost 10 times as fast). I don't have the results of that single file_cache_test I've done any longer (don't even know which PHP version that used; likely some PHP 7.4.x), but there had been no notable performance differences (at least not outside of the usual outliers/instability).

I still think the problem are the slow file system operations on Windows/NTFS (which eat up the performance benefits of pre-compilation). Even after OPcache became generally available with PHP 5.5, WinCache still offered a file cache and a resolve file path cache (both SHM) to improve this. Unfortunately, that extension has been abandoned a couple of years ago. Oh, apparently it had been revived. I think I'll have a closer look.

we don't plan to serialize JIT code to disc

Okay, then this ticket can be closed.