i.e. HHVM is currently 8x faster than Zend and still getting faster?
i.e. HHVM is currently 8x faster than Zend and still getting faster?
> 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.
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.
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.
Nope, it simply means that there is no spec.
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)
https://github.com/facebook/hiphop-php/blob/master/hphp/test...
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.
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.