Hacker News

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

• 60 Comments
• 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.

  By fosap 12 years 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.

  By RobAley 12 years 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.

  By jeffasinger 12 years 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.

  By debacle 12 years 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 :(

  By andyhmltn 12 years ago

• If you find "PHP a delight" you'd probably love a language with a sane design even more.

  By astrodust 12 years ago

• As someone who did make such a change, I agree with this. I'm assuming the parent did not intend it as trolling, as I don't.

  By mildtrepidation 12 years ago

• I wish there were more stories of people who've gone "post-PHP", talking about their experiences.
  "PHP developers", by which I mean developers that know PHP and PHP only, are the first to throw a fit when their language is criticized.
  This is especially awkward as most PHP developers don't even observe best practices for developing with PHP, insisting on using obsolete versions, write hazardously bad SQL queries with so much moaning about how it's not a big deal, and get absolutely irate when you suggest they use an application platform instead of rolling everything by hand.
  There's something to be said for using a language where the community encourages people do to it properly, and everyone's trying to make an effort to move forward together.

  By astrodust 12 years ago

• The PHP community is moving forward and trying to do things the right way. Checkout http://www.phptherightway.com/
  Also checkout the Symfony components and how many large open source PHP projects are using them:
  * Symfony Framework
  * Drupal
  * Laravel
  * Silex
  * phpBB
  * Guzzle
  Then there's Composer (which also uses Symfony components) and PHP-FIG. The list goes on.
  What you need is more modern PHP developers advocating on boards like HN how good PHP has become, not how much better other ecosystems are than what PHP was five years ago.

  By jcroll 12 years ago

• The shortcomings it tries to fix is the speed of the execution of the language, something PHP already gets better than other dynamically typed languages such as ruby. There's lots of good reasons to pick PHP as the language to develop A web application on and with HHVM in the mix the reasons will be greater still. PHP is a real programming language, if your greatest knock against it is the inconsistent order of function parameters then I don't really think you do have a knock against it unless of course you want to take the same swipe against C.

  By jcroll 12 years ago

• For projects the size of Facebook there's a lot of risk and not a lot of reward in rewriting the whole site. Instead of retraining all their developers to write in a new language and taking the time to stop all current development and begin the rewrite, they were able to have a few guys go off and make the current infrastructure faster.
  If you have a sizable existing PHP codebase time and money would be better spent making it run on HHVM than rewriting it in another language, especially if you have an existing army of PHP developers.

  By maximilianburke 12 years ago

• Don't forget the fact that PHP devs are relatively cheap. Especially compared to people capable and willing to learn your brand new homegrown language.

  By michh 12 years ago

• Python, Ruby, C#, and JavaScript are "homegrown" now?

  By astrodust 12 years ago

• No but people were suggesting that if they're writing their own VM, they might as well design a better programming language to use on it.

  By michh 12 years ago

• And the truth comes out.

  By twistedpair 12 years ago

• [deleted]

  By

  A PHP Error was encountered

  Severity: Notice

  Message: Undefined property: stdClass::$user

  Filename: views/hn.php

  Line Number: 101

  12 years ago

• What are valid reasons to use PHP? Like, you don't care about your code or you have no availability SLA?

  By AsymetricCom 12 years ago

• It's a great language for quick prototyping or doing sysadmin tasks (i would choose php over any shell script language any day). I also see no evidence that php apps in practice are any less reliable. Php is in fact probably more reliable because it doesn't give you dangerous stuff like multi-threading and because its very forgiving of errors (it doesn't consider an error a good reason to stop running code).

  By Joeri 12 years ago

• Although it's not a feature that appeals to everyone, modern PHP (5.4+) has nearly any sort of syntactic/structural feature one would want in a programming language, except enumerations[0]. After using them in Scala, traits are also a nice plus to have in PHP. I do use PHP less than I used to, opting for Python more as it has more uses than PHP does (PHP can be used with GTK or CLI, but no thanks) outside of the web.
  There are also quite a few good libraries and frameworks out there for PHP, although they're hard to find if you're not already experienced in PHP and can filter out the horrible ones by reading their code. Compared to Python, the task of finding quality code is generally harder from all the existing stuff out there holding on to bad hacks from PHP 5.2 and before (as well as long time PHP developers abusing such bad hacks out of habit).
  Also, in PHP, trying to do anything event related with server to client notifications[1] comes down being an ugly hack[2] unless you want to use some third party PHP extensions like libevent[3] or offload to another language/service you could have just written everything in to begin with. PHP is just not built for anything unconventional like that and makes your life a headache if you ever find you need it at some point. Screwing with all of that is way more of a pain than just using Python with Tornado or Twisted, using Node.js or something like Play 2.0 with Scala. For what it's worth, the MySQLi native driver/api supports non-blocking async queries to the DB at least now and the native PostgreSQL API does as well (albeit the PgSQL API is not Object Oriented and I resorted to wrapping it a class that mimicked the MySQLi Object Oriented API for consistency).
  [0] http://marc.info/?t=132988607800003&r=1&w=3 (lots of futile rants about it here). Basically comes down someone rejecting enum because they claim it's "redundant" (though PHP has plenty of previously accepted redundancies) when you can fake them with classes (which is not true as you cannot use them in a switch [without faking with toString()] and cannot use them without instantiating an object). The other excuse is it would introduce "strict typing creep" to PHP, which is silly, since you can already type hint on functions by including a the class or array type in each parameter (and will even throw an error if using the incorrect type). Excuses are not surprising though, given the news the past month of how toxic the core developer mailing list is for PHP.
  [1] http://ajaxpatterns.org/HTTP_Streaming
  [2] To implement in PHP without event listeners, you have to use some sketchy third party php based http servers instead of fcgi+fpm for those parts or fake it with an infinite loop + sleep and use nginx + http push stream (http://wiki.nginx.org/HttpPushStreamModule)
  [3] http://php.net/manual/en/book.libevent.php

  By yareally 12 years ago

• If you want to use libevent/libev without coding the glue yourself, you can use React PHP (http://reactphp.org/), which supports timers, websocket/WAMP, ZeroMQ, HTTP (but not SSL), DNS, Redis (Predis async), and plain sockets.
  I'm using it for a project I'm working on because PHP has the only supported cpanel client library, and I don't want to maintain my own bindings for cpanel. I've found that React works quite well for processing queues in PHP and notifying the client via websocket when events occur.
  I did introduce a Play/Akka scheduling daemon instead of hand rolling that in React, which simplifies the PHP worker greatly as it only needs to process jobs submitted over ZMQ, not read the database and update an internal list of jobs.
  I would love to try porting this application to HHVM when there is support for a libev/libevent/libuv extension that is compatible with React.
  I was not aware of the async database library in PHP, though it doesn't seem to be integrated with the React main loop implementation and might be some work to get it working. Are you aware of the difference between Mysqli and Mysqlnd and do you know when I should use either on of them. (I use PDO for database access and prefer the OO api it provides.)

  By tmzt 12 years ago

• Hmm, I've heard of React, but have not had a chance to look at it much or use it yet. Looks like it would be better than any of the other alternatives out there though for PHP with a similar feature set. Thanks for the recommendation.
  MySQLnd uses the same API as MySQLi, so the only differences are deciding which to use within php.ini file and ability to use the asynchronous methods in for the MySQLi API in PHP. When MySQLnd originally came out, there was no support for SSL connections with it, but that's been fixed since PHP 5.4 I believe.
  Won't be able to use PDO though if wanting to use the async stuff (unless they have added that). Could probably write a small adapter to wrap one or the other though. MySQLi API design is kind of quirky compared to PDO API, so I generally write a small helper class to make life easier for dealing with prepared statements and binding variables to them.

  By yareally 12 years 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.

  By debacle 12 years 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.

  By jcroll 12 years 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?

  By sambeau 12 years 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.

  By masklinn 12 years 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.

  By RobAley 12 years 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.

  By kbenson 12 years 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.

  By RobAley 12 years 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)

  By nolok 12 years 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...

  By elgenie 12 years 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 kmavm 12 years 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.

  By masklinn 12 years ago

• For what its worth, HHMV does support eval. Other previous compilers in the HipHop range didn't.

  By RobAley 12 years 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.

  By ptarjan 12 years ago

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

  By Pxtl 12 years ago

• No just that HHVM doesn't yet support the entire PHP codebase

  By jcroll 12 years ago

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

  By johnx123-up 12 years 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
  [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.

  By josegonzalez 12 years 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.

  By dkhenry 12 years 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.

  By debacle 12 years 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.

  By dkhenry 12 years ago

• I agree, I just don't think it's useful for them _right now_.

  By debacle 12 years 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.

  By nasalgoat 12 years 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.

  By Pxtl 12 years ago

• phpBB is being rebuilt using Symfony components

  By jcroll 12 years 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.

  By astrodust 12 years ago

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

  By rmccue 12 years ago

• Is there any valid reason to run 32-bit systems in 2013?

  By q3k 12 years ago

• You don't always get to choose your architecture. Sometimes it's dictated by other concerns.

  By astrodust 12 years ago

• I wish there are a similar effort on Ruby VM.

  By ksec 12 years ago

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

  By oridecon 12 years 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.

  By programminggeek 12 years 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)

  By lacksconfidence 12 years ago