HipHop VM: now at 98.5% PHP framework parity, 16% faster | Hacker News Reader

HipHop VM: now at 98.5% PHP framework parity, 16% faster

hhvm.com

154 pointsjamesgpearce103 comments

I'm not sure I understand. Is this the framework that "compiles" PHP?

Is the 15% performance increase relative to vanilla PHP or to a previous version of HHVM?

HHVM is a JIT engine for PHP code. The performance increase in relative to the previous release of HHVM.

HipHop was the PHP -> C++ compiler. HHVM is a JIT-compiled implementation of PHP.

The 15% increase is relative to HHVM at the beginning of the 3-week sprint they just completed. HHVM was already far faster than vanilla PHP when it was first publicly announced over a year ago.

That's more interesting. How much faster is hhvm overall?

The Wikipedia article (https://en.wikipedia.org/wiki/HipHop_for_PHP) says "up to 6x", however, about 2x speedup versus plain PHP was a more typical experience for me when I used it before.

So basically it's as fast as using PHP with an opcode cache?

No, 2x speedup relative to PHP with an opcode cache.

That's a good question. PHP 5.5 with the newly-open sourced (and integrated) opcache gave it a good run for its money before this optimisation sprint [1]. Under real-world 'bloated framework' usage, HHVM was already pretty cool [2]. I'd like to see the results after this speedup.

1. For simple code only - once it's more computationally intensive, HHVM wins. http://www.alexfu.it/2013/10/22/symfony-benchmark-on-hhvm.ht...

2. http://blog.liip.ch/archive/2013/10/29/hhvm-and-symfony2.htm...

Other than Facebook, does anybody have HipHop running in production? Any big caveats?

Me! Yeah, it's not 100% compatible, so my app runs all it's tests on HHVM to make sure I haven't run into any edge cases, which hasn't been an issue. I get more mileage out of my smallish VPS from it, with no effort on my part other than knowing what frameworks don't work (very very few now) and testing before deploying to staging (as you should be anyway).

I'm pretty happy with it. Is it worth it? Well, if you've got a test suite, run it through HHVM to see if you'll have any issues. If the answer is no, then why turn down free performance :)

I run HHVM on a website. I started in June (back then you had to write your config file from scratch and some API functions were missing). I refactored my code to PDO (mysqli was missing back then). It worked fine from the beginning, and the uptime and overall performance is really great.

I use Nginx as frontend and direct all dynamic request to HHVM's own webserver (https://github.com/facebook/hhvm/wiki/Using-nginx-as-Front-S... )

Keep in mind, Facebook runs on HHVM too, so it's rock solid.

Btw. the devs are very helpful on the official irc channel!

Other than Facebook, does anybody need HipHop?

You're confusing HipHop with HHVM.

HipHop took PHP code and basically turned it into a statically compiled C++ application. The resulting binary acted directly as a web server. It was pretty fast, but very limited.

HHVM is an actual JITing virtual machine for PHP. It's still huge (one of the project pages say that the binaries are nearly a hundred megs), but it's now a real-world reimplementation of PHP, capable of doing anything PHP can, including eventually being run by mere mortals with normal code.

Yes, I do. I have a PHP app that can be CPU bound (lots of ML baked into async threads). It has been a godsend.

I would if their PDO implementation supported postgres :(

We don't use hphp in production at Etsy but do use it for static analysis in our build. It catches lots of dumb mistakes.

Nice! CodeIgniter is at 100% now. I've been contemplating the switch to hhvm for my startup, now it seems likely.

Don't take this the wrong way, but you're actually developing new applications with CodeIgniter? Ugh...

Yeah, Laravel is pretty much the modern framework for people who can't divorce themselves from CodeIgniter.

As someone who can't stand PHP, Laravel is pretty much the only thing that's made me feel like the language has some worth. It feels very similar to the Python and Ruby frameworks I'm used to, and is actually pretty nice to read.

Now if only the rest of the PHP devs stuck in 2005 would switch to it...

What does Laravel do that other frameworks like FuelPHP and Yii don't do? I hear a lot about it but don't hear a lot about why it's so much better than others.

On the surface most of the popular PHP frameworks are not much different from each other. Basic MVC separation, some sort of dependency injection container (actually a service locator), Composer and standardized autoloading, etc. Once you dig into the coding aesthetics then the differences start to become clear. Yii isn't PSR compliant, both FuelPHP and Laravel make liberal use of Facades and/or __callStatic to preserve the style of static function calls that are prevalent in CodeIgniter. I guess what makes Laravel stand out is the sheer amount of documentation and examples that are available, both on the website and in the code itself. This makes it really easy to get started.

Me, I'm not really keen on the Component::function() syntax. Feels like a crutch to me. Especially when people go out of their way to avoid specifying namespaces by abusing class_alias. Plus you're not really saving that many keystrokes compared to, say, $this->app['component']->function(). (Yes, I like Silex).

$this->app['component']->function() gives me an instant headache. Which is why I always wind up giving up on Symfony/Silex after trying it out every now and then.

OTOH, I had a much easier time with Laravel, though it uses some of the same Symfony components under the hood.

Yii still exists? Why?

Laravel has a half decent API and doesn't rely overmuch on (untestable) static functions. My evaluation of FuelPHP was admittedly brief, but let's take another look:

http://fuelphp.com/docs/general/controllers/base.html

and http://fuelphp.com/docs/general/models.html

For those who may be unaware, the issue with static functions is that, if you are calling a static method, you will execute that method. You're not able to choose not to execute that method (unless you do something surpassingly stupid like checking whether you're in test mode), and you can't generally make that method return anything other than what it normally does. Isolating that static method is rather difficult, and if that static method happens to call another one, well, it had better not be an issue with your test, because you're not going to stop it happening.

I know the FuelPHP devs have gone on record saying that Fuel doesn't rely heavily on static methods, and that static methods aren't a problem, and that to the degree to which there is a problem, they are gonna fix it, but...

http://pastebin.com/K03HMyVs

Here we compare CakePHP, Laravel, and FuelPHP (Thank you to Sebastian Bergmann for providing the statistics utility). For anyone actually evaluating these platforms, you may want to check out these benchmarks as well:

http://www.techempower.com/benchmarks

Without saying anything about how easy or fast it would be to develop for each of them, it seems that for trivial tasks Laravel > Fuel > Cake. From the code statistics, we have: Fuel: 785 static methods (22.45%) Cake: 530 static methods (7.96%) Yii: 483 static methods (7.95%) Laravel: 0 (0.00%)

Laravel seems pretty light as far as that goes, and generally when I'm faced with a large project I want the framework to be large as well. I feel like otherwise I'm going to end up finding or writing libraries for things that I feel like the framework should take care of. I would have a hard time recommending a PHP framework, imo they're all pretty much crap. Laravel is not better per se than other frameworks, but it does (far) less, and therefore does it less badly. Divine intervention alone will fix the PHP world at this point, but if you can avoid CodeIgniter, Yii, and FuelPHP, probably no other choices will be as bad.

I still do. Not sure how you can take your derisive comment the right way, either.

Hmmm Laravel at 100%. This is now getting interesting!

Drupal is also 100%, that's actually really nice. Want a quick performance boost on your Drupal site, replace PHP with HHVM

This is core though, from what I hear contrib still breaks (haven't tried myself)

I tried it two days ago after they made the fastcgi announcement. My day job sites are fairly big with what I consider a pretty large number of contrib modules. I managed to get it up and running, but the HHVM logs were full of notices and it finally bombed out after several requests (not enough to really warm up the VM) on something related to apachesolr, and another one related to GD, which is strange because we use imagemagick, but whatever. Sad Trombone.

The really cool part though, it truly was "drop in". Every bit of my existing nginx/fpm configs worked as is, so once it's a bit further along, it's just a matter of shutting down fpm and firing up HHVM.

There were also a couple of gotchas in the setup related to the fact that their apt installer installed HHVM configs that don't assume Fastcgi, so it took a little bit to figure out the correct edits to the init script and HHVM config so it'd listen on :9000 instead of :80, but all in all that it worked at all was really fun for a minute. Very excited about this project.

Laravel is technically at 100%, however the unit tests are throwing a lot of warnings.

compare:

php 5.5: https://travis-ci.org/laravel/framework/jobs/15683979

hhvm: https://travis-ci.org/laravel/framework/jobs/15683980

Is there a good tutorial on installing HHVM on server and then running your PHP app?

Yes, on the official wiki: https://github.com/facebook/hhvm/wiki/_pages

First read the page related to your Linux/BSD e.g. "Prebuilt Packages on Ubuntu 12.04"

Then read the page "Using nginx as Front Server to HipHop"

As last step read this blog article how to write/edit the config file (/etc/hhvm.hdf): http://www.hhvm.com/blog/113/getting-wordpress-running-on-hh...

Read this and copy things you need from the documentation: https://github.com/facebook/hhvm/blob/master/hphp/doc/option...

This is how I got HHVM working.

To sum up:

  * you need a little bit of basic Linux knowledge
  * install Linux or BSD (e.g. Ubuntu 12.04 LTS) (64-bit)
  * install Nginx (or since last week HHVM also supports Apache with FastCGI)
  * install HHVM
  * install MySQL or MariaDB, etc.
  * create a web directory where you place your php files
  * edit the hhvm.hdf (config file)
  * start hhvm

Btw. a lot of blog posts you find with Google search are still about the old HpHp (the former and now outdated PHP to C++ translator also called HipHop from FB)... so better skip third party blog posts older than January 2013 ;)

I wonder how hard it would be (for me) to take php and change all function names to be consistent. All PascalCase and spelled out (no awful abbreviations). Then download the documentation and change it there as well.

First you'd have to make sure your string hash function isn't strlen.

I thought this was a joke at first....

Ahh yes, take the most criticized aspect of Java -- the obscene verbosity -- and cram it into PHP. Sounds wonderful.

I'll take a long function name over an incomprehensible one any day.

Given that many of PHP's method names are that way due to mirroring C (and others due to the hash table hackery), I think you'd just be much happier in a different language.

The function names come mostly from C, so it's not really PHP's fault.

It _is_ their fault, for repeating the stupid mistakes that Kernighan, Ritchie, et al made when designing Unix and C.

Short names weren't really a mistake when K&R made them.

Yes, for some time (the dark ages I like to think) programmers had to sacrifice productivity to make things faster, or to make them fit in memory. The original C compiler had a 6 character limit on variable names, leading to abominations like `strstr()`.

Fortunately, by the Pentium era, which was when PHP was designed, those times were long gone.

"X made this design decision before us" is never a good justification for any design decision unless the decision is truly arbitrary (i.e., are arrays 0 or 1 indexed?) -- then it might be better to stick to what's more familiar. If it was a good design decision then, then there must have been some reason at the time that should be true now to give a good case for repeating a design decision.

I find the juxtaposition between PHP's short function names taken from C, and things like T_PAAMAYIM_NEKUDOTAYIM to be rather funny.

recently(not quite) there was a talk in php internals about changing that.

read this:

http://philsturgeon.co.uk/blog/2013/09/t-paamayim-nekudotayi...

Well, so long as they don't fix the parsing of octal int literals that is okay. Loosing both of my favourite offhand complaints would be rather disappointing. ;)

Never seen that one, but I think it's cute.

Expanding abbreviations doesn't improve clarity.

E.g. XMLHttpRequest vs ExtensibleMarkupLanguageHypertextTransferProtocolRequest

and ftp_ssl_connect vs FileTransferProtocol_SecureSocketLayer_Connect

or if you want to get really ridiculous:

MysqlndUhConnection::sslSet becomes MyStructuredQueryLanguageNativeDriverUserHandlerConnection::SecureSocketLayerSet

You're misrepresenting his position pretty badly. XMLHttpRequest is a comprehensible name. "MysqlndUhConnection" much less so.

Not being very familiar with PHP, I don't have any pet examples of inconsistent names to offer corrections for that might correspond with what he's actually talking about.

yeah , some people think it's easy to understand what strstr does...

...like everyone who has learned C or its derivatives. It's just part of the vocabulary of the language. You could as well ask "what's a list comprehension" in Python, for example.

Set comprehension is a standard mathematical term (http://en.wikipedia.org/wiki/Set-builder_notation). List comprehension is a fairly natural name given that.

While you're at it why don't you fix: (needle, haystack), (haystack, needle)? :P

With array functions, the needle is first. With string functions, the haystack is first.

https://gist.github.com/salathe/1672543

This still doesn't convince me it was ever a beneficial design.

I didn't claim it was beneficial, just consistent.

Are you sure it's that consistent? I just feel like there's some function hiding somewhere that breaks this rule.

Or even use a proper IDE to code other than gedit/notepad !!

The verbosity is not only comprised of long method names.

The verbosity of Java has nothing to do with long function names.

Ironically, the obscene verbosity it is also a common trait of "not very smart" people.)

This was making the rounds recently: http://news.php.net/php.internals/70691

Basically, if you use PHP you're part of the largest computer joke in history.

"PHP you're part of the largest computer joke in history" <-- Good Luck with Scaling Ruby/Python

Python scales quite fine actually (Disqus and YouTube use it for a majority of core development). It's all about the tech behind the scenes (uWSGI, Tornado, Ngnix, memcache/redis, etc), not the language itself (just as it is with PHP). Try scaling PHP if only using Apache Prefork instead of mod worker + php-fpm or Ngnix + php-fpm and you'll see what I mean.

I have no problem with using either PHP or Python on a particular project, depending on what is involved. I wish PHP threads would show a bit more maturity/pragmatism on both sides of the aisle sometimes.

http://yougov.github.io/pycon/slides/

http://highscalability.com/blog/2012/3/26/7-years-of-youtube...

http://www.slideshare.net/jinaljhaveri/scaling-python-webapp...

http://blog.disqus.com/post/62187806135/scaling-django-to-8-...

It wouldn't be that hard if you did it in userland (i.e. pure PHP). But you also need to switch around inconsistent parameter orders (e.g. haystack vs needle) and disable the use of the old ones (which can't really be done w/ the pure PHP aliases). The docs are just docbook, but have had a ton of work, you'd be best to PHPDoc your new methods.

The problem is speed and compatibility. If you did it natively you'd have to do it twice, once for HHVM and once for the Zend engine. If you did it in pure PHP it would cause performance issues since the interpreter isn't smart enough to inline (maybe HHVM is, but even it will take a trace or two to realize the JIT need probably).

Seriously, it's not that big of a deal.

You can write wrapper functions in a PHP script and include it your index.php.

e.g.

  function findFirst ($haystack, $needle, $before_needle=false, case_sensitive=false) {
    if (case_sensitive) {
      return stristr($haystack, $needle, $before_needle);
    }
    return strstr($haystack, $needle, $before_needle); 
  }

You can submit them as RFC to https://wiki.php.net/rfc and maybe your suggestion end up in a future version of PHP. As PHP code in HHVM is almost as fast as C++ code, your wrapper functions will be still useful for you in the meantime.

On paper the lack of consistency is a problem. In reality your editor will autocomplete the function name and tell you its arguments, so it's really not that big of a deal. I mostly hear non-PHP programmers complain about it.

While you're at it, convert intrinsic types to objects too, while retaining backwards compatibility:

    $foo = 'bar';
    echo $foo->length(); // 3
    echo strlen($foo); // 3

This would get rid of a lot of the confusion around string function names.

The performance increase in relative to the previous release of HHVM.

Does anyone have an easy method of testing HHVM on your website?

I was thinking of recording the production requests for x amount of time and replaying them on HHVM so you could see if responses are identical, there are no crashes, state of the database is same afterwards, etc.?

A good test suite? ;)

Seriously though, I decided that if I had a project that was difficult to test, that I knew had hairy code that used some funky features it was best to just stick to APC. All my new projects are being built on HHVM directly with test suites as I go.

Edit; that was a while back now, though. What frameworks and libraries are you using? Run their test suites through HHVM and if they all pass, you'll be fine. Facebook use it themselves now apparently.

Recording requests is a good idea.

Another idea once you're reasonably comfortable and have done a smoke test is to direct a small amount of your traffic/users (say 1%) to the HHVM version, while closely monitoring its error log.

What does a Lockdown implies?

I'm not sure about the particulars of this one, but a lockdown is generally a period where you are encouraged to prune away unnecessary and/or lower-priority requests for your time.

There generally aren't a lot of status meetings, team meetings, project meetings, and so forth at Facebook, but you might want to turn down a request to present at another team's meeting, or turn down those requests to interview - they can wait, or another person can be found.

People tend to make progress on lower-priority work items in between higher-priority work items - things like migrating onto a new library or version of a service, or maybe migrating from one set of machines to another if you aren't using one of the high-level service management systems. This is necessary to prevent these things from becoming interrupt items down the line, but during a lockdown period, it's okay to let these slide for a bit.

If the whole team does this, then suddenly you're spending a lot more time together. Instead of potentially working on different parts of the software like you usually do, you can all focus on a particular class of problem - in this case, performance and parity. That means everyone has that context loaded up, and you can have better discussions and quicker code reviews.

I see a lot of familiar frameworks and CMSs except one. Wordpress. Any idea why Drupal and Joomla would be listed without WordPress?

Wordpress' unit test suite was just too gnarly to get running with our test harness. Send us a pull request if you can get it working.

https://github.com/facebook/hhvm/blob/master/hphp/test/frame...

It seems at the moment there's no way to have a DB server available when running tests. Is that correct? Until that happens, I don't imagine WP tests will be able to run.

They mention the compatibility of the projects unit tests with their own testing so perhaps WordPress has some things in their test setup that didn't fit. They mentioned CakePHP as another example that wasn't included.

Apparently there are some incompatibilities such as Wordpress using some case insensitive constants to support some old plugins while HipHop does not support that. As in http://www.hhvm.com/blog/113/getting-wordpress-running-on-hh...

I haven't looked into integrating with the test harness, but the test suite was pretty easy to get running locally. Unfortunately it crashes halfway through, but up until that point, the majority of the tests passed.

Hey guys, congrats on the release. Any news about Hack coming out any time soon?

With the recent discussion on the origins of PHP function names, and about what, if anything, can be done to fix PHP without ruining it...I'm curious about what happens at Facebook. Besides HipHop, do they maintain a strict PHP style among their developers? Even if HipHop can handle all of PHPs variations, I imagine there's time saved by writing optimally-designed (for the human) code, too?

Yes, they have a static analyser for PHP, Hack, written in OCaml

http://www.youtube.com/watch?v=gKWNjFagR9k

Internally at my company, we've found https://github.com/scrutinizer-ci/php-analyzer to be very effective (after we made some hacks to support 5.5) and we can put it in our sniff pipeline in CI (a tad too slow for a pre-commit hook).

For core language features like that, there really is no way to "fix" it. Just pick a better language.

Poor choice of function names are the easiest of problems to fix. Write an internal base framework that you use and strongly discourage the use of functions outside of it. Even if the new set of APIs are as simple as just forwarding the call to the standard PHP one with reversed arguments, using one example people complain about all the time. This isn't hard to do, doesn't require a lot of upfront work (add APIs as you go) on a new project, and won't give you too much (if any) of a performance hit. You don't need to burn the house down because you don't like how the furniture is arranged.

PHP has so many more problems than that, though. I don't think it's worth the effort. It'd be like replacing the rotting floorboards of a house that has mold spores in every corner and a caved-in roof.

wow, you really hate PHP. That that mold infested roof caved in house runs a great deal of the web.

In what universe? Maybe to maintain wordpress applications, but thats just one product. I don't know that codes in php anymore.

We are literally in a thread about one of the biggest names in tech and something they invent to help with their massive PHP codebase.

Yeah, but Facebook is just a collection of Wordpress plugins.

See: http://wordpress.org/plugins/facebook/

;)

The universe outside your echo chamber.

Haha wow the blindfolds are strong with this one.

I'm actually a tad worried about what will happen to all the people who coded primarily PHP for their whole life when that roof finally collapses. Seems like it might look a bit like what happened with Symbian / Nokia -- they also had a massive cognitive dissonance over the quality of the developer environment, and when the system finally broke, it broke quickly and in a nasty way.

Then again, it's not impossible to learn a new environment or career path... and I'm quite against the thought that any language could permanently ruin a coder.

Additionally, something being popular implying it's good is a blatant fallacy.

I'm curious how you came to the conclusion that something that occupies, by conservative counts, over 75% of the web as being "a blatant fallacy".

Symbian / Nokia went the way of the dodo because the end user fell in love with the ease of use of the iPhone.

In our case, the end users are people who use the internet, not the ones writing code.

Your argument is about as ridiculous as I can imagine, with no real data to back it up other than your frothing hatred of a language.

Calling each and every criticism of the language you like as "frothing hatred" (as I've seen PHP folks do quite a lot lately) reeks of cognitive dissonance. Perhaps you should get over it.

Also, the end users of a programming language are the programmers, not the users of the application. 99% of users could not care less what's under the hood just as long as it works.

It does. COBOL also runs a large number of major banking and government infrastructures. Should we be working on a revision to COBOL with prettier syntax?

I don't hate PHP, but I've written, looked at, and audited enough of it to come to dislike it.

Do you have any PHP code you've written that you can link to? I'm curious as to how versed in PHP you actually are.

Code style is enforced (but overridable) by the code review system - both automated tools that provide feedback ("lint") on the code (things like "Don't use funcx() - it sucks <link here> - rather use funcy()"), and human code review.

Reply on news.ycombinator.com