On Mon, Feb 4, 2019 at 3:44 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov <dmi...@zend.com> wrote: > >> >> >> On 2/1/19 4:23 PM, Dmitry Stogov wrote: >> > >> > >> > On 2/1/19 3:09 PM, Nikita Popov wrote: >> >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmi...@zend.com >> >> <mailto:dmi...@zend.com>> wrote: >> >> >> >> Hi Internals, >> >> >> >> >> >> I'm glad to finally propose including JIT into PHP. >> >> >> >> >> >> https://wiki.php.net/rfc/jit >> >> >> >> >> >> In the current state it may be included both into PHP-8, where we >> >> are going to continue active improvement, and into PHP-7.4, as an >> >> experimental feature. >> >> >> >> >> >> Thanks. Dmitry. >> >> >> >> >> >> I would like to check if the JIT provides an improvement for >> PHP-Parser. >> >> Unfortunately I'm getting a segfault when running the tests. Should be >> >> reproducible with >> >> >> >> git clone g...@github.com:nikic/PHP-Parser.git >> >> cd PHP-Parser >> >> composer install >> >> php-jit vendor/bin/phpunit >> >> >> >> I tried to debug this. Unfortunately my gdb doesn't seem to work with >> >> JIT: It hangs when the script starts running, on line >> Zend/zend_gdb.c:84 >> >> in zend_gdb_register_code. I don't know if that's a bug or I need to do >> >> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3) >> >> 8.1.0.20180409-git). >> > >> > GDB takes enormous time registering too many JIT-ed functions... >> > It should be possible to catch the name of problematic functions and the >> > JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but >> > most probably, only on next week. >> >> I fixed the problem caused JIT to fail on PHP-Parser tests (it was >> related to changes introduced by typed properties patch). >> >> I'm also going to disable automatic JIT code registration in GDB. >> >> Thanks. Dmitry. >> > > Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x > speedup with default JIT configuration. That's promising :) > Unfortunately I made a mistake here and benchmarked against vanilla PHP without opcache (and more importantly the optimizer in opcache). Here are the correct results (for repeated parsing of a large file): PHP: 3.7s PHP+optimizer: 3.2s PHP+optimizer+JIT: 2.4s So the speedup is ~1.3x rather than ~1.5x, which is still good. I also ran the hello-world.php example of https://github.com/amphp/http-server against wrk -c100 -d30 -t4 and got the following results: PHP: 9950 rps PHP+optimizer: 10750 rps PHP+optimizer+JIT: 11350 rps So in this case the improvement is about 5%. (This is the HTTP 1.1 server, HTTP 2 would also be interesting to try, but needs some more setup.) Nikita
