# Is it possible introduce HHVM into PHP kernel tree? - Thread: https://externals.io/message/70979 - Original archive: https://news-web.php.net/php.internals/70979 - Started by zhifeng hu on 2014-01-03T06:05:16+00:00 - Messages: 16 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #70979 — zhifeng hu — 2014-01-03T06:05:16+00:00 URL: https://externals.io/message/70979#70979 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 --- ## #70980 — Pierre Joye — 2014-01-03T06:20:39+00:00 URL: https://externals.io/message/70979#70980 · In reply to: #70979 > > 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 --- ## #70981 — Pierre Joye — 2014-01-03T06:38:45+00:00 URL: https://externals.io/message/70979#70981 · In reply to: #70980 : > > . 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 :) --- ## #70982 — zhifeng hu — 2014-01-03T06:47:04+00:00 URL: https://externals.io/message/70979#70982 · In reply to: #70981 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. > > > : > > […] > > "It did us no good.". I blame shaky typing and android autocorrect :) --- ## #70983 — Andrea Faulds — 2014-01-03T16:18:58+00:00 URL: https://externals.io/message/70979#70983 · In reply to: #70980 > > 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/ --- ## #70984 — Rowan Collins — 2014-01-03T16:31:58+00:00 URL: https://externals.io/message/70979#70984 · In reply to: #70983 Andrea Faulds wrote (on 03/01/2014): > > > > > […] > > 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] --- ## #70985 — Andrea Faulds — 2014-01-03T16:36:38+00:00 URL: https://externals.io/message/70979#70985 · In reply to: #70984 > > 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/ --- ## #70986 — Sara Golemon — 2014-01-03T18:50:01+00:00 URL: https://externals.io/message/70979#70986 · In reply to: #70983 > 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. --- ## #70987 — Kevin Ingwersen — 2014-01-03T18:55:17+00:00 URL: https://externals.io/message/70979#70987 · In reply to: #70986 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: > > […] > 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. --- ## #70988 — Levi Morrison — 2014-01-03T18:58:03+00:00 URL: https://externals.io/message/70979#70988 · In reply to: #70986 > > […] > implement > > […] > work > > […] > 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. --- ## #70989 — Levi Morrison — 2014-01-03T19:11:24+00:00 URL: https://externals.io/message/70979#70989 · In reply to: #70985 > > > > […] > > 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. --- ## #70990 — Sara Golemon — 2014-01-03T19:25:54+00:00 URL: https://externals.io/message/70979#70990 · In reply to: #70988 > > […] > > 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. --- ## #70991 — Sara Golemon — 2014-01-03T19:30:57+00:00 URL: https://externals.io/message/70979#70991 · In reply to: #70990 > > […] > 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. https://github.com/facebook/hhvm/commit/06f4711821b1db0a2ef9ac56ec2186bcb0049651#diff-ede14f13ebae67ee268413ed558d1acf --- ## #70992 — Stas Malyshev — 2014-01-03T19:41:19+00:00 URL: https://externals.io/message/70979#70992 · In reply to: #70986 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 --- ## #70993 — guilhermeblanco@gmail.com — 2014-01-03T19:43:59+00:00 URL: https://externals.io/message/70979#70993 · In reply to: #70991 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, > > […] > can't > > […] > issue > > […] > Scratch that, the fix was committed last week. Drew just forgot to > add "Closes #1363" to his commit message. > > > https://github.com/facebook/hhvm/commit/06f4711821b1db0a2ef9ac56ec2186bcb0049651#diff-ede14f13ebae67ee268413ed558d1acf > > -- > > > > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #70994 — David Soria Parra — 2014-01-03T19:55:56+00:00 URL: https://externals.io/message/70979#70994 · In reply to: #70992 Stas Malyshev schrieb: > Hi! > > > […] > > 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. 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.