1. 13
  1.  

  2. 10

    I don’t really understand, I know they are explaining the reasoning, but to me it’s a bit strange to dedicate such large amount of volunteer/engineering resources to improve the math/3d rendering/machine learning capabilities of a language like PHP.

    It looks to me like a completely unnecessary feature for 99% of the usage that PHP sees, that will complicate a piece of software that is internet-facing. It looks like a very wrong tradeoff to me, but what do I know.

    1. 1

      If Facebook had made AOT compiler for PHP (with C++ as intermediate representation!), then moved from AOT to JIT, then there’s might be demand for faster PHP code execution. Not sure, though, that this may help other applications, as Facebook has very specific needs.

    2. 5

      ’In the general case, applications written in PHP are I/O bound.. ’ .. really? my Wordpress is incredibly slow because of waiting for IO?

      ‘where the JIT really shines is in the area of mathematics’.. because that’s where most people needed optimisation in PHP?

      1. 3

        I haven’t benchmarked Wordpress, so my answer would only be anecdotal evidence: Most of the stuff I write in PHP (typical web applications) do indeed use a good amount of time waiting for the database. If I spot a bottleneck, it’s often caused by a bad query to the database.

        I agree that today’s most typical use cases for PHP will not benefit much from JIT. The author does however mention that this will allow for more interesting use cases in the future.

      2. 1

        PHP requires that application is initialized from scratch for each request, so this can really decrease response latency. But this is also a problem for JIT: how generated code and tracing information is preserved between requests? Usually it starts from blank state, source files are re-read for each request, each function and class definitions re-create functions and classes. How will it change with adding JIT?

        1. 2

          source files are re-read for each request

          With an opcode cache like APC, you try to only re-read and re-parse the source files when they change (when their mtimes change, I presume).

          IME, if you turn on APC’s opcode cache, turn off debug mode and change absolutely nothing else, WordPress on running on Apache/mod_php used to become perceptibly quicker. (Note I haven’t checked this in at least 4 years.)

          1. 1

            Apache/mod_php is dog slow. I hope nobody is using this anymore… Better use Apache MPM event + PHP-FPM, that is quite acceptable! :)

            1. 1

              MPM event wasn’t officially considered stable yet back when I did this. FPM wasn’t in the distro repos ;). The Wordpress site was not the slow part of the whole product anyway. We had a much slower website alongside it, which the WP site was effectively a giant landing page for. Also I had Varnish in front of the WP site so it went fine.

            2. 1

              As I remember, using these caches (there was plenty of them) always wasn’t easy and standardized, and now documentation for APC says:

              This extension is considered unmaintained and dead. However, the source code for this extension is still available within PECL GIT here: https://git.php.net/?p=pecl/caching/apc.git.

              Alternatives to this extension are OPcache, APCu, Windows Cache for PHP and the Session Upload Progress API.

              Adding JIT will probably require intermediate code/native code cache that really works out of the box. Working bytecode cache also was the main selling point of commercial Zend Platform/Zend Accelerator (renamed several times), and if mainline PHP will have cache out of the box, it may reduce its sales.

              1. 1

                I remember APC only taking about an hour or so to set up, most of which was reading docs.

                Fwiw this was somewhere around 4 to 6 years ago on a one off job. Never touched it since.

            3. 1

              JIT will increase the bootstrap time for the first request so this may reduce response latency. May as in, it will also speed up long-running processes. As the author says you’ll probably see no performance gains from JIT for web applications.

              1. 1

                But PHP’s current execution model does not have long-running processes. Only interpreter/compiler may be preserved as long-running process, but application starts and terminates with each request. Almost like in CGI.