The latest techempower benchmarks show HHVM got better performance than PHP native.
http://www.techempower.com/benchmarks/
Is it possible introduce HHVM into PHP kernel tree?
Or just let HHVM as the primary solution for PHP ?
more detail:
http://www.hhvm.com
—————————
zhifeng hu
The latest techempower benchmarks show HHVM got better performance than
PHP native.http://www.techempower.com/benchmarks/
Is it possible introduce HHVM into PHP kernel tree?
Or just let HHVM as the primary solution for PHP ?
more detail:
http://www.hhvm.com
While it is very appealing there are many reasons to do not even consider
it as this stage:
. CLA and only controlled by one single company. We had the single company
control of our engine in the past, it did UA no good.
. barely portable, relies on gcc only
. will reduce even more the amount of contributors able to participate in
the engine development (due to technical, legal or related reasons.
Please keep in mind that this is my personal take on hhvm, not "our" take
as the php dev team.
Cheers,
Pierre
:
. CLA and only controlled by one single company. We had the single
company control of our engine in the past, it did UA no good.
"It did us no good.". I blame shaky typing and android autocorrect :)
Thanks Pierre Joye, You answer is very impressive.
We use PHP, We like PHP, we want it got better and better.
If we can learn from the other open source friend, we can move forward even faster.
The VM and JIT of HHVM were very funny things.
It make PHP more looks like JVM , a more comprehensive platform.
:
. CLA and only controlled by one single company. We had the single company control of our engine in the past, it did UA no good.
"It did us no good.". I blame shaky typing and android autocorrect :)
While it is very appealing there are many reasons to do not even consider
it as this stage:. CLA and only controlled by one single company. We had the single company
control of our engine in the past, it did UA no good.. barely portable, relies on gcc only
. will reduce even more the amount of contributors able to participate in
the engine development (due to technical, legal or related reasons.
It's my understanding that HHVM is incomplete, as well. Does HHVM
implement the full basic functionality of PHP? Are there still things
which don't work for performance reasons?
--
Andrea Faulds
http://ajf.me/
Andrea Faulds wrote (on 03/01/2014):
While it is very appealing there are many reasons to do not even
consider
it as this stage:. CLA and only controlled by one single company. We had the single
company
control of our engine in the past, it did UA no good.. barely portable, relies on gcc only
. will reduce even more the amount of contributors able to
participate in
the engine development (due to technical, legal or related reasons.It's my understanding that HHVM is incomplete, as well. Does HHVM
implement the full basic functionality of PHP? Are there still things
which don't work for performance reasons?
It occurs to me that an interesting direction to consider would be
moving towards having a PHP language specification, rather than a single
reference implementation. Then both the Zend Engine (as distributed by
PHP.net) and HHVM could be implementations of that language
specification, with documented limitations / deviations.
Such a specification might also be useful in other ways - for instance,
cross-checking with unit tests and documentation, and establishing clear
baselines when discussing RFCs and maintaining (or not) compatibility
between releases.
Obviously, though, this would require the folks in charge of both
implementations to be interested enough in the project to spend time on it.
Just a thought...
Rowan Collins
[IMSoP]
It occurs to me that an interesting direction to consider would be
moving towards having a PHP language specification, rather than a single
reference implementation. Then both the Zend Engine (as distributed by
PHP.net) and HHVM could be implementations of that language
specification, with documented limitations / deviations.Such a specification might also be useful in other ways - for instance,
cross-checking with unit tests and documentation, and establishing clear
baselines when discussing RFCs and maintaining (or not) compatibility
between releases.Obviously, though, this would require the folks in charge of both
implementations to be interested enough in the project to spend time on it.Just a thought...
It's something I'd definitely like to see, and is perhaps something the
long-awaited PHP 6 could have. One of PHP's big problems is the fact
that there is no real specification whatsoever, only the single Zend
implementation. Of course, this presents a problem in specifying PHP's
behaviour, as the result would likely be "do exactly what the Zend
engine does". Perhaps we'd discover things in Zend which don't work the
way they're supposed to, mind.
--
Andrea Faulds
http://ajf.me/
It occurs to me that an interesting direction to consider would be
moving towards having a PHP language specification, rather than a single
reference implementation. Then both the Zend Engine (as distributed by
PHP.net) and HHVM could be implementations of that language
specification, with documented limitations / deviations.Such a specification might also be useful in other ways - for instance,
cross-checking with unit tests and documentation, and establishing clear
baselines when discussing RFCs and maintaining (or not) compatibility
between releases.Obviously, though, this would require the folks in charge of both
implementations to be interested enough in the project to spend time on
it.Just a thought...
It's something I'd definitely like to see, and is perhaps something the
long-awaited PHP 6 could have. One of PHP's big problems is the fact that
there is no real specification whatsoever, only the single Zend
implementation. Of course, this presents a problem in specifying PHP's
behaviour, as the result would likely be "do exactly what the Zend engine
does". Perhaps we'd discover things in Zend which don't work the way
they're supposed to, mind.
I'd personally like to see a PHP language specification as well. With a
spec in mind, it would be much easier to create more implementations and
competition can be quite healthy for a product. I'm not going to pretend
that a spec alone would make PHP better as a whole; it would also require a
lot of work that initially doesn't help anyone. In the long-term though, I
think it would help PHP and that's why I'd support it.
It's my understanding that HHVM is incomplete, as well. Does HHVM implement
the full basic functionality of PHP? Are there still things which don't work
for performance reasons?
Syntax: Yes, HHVM is an equivalent engine.*
Runtime Library: This is the big gap. PHP has a bunch of bundled
extensions and a massive library of PECL extensions. Since the
extension API is very different, each extension has to be
reimplemented, and not all of them have been.
-Sara
- Actually HHVM hasn't finished finally yet, but that's very new in
PHP. Also, there are a couple small areas where HHVM intentionally
differs from PHP.
If I may mention, HHVM doesn’t even work properly on all platforms so far; but PHP does. That’s one big bummer to consider.
Am Fr. Jan. 03 2014 19:50:01 schrieb Sara Golemon:
It's my understanding that HHVM is incomplete, as well. Does HHVM implement
the full basic functionality of PHP? Are there still things which don't work
for performance reasons?Syntax: Yes, HHVM is an equivalent engine.*
Runtime Library: This is the big gap. PHP has a bunch of bundled
extensions and a massive library of PECL extensions. Since the
extension API is very different, each extension has to be
reimplemented, and not all of them have been.-Sara
- Actually HHVM hasn't finished finally yet, but that's very new in
PHP. Also, there are a couple small areas where HHVM intentionally
differs from PHP.
It's my understanding that HHVM is incomplete, as well. Does HHVM
implement
the full basic functionality of PHP? Are there still things which don't
work
for performance reasons?Syntax: Yes, HHVM is an equivalent engine.*
Runtime Library: This is the big gap. PHP has a bunch of bundled
extensions and a massive library of PECL extensions. Since the
extension API is very different, each extension has to be
reimplemented, and not all of them have been.
Unless some commits have been merged that I am not aware of, you still
can't use callable type-hints (https://github.com/facebook/hhvm/issues/1363).
While I can't imagine it is difficult for HHVM to finish support for the
callable type-hint, it does show an example of a major compatibility issue
as your code will not run at all.
My opinion: it's not stable enough... yet.
Syntax: Yes, HHVM is an equivalent engine.*
Runtime Library: This is the big gap. PHP has a bunch of bundled
extensions and a massive library of PECL extensions. Since the
extension API is very different, each extension has to be
reimplemented, and not all of them have been.Unless some commits have been merged that I am not aware of, you still can't
use callable type-hints (https://github.com/facebook/hhvm/issues/1363).
While I can't imagine it is difficult for HHVM to finish support for the
callable type-hint, it does show an example of a major compatibility issue
as your code will not run at all.My opinion: it's not stable enough... yet.
For the record, I agree. I think this whole thread is at least a year
early, if not two. With all due respect to the OP, calling for a
merge of PHP and HHVM at this time shows a lack of understanding about
the full breadth and reach of PHP, and the fact that HHVM is a
complete reimplementation of the language and runtime.
-Sara
P.S. - FWIW, the fix for that bug (hate to play semantics, but it's a
bug, not a parity gap) is on its way out. Basically just been delayed
by the holidays.
Unless some commits have been merged that I am not aware of, you still can't
use callable type-hints (https://github.com/facebook/hhvm/issues/1363).
While I can't imagine it is difficult for HHVM to finish support for the
callable type-hint, it does show an example of a major compatibility issue
as your code will not run at all.P.S. - FWIW, the fix for that bug (hate to play semantics, but it's a
bug, not a parity gap) is on its way out. Basically just been delayed
by the holidays.
Scratch that, the fix was committed last week. Drew just forgot to
add "Closes #1363" to his commit message.
I would be very happy with this decision, but I have some concerns too.
Will detail each one
- CLA
As Pierre mentioned
- Existing extension (read as PECL) support
There're a lot of existing PECL extensions, that are tied to ZE.
While it would be a collective effort to migrate existing ones to HHVM, it
would be a huge effort for everyone, not only core.
I foresee a lot of discrepancies during this transition. Like possible BC
breaks, such as some I've seen with thread (HHVM) support compared to
pthreads (PHP).
If HHVM was able to provide a wrapper support for ZE API, that would
simplify a lot of work around existing PECL extensions and 3rd party
contributors.
- Code organization
After some time around php internals, you get used to its structure and
where everything is implemented/organized.
I am trying to regularly contribute to HHVM and keep my tools compatible. I
find myself relying on search most of the time to find where things are. =
It may be my lack of experience, but that's what I personally feel.
- Compatibility
A lot of effort is needed to get everything compatible, up and running.
This requires more and more effort.
Cheers,
Unless some commits have been merged that I am not aware of, you still
can't
use callable type-hints (https://github.com/facebook/hhvm/issues/1363).
While I can't imagine it is difficult for HHVM to finish support for the
callable type-hint, it does show an example of a major compatibility
issue
as your code will not run at all.P.S. - FWIW, the fix for that bug (hate to play semantics, but it's a
bug, not a parity gap) is on its way out. Basically just been delayed
by the holidays.Scratch that, the fix was committed last week. Drew just forgot to
add "Closes #1363" to his commit message.--
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Hi!
Syntax: Yes, HHVM is an equivalent engine.*
Runtime Library: This is the big gap. PHP has a bunch of bundled
From what I understand, there's also a certain gap in semantics - while
hhvm accepts PHP syntax (or most of it), it doesn't do the same with it
as PHP does. With the result that if you're going to run real life app
on it, there are chances that it wouldn't work unless it was developed
against hhvm from the start.
Building hhvm is right now not for the faint of heart either, at least
compared to how easy it is to build PHP on any reasonable supported
platform. E.g., for centos you need to manually rebuild whole gcc
toolchain, and the same for mac os x 10.8 (earlier versions not even
supported).
Also, while I greatly appreciate the efforts of folks at Facebook to
make the engine available and working, I am still not sure
organizationally how important it is for Facebook that this engine is
running anything but Facebook, or, even wider, everything (PHP) that is
not Facebook. I.e. it may be important for some people within Facebook
as their project, but organizationally it is a project to run Facebook,
isn't it? Which implies some decisions when they need to be made, and
corners cut when they need to be cut, etc. I understand hhvm works
really good for Facebook, and may even work fine with some lucky PHP
apps, but the last 10% is the hardest. Does it make sense to make the
investment? I of course have no idea what Facebook as an org answers to
this question...
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas Malyshev smalyshev@sugarcrm.com schrieb:
Hi!
Syntax: Yes, HHVM is an equivalent engine.*
Runtime Library: This is the big gap. PHP has a bunch of bundledFrom what I understand, there's also a certain gap in semantics - while
hhvm accepts PHP syntax (or most of it), it doesn't do the same with it
as PHP does. With the result that if you're going to run real life app
on it, there are chances that it wouldn't work unless it was developed
against hhvm from the start.
Sara pointed out that there is an intentional gap in the semantics.
Also, while I greatly appreciate the efforts of folks at Facebook to
make the engine available and working, I am still not sure
organizationally how important it is for Facebook that this engine is
running anything but Facebook, or, even wider, everything (PHP) that is
not Facebook. I.e. it may be important for some people within Facebook
as their project, but organizationally it is a project to run Facebook,
isn't it? Which implies some decisions when they need to be made, and
corners cut when they need to be cut, etc. I understand hhvm works
really good for Facebook, and may even work fine with some lucky PHP
apps, but the last 10% is the hardest. Does it make sense to make the
investment? I of course have no idea what Facebook as an org answers to
this question...
I recently read on their blog that they are trying to put a lot of effort
into making HHVM compatible with widely used frameworks. So it seems that
there is an effort in making it run good for everyone than just for FB.
Nevertheless we all agree that HHVM and php-src are separate projects with
different goals at the moment. However the community would benefit from a
formal language standard. I am not sure how python does it but they have
a healthy community of language reimplementations (pypy, jython, etc) and
I think the PHP community can learn from that and help people choosing
which runtime fits best for their needs.