Facebook releases HHVM, 60 percent faster than its current PHP interpreter

https://www.facebook.com/note.php?note_id=10150415177928920&hn=2

by adeelarshad82 • 15 years ago

164 142 15 years ago

nupark25• 15 years ago

I 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).

hvs2• 15 years ago

I'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".

nupark25• 15 years ago

I'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.

maratd12• 15 years ago

Absolutely. 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.

phillmv• 15 years ago

It'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).

streptomycin2• 15 years 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• 15 years ago

mod_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• 15 years ago

Perl had a reputation for being more complex for a beginner too and leading to code that was difficult to maintain.

dmooney1• 15 years ago

I always thought it was because basic PHP was so intuitive for anyone familiar with a C-like language.

sciurus• 15 years ago

As an aside, there are an enormous number of ways to deploy a modern perl application. For anyone who is curious, see slides 30 through 79 of http://www.slideshare.net/miyagawa/deploying-plack-web-appli...

themonk• 15 years ago

mod_perl was there, it performed better but little bit extra memory footprint.

I don't know why mod_perl was known to very few and PHP become popular.

fallous3• 15 years ago

Sorry, but that's just historically inaccurate. PHP _10_ years ago was popular because it was a templating language that could be embedded in HTML, in which case it supplanted SSI and really was a competitor to ASP.

mod_perl was spanking PHP 10 years ago from a performance standpoint, but the democratization of the web meant that a lot of people that started with basic HTML layout then learned to extend it with PHP in templates, then moved on from there. Much the same as Perl became a dominant CGI language in mid/late 90s because a lot of sysadmins and hackers transitioned to back-end development due to web programming demands.

preinheimer• 15 years ago

They'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• 15 years ago

    var_dump($hit);

Good to see that Facebook's engineers still have a startup-y sense of humor.

sjs• 15 years ago

By 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.

iamandrus3• 15 years ago

I 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• 15 years ago

Believe 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.

nixxle3• 15 years ago

How easy/hard/logical would it be to implement this for a medium-size website with about 250k monthly visits?

leftnode2• 15 years ago

I 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.

nixxle3• 15 years ago

Fair enough answer. Thanks! I'll report back when we hit 800m. ^^

jerf• 15 years ago

More details: That's about one hit every ten seconds. While I know that you'll get bursts, you still shouldn't be exceeding 10 hits per second very often. Any web framework can handle that; the reasons why you can't sustain that or can't get good performance out of that are going to be found in your code, not the framework code, and linear speedups probably won't be the difference between "working" and "not working".

leoedin• 15 years ago

Are you finding that your visits are starting to actually make a performance hit on the servers? For that kind of scale, assuming your code isn't doing weird things, the lowest tier Linode VPS or similar should be more than capable of serving the pages.

nixxle3• 15 years ago

No, we are not experiencing any trouble at all. I'm just always looking for new ways to optimize and keep me and my colleagues busy. Playing with kind of stuff seems like fun.

rplnt• 15 years ago

Others answered the logical part of the question. I would be interested in how easy/hard it is. If anyone tried to get it running.

feralchimp• 15 years ago

Hats 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• 15 years ago

agreed, and it is not only a deep piece of work, but the core infrastructure that powered their business.

pyman2• 15 years ago

I 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• 15 years ago

And it seems that the 30% creates tools so the 70% can continue writing sub-optimal code that works well.

bluesnowmonkey• 15 years ago

For a company that size, 30% is amazing.

kmavm6• 15 years ago

Hey, I work at Facebook on HHVM.

I actually view Facebook as the opposite of what you're describing. VMware, for instance, really did have a bimodal engineering organization; some pieces were amazing, but many were so-so. That can have its strengths, too, and it has worked out ok for VMware to date, but Facebook has the absolute opposite philosophy. For instance, you don't have a "hiring manager" here, because the selection process is decoupled from the allocation process. This means a uniform bar across groups; e.g., I interview people destined for all different parts of the stack, and I expect the same level of skill for all of them.

itmag• 15 years ago

I would say that 30% of Facebook's engineers are top notch, and 70% are just average php and javascript developers.

Pet peeve of mine: why is the word "engineer" thrown around so much on HN? Is it meant to distinguish a certain class of people from mere coders? Or is it just a fancy word of saying "coder"?

I've always referred to myself as a coder. Should I change this?

I am genuinely curious, not trying to put anyone down.

iamandrus3• 15 years ago

Agreed. I don't like what Facebook is doing with the social network portion of its business whatsoever, but their engineering is brilliant and it's awesome for them to release something as amazing as this software.

grinich• 15 years ago

...with the social network portion of its business...

Isn't that the entirety of their business?

afsina2• 15 years ago

http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

so x30 more to go..

EricBurnett• 15 years ago

Ignoring 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.

SomeOtherGuy8• 15 years ago

So check the single core version: 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.

igouy• 15 years ago

> a 4 core machine with varying amounts of parallelism

Let's force the programs onto one-core.

http://shootout.alioth.debian.org/u32/php.php

> aggregate CPU time is more important than wall time

Both CPU secs and Elapsed secs were shown.

> 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.

afsina pointed to a program-by-program comparison - not something distilled down to a single value.

RobAtticus3• 15 years ago

Interesting 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.

pyman2• 15 years ago

Why? HipHop is already faster than your Dad's fancy sport car.

hvs2• 15 years ago

The 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.

jrockway3• 15 years ago

If 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.

j_col5• 15 years ago

Their logging server Scribe, which they also open sourced, is equally awesome. Kudos to Facebook for releasing such cool technology.

donut• 15 years ago

I'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• 15 years ago

I 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?

oconnor0• 15 years ago

The 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?

Facebook releases HHVM, 60 percent faster than its current PHP interpreter

Related Stories