Forgot your password?
typodupeerror
Facebook PHP Programming

Facebook Releases JIT PHP Compiler 244

Posted by Unknown Lamer
from the history-repeats-itself dept.
angry tapir writes, quoting a Techworld article: "In its continuing endeavor to serve its 800 million users as quickly as possible, Facebook is once again revamping the way it handles its PHP-based Web pages. Facebook has posted ... its HipHop Virtual Machine (HHVM), which the company's engineers call a just-in-time PHP compiler. According to Facebook, this PHP execution engine is 60 percent faster than its current PHP interpreter and uses 90 percent less memory." Facebook has a weblog post with a more technical description.
This discussion has been archived. No new comments can be posted.

Facebook Releases JIT PHP Compiler

Comments Filter:
  • by PCM2 (4486) on Monday December 12, 2011 @08:46PM (#38350378) Homepage

    I'd like to launch this discussion by making a snide remark about PHP.

    • by Roachie (2180772)

      Yea, perhaps Facebook can now develop a tool for REAL programmers!

    • by Taco Cowboy (5327) on Monday December 12, 2011 @08:52PM (#38350432) Journal

      Is FB's JIT PHP open sourced?

      • by PCM2 (4486) on Monday December 12, 2011 @09:00PM (#38350496) Homepage

        Is FB's JIT PHP open sourced?

        It appears to be licensed under a combination of the PHP license and the Zend license. Both are BSD-like, but the Zend license has a clause that requires you to advertise for Zend if you advertise for a product built with the Zend Engine, which I don't much care for.

        • Hey, say what you want about fb, this news is a net Good Thing(tm). Its not bad that they add to the community and add something useful. And a JIT for php is a good thing.
          • A good thing for the "community" would be if the library was cleaned up. Speeding up a trainwreck only makes the end result that much more catastrophic.

      • by Anonymous Coward on Monday December 12, 2011 @09:01PM (#38350498)

        If it's not, back to Xcache or APC.

        Their "10 times figure" is absolutely correct though, in both Xcache and APC, the compiled binaries to take up 10 times as much space on disk and/or in memory, but to put things in perspective, that's caching memory. It was already consuming that 10 times size when being run directly from php before.

        Memory pigs like wordpress eat like 64MB of memory before you even get to plugins. Memory deduplication is required if you are running multiple blogs because the cache files generated by things like SuperCache and MaxCDN also eat up the opcode cache space.

        Fun times.

        #1 rule of php memory management: NEVER inline html. Many people use it as a easy way to do SSI, but this eats memory, opcode cache or not.

        • or eaccelerator.

          I had stability issues with both xcache and APC on my production servers where things would go unexpectedly missing from the cache and throw nasty errors.

          No such issues with eaccelerator. very happy with that.

          • I had the opposite experience. When testing on some newer quad core servers (several years ago), I found that eaccelerator would cause segfaults in Apache that I couldn't pin down to anything in particular. It wasn't hardware either, because it happened on several machines equally. I ditched eaccelerator for APC and things have been peachy since.

      • by nzac (1822298) on Monday December 12, 2011 @09:01PM (#38350504)

        Its on github and depends on open-source libraries.

        from the github page:

        HipHop is licensed under the PHP and Zend licenses except as otherwise noted.

        Its opens source but not copyleft/gpl and if you want to contribute to the project i think you have to sign over the copyright (need facebook login to see the agreement).

      • by MikeyO (99577)

        A 4 digit ID and you can't make it to RTFA? :)

      • by Rennt (582550)
        Yes. Code is up on github, a link to it cleverly hidden right there in the summary.
      • by cshark (673578)
        Yes. I don't remember which license it's under though.
    • by MattW (97290) <matt@ender.com> on Monday December 12, 2011 @09:33PM (#38350736) Homepage

      It's too bad PHP doesn't scale.

      • Haha. :D

    • Great, along with all the other evils Facebook has perpetuated on the net, they've now made php more powerful and potentially more popular. They might as well give Darth Vader a perm.
    • What's ironic is that if Facebooks development team spent half the amount of time they spend trying to make PHP perform well enough for them, writing code in a more conformant language.. they'd be done already.

  • Yo Dawgs! (Score:4, Funny)

    by syousef (465911) on Monday December 12, 2011 @08:48PM (#38350398) Journal

    Da Hip Hop PHP compila is in Da House! Respect bitches!

    • Re: (Score:3, Funny)

      by binarylarry (1338699)

      Yo dawg I heard you like PHP, so we put an optimizing JIT compiler in your PHP runtime, so you can execute PHP code while you execute PHP code!

      • Re: (Score:3, Funny)

        by syousef (465911)

        Yo dawg I heard you like PHP, so we put an optimizing JIT compiler in your PHP runtime, so you can execute PHP code while you execute PHP code!

        Yo mama executes unoptimized PHP!

        • by iluvcapra (782887) on Monday December 12, 2011 @10:50PM (#38351276)

          Yo mama's so fat, she thinks strstr(needle, haystack) and strstr(haystack, needle) both sound delicious, she just can't ever remember which one is the one to use.

          Yo mama's so fat, she hides food in $a[1] and $a["1"].

          Yo mama's so fat, she silently coerces strings into sandwich, and when the interpreter complains, she puts an @ sign in front of it.

      • by MrEricSir (398214) on Monday December 12, 2011 @10:08PM (#38351004) Homepage

        Yo dawg I heard you like interpreting PHP code, so we put an eval() function in PHP so you can interpret PHP while you interpret PHP!

  • Interesting that they've settled on this approach, which in some ways is much more traditional: developing a high-performance JIT for a dynamic language instead of trying to statically compile a subset. Basically the approach taken by StrongTalk, V8, PyPy, Rubinius, etc.

    • by loufoque (1400831)

      Statically compiling a subset would yield much better results, but would be significantly harder to do.

      They took the easy way out; this is not a compiler any more than the reference implementation is. It's just a replacement for the reference implementation that sucks a bit less in terms of performance.

  • From the article....

    The first 90% of the hhvm project is done; now we're on to the second 90% as we make it really shine.

    • From the article....

      The first 90% of the hhvm project is done; now we're on to the second 90% as we make it really shine.

      Good at math they are not...

    • by fsckmnky (2505008)

      From the article.... The first 90% of the hhvm project is done; now we're on to the second 90% as we make it really shine.

      And when they are finally done optimizing it, squeezing every last bit of performance out of it, adding the ability to compile to a native binary, they will have achieved the remarkable accomplishment of having re-invented the C compiler.

      Way to go Facebook. Keep up the good work. ;)

      • by PCM2 (4486)

        And when they are finally done optimizing it, squeezing every last bit of performance out of it, adding the ability to compile to a native binary, they will have achieved the remarkable accomplishment of having re-invented the C compiler.

        They did that already. They're moving away from static compilation in favor of running it in a VM with a JIT.

        • by fsckmnky (2505008)

          They're moving away from static compilation in favor of running it in a VM with a JIT.

          Which is a complete step backwards if their goal is performance.

          • by PCM2 (4486)

            Which is a complete step backwards if their goal is performance.

            Not really. JIT technology is pretty advanced these days. (It's good enough for Java, anyway.) More importantly, though, my understanding is that static compilation forced them to heavily restrict their coding style. PHP being a dynamic language, there were a lot of features they had to leave on the table to make it work that way.

            • Re: (Score:2, Interesting)

              by fsckmnky (2505008)

              (It's good enough for Java, anyway.)

              Which is at least 50% slower on its best day, than C/C++ on it's worst day.

              As for JIT, it's a non-issue. Anyone could make .c or .cpp files executable, by passing them through the linux kernels MISC binary capability. [see "Kernel support for MISC binaries" under "Executable file formats / Emulations"].

              It's the VM part that kills performance. The Java VM, and presumably, the PHP VM, do not execute native machine instructions, but instead, use an intermediary format, as opposed to, native cpu instructio

              • Re:So True. (Score:5, Interesting)

                by PCM2 (4486) on Monday December 12, 2011 @11:25PM (#38351512) Homepage

                Which is at least 50% slower on its best day, than C/C++ on it's worst day.

                Got any numbers to back that up, or are you just pulling it out of thin air?

                It's the VM part that kills performance. The Java VM, and presumably, the PHP VM, do not execute native machine instructions, but instead, use an intermediary format, as opposed to, native cpu instructions.

                You don't seem to understand how a JIT works. Many portions of Java programs are indeed executed as native machine instructions.

                Combine that with the remarkable similarity between PHP syntax and C ( but without the speed )

                I wouldn't call the similarity "remarkable." "Superficial" might be a word I'd use, in the sense that Java syntax is also similar to C.

              • by fsckmnky (2505008)
                Now that I go and read the article, I see they have created a "PHP to C++" translator of sorts, not so much a JIT VM combination. It won't be nearly as bad performance wise, but, why even f' with PHP at that point.
  • by Maltheus (248271) on Monday December 12, 2011 @09:12PM (#38350594)

    They're just not maintainable in my experience.

    • by zero0ne (1309517)

      So:

      Pascal, Pawn, Perl, PHP, PL/I, Plus, Prolog, PureBasic, and Python ?

    • It's ironic how close P and R happen to be. Ruby fan, I take it?

      If not Ruby, what do you use for a scripting language? Please don't tell me you decided long ago that if it's possible to do everything in assembly, it must be done in assembly.

  • Can I "Like" this?
  • by kervin (64171) on Monday December 12, 2011 @10:00PM (#38350942) Homepage

    You can find a real PHP compiler at http://phpcompiler.org/ [phpcompiler.org]. It would be nice if the official PHP engine had built in support for loading and running bytecode ( like JVMs ) instead of strictly text code.

    • by Guspaz (556486)

      Or Phalanger at http://www.php-compiler.net/ [php-compiler.net] which is a GPL project that compiles to CIL bytecode, which is then run through .NET or Mono in a JIT fashion. It's a proper .NET language, so you get access to the .NET framework as well as the core PHP functions and default extensions. Unfortunately, some of the non-default extensions that they've ported (like gd2 or memcached) are not available in the GPL version.

      • by cshark (673578)
        Yes, but it's non standard. With Phlanger, you're mixing old extensions with known threading and security bugs with a weird namespace format, and an incomplete implementation. Then there's Studio integration, which is spotty. Didn't even support Studio 10 last I checked. If by "real" you mean, "runs half ass on .net" you're right. In terms of maturity, and in most other respects, it can't touch hiphop. Seriously man, try hiphop. It's amazing.
  • the readme says its a source code transformer that converts php into c++ then compiles it with g++.
    How is that a JIT VM in any sense of the word?
    • by PCM2 (4486)

      I think the Readme on GitHub is a placeholder. They took the Readme from HipHop, aka hphpc, which was the earlier project. This is HipHop VM, which is something different. Read the "more technical description," linked at the top, to get the picture. Basically, HipHop goes PHP-->Abstract Syntax Tree-->C++-->x64. HipHop VM goes PHP-->AST-->Bytecode, then runs the bytecode through a JIT.

  • dev only (Score:4, Insightful)

    by Fnord666 (889225) on Monday December 12, 2011 @10:27PM (#38351140) Journal
    Unless I misunderstood the post, this is only being used in their development environments. It sounds like they are still using statically compiled php for production. They did mention that they hoped to closed they gap in performance between the two in the near future though.

Some people carve careers, others chisel them.

Working...