6 ms·

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 getti

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

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