13 ms·
Facebook releases HHVM, 60 percent faster than its current PHP interpreter
- nupark2 15y agoI find it interesting that the economics of inertia work out in favor of Facebook expending so much effort in improving the performance of a historically technologically poor language like PHP. Jason Evans is the author of jemalloc (and more). Given all the things he would be capable of applying himself to, it's surprising to see him working on PHP runtime performance (though, the problems are interesting).
- hvs 15y agoI'm not sure that I'd refer to PHP as a "historically technologically poor language". I'm not even quite sure what that means, exactly, but PHP has proven itself over and over again to be more than capable of working in environments with heavy load and numerous simultaneous users. In fact, in comparison to something like Ruby, it historically destroys it. Now, if you want to get into the details of syntax, naming conventions, etc.. sure, PHP is not everyone's favorite language to work with, but it is far from "technologically poor".
- nupark2 15y agoI'm referring to the quality of the implementation, its performance profile, the soundness of the type system and syntax, and -- like the original post -- measuring relative to the state of the art in JITs, including the JVM.
- j_col 15y agoIf the JVM is state of the art, how many applications of the scale of Facebook are using it? A serious question, as I don't know of any.
- nupark2 15y agoThe JVM is one of the most advanced production-quality JITs available. As for who is using it, everyone from Google to Twitter to Apple, as well a huge number of high-transaction business systems. The JVM is something that tends to get used quietly and widely.
- j_col 15y agoIt's also in my experience a massive memory hog, makes deploying your web application a pain (restarts anyone?), and is much more complex to develop for. If your Facebook and you're trying to get more bang-for-your-buck from your existing hardware, do you think its a good choice to migrate everything to the JVM (including a full rewrite to Java/JRuby/Scala etc.)?
- nupark2 15y ago> It's also in my experience a massive memory hog It's not that Java is memory hog per se, but rather that the total VM memory allocation must be specified at launch, and the VM will not (rarely?) give that memory back to the OS. This is largely an artifact of Sun's generational GC design+implementation, and has some interesting performance wins; namely, object allocation and deallocation are incredibly cheap, because in the fast case, all allocation requires is updating a single pointer. The last time I profiled java object allocation, creating short-live objects turned out to be insanely cheap compared to other allocators/runtimes. > Makes deploying your web application a pain (restarts anyone?) This largely depends on how you structure your web application. > If your Facebook and you're trying to get more bang-for-your-buck from your existing hardware, do you think its a good choice to migrate everything to the JVM (including a full rewrite to Java/JRuby/Scala etc.)? That depends largely on how much they're spending on hardware and JIT/language engineers, versus how much a rewrite would cost, amortized over the reasonable lifetime of their code base. You have to factor in the fact that they've built an entire organization around PHP, and it's not just a technological migration problem; they might also have to retrain or outright replace a large number of existing engineers. I'm inclined to say that it was a mistake to choose PHP, and moreover, to continue to use PHP as they scale. However, funding the implementation of better PHP runtime implementation may be the most fiscally conservative decision left available to them.
- maratd 15y agoAbsolutely. PHP just works and it's easy to make it work. That's the most important thing when choosing a platform. Asthetics are always secondary. It's certainly a pain to deal with inconsistent syntax, but fighting your toolchain is a far worse fate and with PHP, that's rarely an issue.
- laconian 15y agoFor a hack, maybe. Fighting your toolchain is an upfront penalty. Once things start moving smoothly, they tend to continue to work smoothly. And that's a problem that can be solved by further development of the toolchain. Poor aesthetics/readability? You pay that price every second you work on the code.
- maratd 15y ago> Once things start moving smoothly, they tend to continue to work smoothly. This is flat out wrong. If you're on a language all the cool kids are using, you'll find those cool kids have an obsession with perfection. To the point where they deprecate things instantly and break everything that worked before. See NodeJS and Python for examples. If you have 10K lines of code, not so bad. So you do a rewrite every year. When you have 100K lines of code or more, their obsession with perfection will destroy your business. A rewrite becomes an immense undertaking. You end up running old versions. Those old versions require dependencies which require you to run old operating systems. Eventually the entire ecosystem implodes. But guess what? Code that was written in PHP3 over 10 years ago works just as well today under PHP5. You can even mix and match. Does that make the syntax of the language ugly? Sure. It even encourages bad practices. So what? You're running a business, not an art gallery. Code should be beautiful, but not at the expensive of having a successful business and a working product.
- laconian 15y agoBut, I don't use the languages those cool kids are using. :) I imagine I would have to formulate a very defensive strategy to deal with breaking changes that would gobble up my productivity gains from using said cool language, just like the people that use Mongo have to DIY the checks that RDBMSes get for free. I use Java and C++, and I don't rush update the second new libraries become available. My team has a large regression suite, too, so it's been less painful (can't say painless) to detect breakage when our dependencies need to be updated.
- phillmv 15y agoIt's always hard to talk about these differences because 90% of the time we're actually just chest beating and comparing the length of our respective community's e-penises. When people complain about PHP they often mean that in an aesthetic, and in an academic sense, the designers of PHP have, arguably, made a lot of poor choices. What they usually mean is, due to the low barrier of entry coupled with poor aesthetic design choices the PHP community at large seems to have poor engineering standards. These all being Turing machines though don't prevent it from having quality engineering being applied to it, as is the case of Facebook. So, the corollary to "only a poor craftsman blames his tools" is "when you only have a hammer everything starts looking like a nail". I wonder how many people are paid to directly hack on a Ruby implementation vs Python (yay Google) or PHP (yay Facebook).
- umjames 15y agoIsn't that what Matz is doing now at Heroku?
- jackowayed 15y agoI think Engine Yard pays 3 people to be fulltime on the JRuby core team and 2 (not sure on that, certainly one) to be fulltime on Rubinius. Microsoft was supporting IronRuby until a couple years ago.
- streptomycin 15y ago> the performance of a historically technologically poor language like PHP One of the biggest reasons PHP supplanted Perl as the de facto web programming language ~10 years ago was that Perl running through CGI was incredibly slower than PHP.
- rscale 15y agomod_perl also had serious performance and memory leak issues. PHP sucked at the time too, but it sucked in ways that were easier to track down and fix.
- dspillett 15y agoPerl had a reputation for being more complex for a beginner too and leading to code that was difficult to maintain.
- dmooney1 15y agoI always thought it was because basic PHP was so intuitive for anyone familiar with a C-like language.
- pbiggar 15y agoThere's a ton of reasons PHP took off, including off the top of my head - cruftyness of perl - good timing, few alternatives (C and Perl basically) at a key point in the growth of the internet and web developers. - very easy migration from a static only site - easy to deploy, leading to... - wide availability of PHP shared hosting - in depth docs - commenting on docs (cut-and-paste programming ;)) - thousands of builtin functions: first real batteries-included language - recognizable syntax (esp vs Perl) for Java/C programmers - not awful performance - builtin MySQL support from an early stage - oh, it was free (and also Free) - dynamic typing - weak typing (as in, values coerced to other types easily, I know this isn't a real term)
- nir 15y ago> - commenting on docs (cut-and-paste programming ;)) Very true and rarely mentioned. PHP docs never had the fancy wiki/social/javadoc features you see in many languages, just a primitive comments system - and it was perfect. When you were picking it up back when "PHP3" yielded 0 results in Amazon (and we had to change the oil on our desktops every week) the docs were your bible, not merely in the sense of occasionally contradicted themselves but also in having examples, Q&A and recipes for common tasks posted by your peers in the comments, much faster than doc writers could catch up with the language's growth.
- deleted 15y ago[deleted]
- phillmv 15y agoSince they're hiring so many Googlers one presumes Python would be a top choice, but if you need an opportunity to whine about Ruby/Rails go for it.
- preinheimer 15y agoThey've spoken to this directly. Facebook has tried to migrate to something else (generally with a small team leading the charge) a few times. Let's say that there's 1M lines of PHP code right now handling Facebook's site. In the time it takes the team to re-write those million lines of code, another million have been written. So they can never catch up. Almost like Zeno's paradox, except the turtle moves faster :). All that aside, you can teach PHP to pretty much anyone, and it's rather effective at solving web problems. For quite a while they had some really smart people working on APC to help with performance, they've since switched horses to work on HipHop and the like to get the performance they need.
- yahelc 15y agovar_dump($hit); Good to see that Facebook's engineers still have a startup-y sense of humor.
- sjs 15y agoBy which you mean juvenile. I don't mean that in a condescending way. No one wants to work with a bunch of uptight folks. I think it's good too, but let's call a spade a spade.
- iamandrus 15y agoI would prefer juvenile and brilliant (but productive) programmers to boring men in suits sitting in dark cubicles, lifelessly writing code day after day, and who have no sense of humor or fun whatsoever.
- jasone 15y agoBelieve it or not, my $hit meter was too insensitive to notice the visual similarity to a four letter word until it was repeatedly pointed out by readers. Now that we're all on the same wavelength, let's call a spade a shovel, or even a $hovel, and, well, now we have $hovel and $hit to work with. Imagine the possibilities.
- nixxle 15y agoHow easy/hard/logical would it be to implement this for a medium-size website with about 250k monthly visits?
- leftnode 15y agoI don't think it's logical. Stock PHP can easily handle a website with 250k monthly visits. Or, rather, your speedups will most likely come from talking to the database less, doing less IO, that sort of thing. CPU probably isn't your bottleneck now.
- nixxle 15y agoFair enough answer. Thanks! I'll report back when we hit 800m. ^^
- leftnode 15y agoThe ironic thing about Facebook releasing this is they're (and a handful of other sites) are the only ones that would really benefit from this. I do love that they release it as open source. At my last company, we handled about 20 million API requests a day through a PHP API. Granted, the request and response were smaller than a standard webpage, but that was using stock PHP (hell it wasn't even custom compiled, it came straight from the Debian packages). So, you need to hit a pretty huge amount of traffic before something like this makes sense. Of course, it's always neat technology to play with.
- carbocation 15y agoSurely you used opcode caching?
- rhu86 15y agoPresumably he just installed the php-apc package
- pantaloons 15y ago
- feralchimp 15y agoHats off. I have no love for Facebook's product or business model, but their engineering is diesel, and it's very cool that they're sharing such a deep piece of work.
- tszming 15y agoagreed, and it is not only a deep piece of work, but the core infrastructure that powered their business.
- pyman 15y agoI know some great Facebook engineers and some terrible ones. An ex-colleague of mine who loves writing spaghetti php code joined Facebook almost a year ago. I would say that 30% of Facebook's engineers are top notch, and 70% are just average php and javascript developers.
- judofyr 15y agoAnd it seems that the 30% creates tools so the 70% can continue writing sub-optimal code that works well.
- maratd 15y agoThis may actually be a sound business model, regardless of its unpleasant aftertaste.
- makmanalp 15y agoThat is actually the principle behind enterprise java, I thought. Force everything into its own isolated and replaceable small black box so that your grunt development can be done by "commodity" programmers.
- bluesnowmonkey 15y agoFor a company that size, 30% is amazing.
- 15y ago
- afsina 15y agohttp://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=php&lang2=java http://shootout.alioth.debian.org/u32q/benchmark.php?test=al... so x30 more to go..
- EricBurnett 15y agoIgnoring the fact that these are all running on the standard PHP interpreter, not one of Facebook's creation... The benchmarks linked ran on a 4 core machine with varying amounts of parallelism, generally with Java being more parallelized. When running a server farm, as Facebook does, aggregate CPU time is more important than wall time^, since one can easily scale the number of processes to fit the machine. By CPU time the difference is down a factor of two at least, possibly more. Be careful with benchmarks. They distill a comparison into a single value for easy use, but it's not going to be the most appropriate metric in all cases. ^So long as wall time is "sufficiently small", which it generally is.
- SomeOtherGuy 15y agoSo check the single core version: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=php&lang2=java http://shootout.alioth.debian.org/u32/benchmark.php?test=all... Oh look, PHP is still 30 times slower than java. A 60% improvement to that still won't get it within an order of magnitude. And PHP is not significantly faster or easier to develop in than java, so you are losing execution speed to gain nothing.
- maratd 15y agoJava is a compiled language. PHP is not. If you need to do a benchmark to realize that a compiled language is faster than its dynamic counterpart, then I really don't know what else to say to you.
- fleitz 15y agoSome compiled languages are faster, some aren't. Speed of execution is largely related to the optimizations the interpreter / compiler can do, and in many practical cases the qualities of the default library. The other problem is that many interpreted languages are implemented in C leading to the usual performance implications of inner-platform effect. Another problem is the underlying CPU architecture, the vast majority of CPUs are designed to execute C-like languages.
- RobAtticus 15y agoInteresting that so far most of the comments are pretty positive. Every time Facebook gives a HipHop talk at my university, it seems the general feeling in the room is "ugh, why?" The PL people wonder why they're bothering with such a broken language, and other language zealots get angry that they aren't using [insert-favorite-language-here]. I wonder if there is a point where they can't squeeze anything more out of HipHop and have to do a drastic rewrite.
- pyman 15y agoWhy? HipHop is already faster than your Dad's fancy sport car.
- hvs 15y agoThe thing is, when they can't squeeze any more out of HipHop, the last thing they are likely to do is use one of those [insert-favorite-language-here], because HipHop will be so much faster than any implementation of those other languages. An important point to remember is that languages, as interesting as they are, are simply means to translate ideas into machine code. If they translate it into really fast machine code, it doesn't really matter that much (except academically) how "correct" the language is. I do not enjoy writing in PHP, but I have a lot of respect for the real world work that Facebook is doing with it.
- jrockway 15y agoIf you want fast, why would you use PHP and then write a new VM, when you could just use Java or Common Lisp or Haskell or C? Those already exist and are already damn fast.
- RobAtticus 15y agoThe explanation they seem to give is there are a lot of people who can write PHP, and can write PHP code very fast. So because PHP allows their engineers to iterate and prototype new features very quickly, any attempt to convert to a new language is thwarted when those writing in PHP are outproducing the conversion process that it'll never catch up. I'm not saying it's a great explanation, but it is what it is.
- j_col 15y agoTheir logging server Scribe, which they also open sourced, is equally awesome. Kudos to Facebook for releasing such cool technology.
- oconnor0 15y agoThe discussion of this over on Ars Technica centered around their current PHP interpreter being twice as slow as the Zend PHP engine so a 60% improvement would still leave HHVM slower. What am I missing?
- donut 15y agoI'll probably get dinged for making a sophomoric observation. Their example code makes use of the variable $hit, performs a var_dump($hit) and then returns $hit. Am I the only one that noticed this?
- mkramlich 15y agoI have two reactions: 1. it's still PHP 2. why are they still using PHP in a world where things like Python, Ruby and Java exist?