In Response to JIT Compilation

Posted by santosj on April 26, 2007

I understand now or at least a little bit more why JIT compilation wouldn’t be useful.

Most pages will take less than a second to execute. Caching, where possible, will also be used to further decrease the time. Opcode Caches can also be used to keep PHP from compiling the page with each request further decreasing the time it takes. Taken all together most professional web sites wouldn’t benefit from JIT compilation. Given the delay from converting to machine code, it might actually take longer on the first run.

Would it be quicker to write a C extension for PHP than building a JIT compiler for the Zend Engine? Yes. In the discussion with Frameworks, the solution is to write the slow PHP code in C and write a function to be called in PHP, if available. My argument has always been that I shouldn’t have to. If it is just as fast using JIT compilation than I shouldn’t have to touch C code unless I’m binding some library in C or C++ to be used in PHP.

Yeah, 2x time decrease (Roadsend compiler statistics) doesn’t sound like much, but I would like to run algorithms that normally take 15 to 30 seconds in half the time. That to me is a huge deal. Now, these algorithms won’t run in front end pages, of course, but I would like to maintain the code in PHP. The possibility of the algorithm being poor is there, and so is that it would be better writing the code in C/C++.

Well, what I’m trying to get at, is that with edge cases JIT compilation would make a lot of sense. For those with normal pages, then I concede that you are correct.

Possibly Related Posts:


Writing Projects, ,

3 Comments.

  1. vincent.dupont May 10, 2007 at 3:14 pm

    hi,

    on most forums and meetings, I’ve heard that native (compiled) C functions are faster than PHP code.
    We also have had some demonstrations on how ‘easy’ it is to create new PHP extensions (PECL)

    On this basis, I guess a complete set of PHP code, as Zend Framework or PEAR classes should benefit from being converted into a PECL extension, no?

    If this is true, why not keep PHP code for layout only (views and/or templates), and do all customer application code into a PECL extension in C? (well, this will make me a web-designer instead of a PHP programmer…)

    What’s your opinion?

    Vincent

  2. Jacob Santos May 10, 2007 at 7:52 pm

    I know that would be what is desirable for PHP development, “Just Build an Extension.” I suppose for the same reason you don’t develop an complete application in Assembler, that it wouldn’t make sense to create an entire web application in C. While it is technically possible, allowing for time, I can develop faster in PHP with less bugs than I could in C. Just as someone can develop an application in C/C++ than they can in Assembler.

    The reason C code is faster is because it is compiled to Machine Code. What the JIT compiler does, is take PHP oplines and convert them to machine code also. If you can develop an application in PHP quicker with less bugs and run as fast as C, than what is the point of developing in C in the first place. Unless you need to hook the functionality into PHP first, than it would seem reasonable to me at least.

    The argument is that JIT is an edge case, meaning most of the time, pages will render less than half a second. Most pages should compiler and execute in less than a second. If it isn’t than you are doing to much in the page and need to do less on the front end and more on the backend.

    My case, is that I need to do math and cpu intensive work in loops and JIT would cut the time considerablely in the CRON Jobs. I don’t want the CRON jobs to go on for more than a minute, I don’t want the CRON jobs to go on for more than 10 seconds.

  3. André R. June 22, 2007 at 6:04 pm

    Larger applications like Facebook(even though they cache, cache and cache, and bye now probably have rewritten most heavy logic to C, they do need to touch php code sometimes) and others definitely would benefit from a JIT compiler, like the larger php cms systems around.

    Reusing the opcode optimizer codes around are probably a good idea.
    And since flexibility in php is an issue, it might help to restrict jit compilation to strict php 6 code? Falling back in some manner to running opcode when warnings are thrown. ( this will also be a good incentive for programmers to write proper code :) )