8 ms·

HHVM is fast – too bad it doesn’t run my code

69 points by anu_gupta 13y ago

sambeau 13y ago
So am I right in thinking that HPHPc is around 6x faster than Zend and HHVM so far adds another 40%? i.e. HHVM is currently 8x faster than Zend and still getting faster?
- ptarjan 13y ago
  It depends what you are running, but you are at the right order of magnitude. Our main measurements are from running facebook.com back when it could run on both HPHPc and PHP 5.2 and then extrapolating from there with any improvements.
- masklinn 13y ago
  Yes, although that can be considered an odd comparison as technically at this point HHVM is not a PHP implementation (ignoring the incomplete stdlib and autoload bugs) due to things like > CakePHP has a class named String. HHVM does not allow [...] for classes to have names of primitives. and > a method called setValue() that takes two parameters, [...] only one parameter is provided [...] HHVM does not allow this. and > HHVM requires classes that implement interfaces to be compatible with the interfaces they implement. You can argue the HHVM language is a better language than PHP (not a high bar to set), but that makes HHVM not a PHP runtime.
  - RobAley 13y ago
    I disagree. Currently there is no standards body that defines what is PHP, and thus the "official" PHP runtime is "simply" another runtime like HHVM (and others) that implements what it considers to be PHP. It's taken as the "defacto" standard simply as it was the first, and still largest supported, PHP implementation. There is currently talk on PHP Internals (as there has been for some time, to be fair), of creating a PHP standards body to dictate the language. The "official" PHP runtime will (probably) then be written to that standard, and any other runtimes can conform to the standard (and be a "PHP runtime" as you define it) or not as they wish.
    - kbenson 13y ago
      If a language developed as a runtime, and no standard has yet been defined for exactly how the language will behave, then that runtime IS the spec. See Perl. In the meantime, if HHVM doesn't conform to some version of the PHP runtime, it doesn't conform to the PHP language (of the same version). The community could change this, either through defining a standard or accepting HHVM as close enough to be considered a PHP dialect, not a different language with similarities.
      - RobAley 13y ago
        > If a language developed as a runtime, and no standard has yet been defined for exactly how the language will behave, then that runtime IS the spec. See Perl. Nope, it simply means that there is no spec.
- nolok 13y ago
  HHVM doesn't permit quite a few things that regular php allows, and it also turns into outright errors "bad" things that regular php treats as warnings because it thinks it can run despite it. I also don't think it supports eval(), although it may have changed since the last time I read about it. When you remove the "I don't know, maybe, maybe not" part, you can make you code a lot more efficient. (not making a judgment call here, just clearing things up on how it is possible to be that much faster)
  - masklinn 13y ago
    > (not making a judgment call here, just clearing things up on how it is possible to be that much faster) It's probably possible to be that much faster (on average and in good cases) even without throwing out huge swathes of the language. See: javascript runtimes, they don't throw out the parts which bother them but they do deoptimize (or not optimize in the first place) code making use of specific constructs (e.g. `eval` or `with`, I believe V8 also used not to optimize functions using `try/except`, not sure if that's changed). That means pathological code will run no faster on the fast runtime than on a standard interpreter, but it'll still run. And non-pathological code will run significantly faster.
  - RobAley 13y ago
    For what its worth, HHMV does support eval. Other previous compilers in the HipHop range didn't.
  - elgenie 13y ago
    HPHPc, the static compilation version of the runtime, didn't support eval, because eval is not static :) With the JIT compiler and VM, the runtime now support eval and other more dynamic PHP features: https://github.com/facebook/hiphop-php/blob/master/hphp/test/quick/eval.php https://github.com/facebook/hiphop-php/blob/master/hphp/test...
  - kmavm 13y ago
    Hey, HHVM alum here. The outright language gaps to 5.4 are few and fairly obscure these days, in my opinion. Most practical problems are due to missing or slightly misbehaving extension functions, rather than the core language. You can write programs that produce different output from php.net if, e.g., they depend on the order that destructors are called when killing lots of objects at once, but you can also write programs that differ across minor revisions of php.net. In the absence of a standard, much like pre-standardization C, "PHP" is anything that runs useful PHP programs. We think HHVM qualifies. HHVM lets you do eval(), and we try to do a decent job of running it fast. We do actually jit eval'ed code, though if you're running in whole-program optimization mode the presence of eval() will prevent lots of compile-time class hierarchy analysis based optimizations from working. Yes, yes, we should be optimistic and deoptimize when we're wrong, it's just easier said than done :). Facebook disallows eval() in production code for reasons you can probably imagine.
fosap 13y ago
I don't see the point of HH. There are valid reasons to use php. IMO they are: A existing codebase and the fact it is installed everywhere. But HH is neither installed everywhere nor will the old codebase be compatible. Why not use a proper language right from the start? There are tons of alternatives that do not suffer from the shortcomings hh tries to fix.
- deleted 13y ago
  [deleted]
- RobAley 13y ago
  Er, surely the whole point of the article is that they are making it so that more of the existing codebase will run. Their roadmap also includes making it easy to install on Linux and other platforms, so it may make inroads into "everywhere". If they can even achieve the first objective, then people can continue with the normal PHP runtime as usual in most places and switch to HHVM when they need better performance. Also, I find PHP a delight to program in. YMMV.
  - jeffasinger 13y ago
    Newer PHP isn't too bad to program in, so long as everyone who ever will need to write a line of your code is relatively disciplined, and works to an agreed upon standard. However, your average codebase, written for PHP 5.0 or older, touched by many, mostly incompetent people over several years, is usually incredibly painful to work with.
    - debacle 13y ago
      I haven't seen a PHP codebase that didn't run on 5.2 in years. If you don't support 5.2, that means your code is at least eight years old at this point, with no effort at all to upgrade. That's kind of scary. It'd be like captaining the SS Swiss Cheese.
      - andyhmltn 13y ago
        Sadly, I've seen companies that depend (like literally, if it were to fail the company would shut down) on a codebase that is on 5.0 :(
dkhenry 13y ago
The biggest issue I have had with HHVM is that the extensions are totally undocumented ( not like there is much for the Zend engine ). So trying to port over extension to it is a excersize in futility.
- debacle 13y ago
  Right now, I think documentation would be futile and also suffocating. Considering the stability of HHVM and its steward (Facebook), I expect things to break/change.
  - dkhenry 13y ago
    If they want wider adoption they will need to document extensions. There are tons of extensions out there and I would say most non trivial installation use at least a few of them.
    - debacle 13y ago
      I agree, I just don't think it's useful for them _right now_.
debacle 13y ago
I'm really excited that Facebook is stewarding in a new era of PHP. I would love it to see some of these framework maintainers (particularly fabpot and jwage) push their frameworks towards interop with HHVM. The sooner we can abandon the backwards php.internals mentality of "Do things easy the easiest way possible," we'll see a much stronger language.
- jcroll 13y ago
  Maybe HHVM will be like MariaDB and MySQL, HHVM will become the new fork and the current stewardship will be left behind with their troll mailing list. Either way I think HHVM is going to be a huge step forward for the PHP ecosystem, it's going to kick up some dust and we'll see where everything lies when it settles.
johnx123-up 13y ago
Not tried... but there's a way to get CakePHP run in HHVM http://bakery.cakephp.org/articles/lorenzo/2012/01/30/running_cakephp_using_the_facebooks_hiphop_compiler http://bakery.cakephp.org/articles/lorenzo/2012/01/30/runnin...
- josegonzalez 13y ago
  I'm on the Cake Core team. We're moving towards a 3.x release, which will be all PHP 5.4 compatible (namespaces, etc.) so the issue they point out in class loading will be non-existent. We are discussing aliasing the String class to a CakeText class, and then deprecating the String class in a 2.5 release. If we had known this was an issue[1], then it would likely have made it into the recent 2.4 release. Something that would be nice would be to see the method in which they ran the tests, so that we can include their testing into our TravisCI/Jenkins setup. Probably would help other frameworks/packages as well. Will file a bug. EDIT: Bug Filed: https://github.com/facebook/hiphop-php/issues/1054 https://github.com/facebook/hiphop-php/issues/1054 [1]: They could and should have filed a bug. A cursory search of our lighthouse issue tracker does not surface one, though admittedly lighthouse is pretty shit, so it may indeed be there.
rmccue 13y ago
I went to install HHVM to test my own code, but it turns out it's 64-bit only. Kind of sucks.
- q3k 13y ago
  Is there any valid reason to run 32-bit systems in 2013?
  - astrodust 13y ago
    You don't always get to choose your architecture. Sometimes it's dictated by other concerns.
Pxtl 13y ago
phpBB sports zero. Hopefully this will encourage a migration away from that mess and phpBB will end up on the dustbin of history. Please? Pretty-please? Drupal's success is nice. I've run a Drupal site for a hobby project and performance wasn't stellar, so it's nice to know that Drupal might run well on HHVM.
- jcroll 13y ago
  phpBB is being rebuilt using Symfony components
  - astrodust 13y ago
    phpBB, vBulletin, and the rest of them should be loaded up into a rocket and fired into the sun. Would it kill them to get someone to look over the UX of these things? WordPress has a user interface that, while tricky, does make sense. These "bulletin" products show their origins as some high-school kid's project to make a website.
Pxtl 13y ago
So wait, you're telling me that Facebook's PHP interpreter moves fast and breaks things?
- jcroll 13y ago
  No just that HHVM doesn't yet support the entire PHP codebase
programminggeek 13y ago
I don't think the point of HHVM is to run things like phpbb. It is a tool for Facebook to run their own stuff on as fast as possible.
- lacksconfidence 13y ago
  ? This blog post was written by the authors of HHVM, do you know something they do not? EDIT: I should add, the last time i talked with sgolemon she said (half jokingly) that their goal is to replace zend (engine)
oridecon 13y ago
as long as I don't need to login on facebook to use it
ksec 13y ago
I wish there are a similar effort on Ruby VM.
nasalgoat 13y ago
We did some experiments with HHVM and discovered that our heavy reliance on both redis and mongodb meant no HHVM for us - it supports neither of those things. If they could get php.ini support working, I'd be very pleased to leave php-fpm behind.

69 points by anu_gupta 13y ago

So am I right in thinking that HPHPc is around 6x faster than Zend and HHVM so far adds another 40%? i.e. HHVM is currently 8x faster than Zend and still getting faster?

ptarjan 13y ago
It depends what you are running, but you are at the right order of magnitude. Our main measurements are from running facebook.com back when it could run on both HPHPc and PHP 5.2 and then extrapolating from there with any improvements.
masklinn 13y ago
Yes, although that can be considered an odd comparison as technically at this point HHVM is not a PHP implementation (ignoring the incomplete stdlib and autoload bugs) due to things like > CakePHP has a class named String. HHVM does not allow [...] for classes to have names of primitives. and > a method called setValue() that takes two parameters, [...] only one parameter is provided [...] HHVM does not allow this. and > HHVM requires classes that implement interfaces to be compatible with the interfaces they implement. You can argue the HHVM language is a better language than PHP (not a high bar to set), but that makes HHVM not a PHP runtime.
- RobAley 13y ago
  I disagree. Currently there is no standards body that defines what is PHP, and thus the "official" PHP runtime is "simply" another runtime like HHVM (and others) that implements what it considers to be PHP. It's taken as the "defacto" standard simply as it was the first, and still largest supported, PHP implementation. There is currently talk on PHP Internals (as there has been for some time, to be fair), of creating a PHP standards body to dictate the language. The "official" PHP runtime will (probably) then be written to that standard, and any other runtimes can conform to the standard (and be a "PHP runtime" as you define it) or not as they wish.
  - kbenson 13y ago
    If a language developed as a runtime, and no standard has yet been defined for exactly how the language will behave, then that runtime IS the spec. See Perl. In the meantime, if HHVM doesn't conform to some version of the PHP runtime, it doesn't conform to the PHP language (of the same version). The community could change this, either through defining a standard or accepting HHVM as close enough to be considered a PHP dialect, not a different language with similarities.
    - RobAley 13y ago
      > If a language developed as a runtime, and no standard has yet been defined for exactly how the language will behave, then that runtime IS the spec. See Perl. Nope, it simply means that there is no spec.
nolok 13y ago
HHVM doesn't permit quite a few things that regular php allows, and it also turns into outright errors "bad" things that regular php treats as warnings because it thinks it can run despite it. I also don't think it supports eval(), although it may have changed since the last time I read about it. When you remove the "I don't know, maybe, maybe not" part, you can make you code a lot more efficient. (not making a judgment call here, just clearing things up on how it is possible to be that much faster)
- masklinn 13y ago
  > (not making a judgment call here, just clearing things up on how it is possible to be that much faster) It's probably possible to be that much faster (on average and in good cases) even without throwing out huge swathes of the language. See: javascript runtimes, they don't throw out the parts which bother them but they do deoptimize (or not optimize in the first place) code making use of specific constructs (e.g. `eval` or `with`, I believe V8 also used not to optimize functions using `try/except`, not sure if that's changed). That means pathological code will run no faster on the fast runtime than on a standard interpreter, but it'll still run. And non-pathological code will run significantly faster.
- RobAley 13y ago
  For what its worth, HHMV does support eval. Other previous compilers in the HipHop range didn't.
- elgenie 13y ago
  HPHPc, the static compilation version of the runtime, didn't support eval, because eval is not static :) With the JIT compiler and VM, the runtime now support eval and other more dynamic PHP features: https://github.com/facebook/hiphop-php/blob/master/hphp/test/quick/eval.php https://github.com/facebook/hiphop-php/blob/master/hphp/test...
- kmavm 13y ago
  Hey, HHVM alum here. The outright language gaps to 5.4 are few and fairly obscure these days, in my opinion. Most practical problems are due to missing or slightly misbehaving extension functions, rather than the core language. You can write programs that produce different output from php.net if, e.g., they depend on the order that destructors are called when killing lots of objects at once, but you can also write programs that differ across minor revisions of php.net. In the absence of a standard, much like pre-standardization C, "PHP" is anything that runs useful PHP programs. We think HHVM qualifies. HHVM lets you do eval(), and we try to do a decent job of running it fast. We do actually jit eval'ed code, though if you're running in whole-program optimization mode the presence of eval() will prevent lots of compile-time class hierarchy analysis based optimizations from working. Yes, yes, we should be optimistic and deoptimize when we're wrong, it's just easier said than done :). Facebook disallows eval() in production code for reasons you can probably imagine.

fosap 13y ago

I don't see the point of HH. There are valid reasons to use php. IMO they are: A existing codebase and the fact it is installed everywhere. But HH is neither installed everywhere nor will the old codebase be compatible. Why not use a proper language right from the start? There are tons of alternatives that do not suffer from the shortcomings hh tries to fix.

deleted 13y ago
[deleted]
RobAley 13y ago
Er, surely the whole point of the article is that they are making it so that more of the existing codebase will run. Their roadmap also includes making it easy to install on Linux and other platforms, so it may make inroads into "everywhere". If they can even achieve the first objective, then people can continue with the normal PHP runtime as usual in most places and switch to HHVM when they need better performance. Also, I find PHP a delight to program in. YMMV.
- jeffasinger 13y ago
  Newer PHP isn't too bad to program in, so long as everyone who ever will need to write a line of your code is relatively disciplined, and works to an agreed upon standard. However, your average codebase, written for PHP 5.0 or older, touched by many, mostly incompetent people over several years, is usually incredibly painful to work with.
  - debacle 13y ago
    I haven't seen a PHP codebase that didn't run on 5.2 in years. If you don't support 5.2, that means your code is at least eight years old at this point, with no effort at all to upgrade. That's kind of scary. It'd be like captaining the SS Swiss Cheese.
    - andyhmltn 13y ago
      Sadly, I've seen companies that depend (like literally, if it were to fail the company would shut down) on a codebase that is on 5.0 :(

dkhenry 13y ago

The biggest issue I have had with HHVM is that the extensions are totally undocumented ( not like there is much for the Zend engine ). So trying to port over extension to it is a excersize in futility.

debacle 13y ago
Right now, I think documentation would be futile and also suffocating. Considering the stability of HHVM and its steward (Facebook), I expect things to break/change.
- dkhenry 13y ago
  If they want wider adoption they will need to document extensions. There are tons of extensions out there and I would say most non trivial installation use at least a few of them.
  - debacle 13y ago
    I agree, I just don't think it's useful for them _right now_.

debacle 13y ago

I'm really excited that Facebook is stewarding in a new era of PHP. I would love it to see some of these framework maintainers (particularly fabpot and jwage) push their frameworks towards interop with HHVM. The sooner we can abandon the backwards php.internals mentality of "Do things easy the easiest way possible," we'll see a much stronger language.

jcroll 13y ago
Maybe HHVM will be like MariaDB and MySQL, HHVM will become the new fork and the current stewardship will be left behind with their troll mailing list. Either way I think HHVM is going to be a huge step forward for the PHP ecosystem, it's going to kick up some dust and we'll see where everything lies when it settles.

johnx123-up 13y ago

Not tried... but there's a way to get CakePHP run in HHVM http://bakery.cakephp.org/articles/lorenzo/2012/01/30/running_cakephp_using_the_facebooks_hiphop_compiler http://bakery.cakephp.org/articles/lorenzo/2012/01/30/runnin...

josegonzalez 13y ago
I'm on the Cake Core team. We're moving towards a 3.x release, which will be all PHP 5.4 compatible (namespaces, etc.) so the issue they point out in class loading will be non-existent. We are discussing aliasing the String class to a CakeText class, and then deprecating the String class in a 2.5 release. If we had known this was an issue[1], then it would likely have made it into the recent 2.4 release. Something that would be nice would be to see the method in which they ran the tests, so that we can include their testing into our TravisCI/Jenkins setup. Probably would help other frameworks/packages as well. Will file a bug. EDIT: Bug Filed: https://github.com/facebook/hiphop-php/issues/1054 https://github.com/facebook/hiphop-php/issues/1054 [1]: They could and should have filed a bug. A cursory search of our lighthouse issue tracker does not surface one, though admittedly lighthouse is pretty shit, so it may indeed be there.

rmccue 13y ago

I went to install HHVM to test my own code, but it turns out it's 64-bit only. Kind of sucks.

q3k 13y ago
Is there any valid reason to run 32-bit systems in 2013?
- astrodust 13y ago
  You don't always get to choose your architecture. Sometimes it's dictated by other concerns.

Pxtl 13y ago

phpBB sports zero. Hopefully this will encourage a migration away from that mess and phpBB will end up on the dustbin of history. Please? Pretty-please? Drupal's success is nice. I've run a Drupal site for a hobby project and performance wasn't stellar, so it's nice to know that Drupal might run well on HHVM.

jcroll 13y ago
phpBB is being rebuilt using Symfony components
- astrodust 13y ago
  phpBB, vBulletin, and the rest of them should be loaded up into a rocket and fired into the sun. Would it kill them to get someone to look over the UX of these things? WordPress has a user interface that, while tricky, does make sense. These "bulletin" products show their origins as some high-school kid's project to make a website.

Pxtl 13y ago

So wait, you're telling me that Facebook's PHP interpreter moves fast and breaks things?

jcroll 13y ago
No just that HHVM doesn't yet support the entire PHP codebase

programminggeek 13y ago

I don't think the point of HHVM is to run things like phpbb. It is a tool for Facebook to run their own stuff on as fast as possible.

lacksconfidence 13y ago
? This blog post was written by the authors of HHVM, do you know something they do not? EDIT: I should add, the last time i talked with sgolemon she said (half jokingly) that their goal is to replace zend (engine)

oridecon 13y ago

as long as I don't need to login on facebook to use it

ksec 13y ago

I wish there are a similar effort on Ruby VM.

nasalgoat 13y ago

We did some experiments with HHVM and discovered that our heavy reliance on both redis and mongodb meant no HHVM for us - it supports neither of those things. If they could get php.ini support working, I'd be very pleased to leave php-fpm behind.