HHVM is fast – too bad it doesn’t run my code | Hacker News Reader

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

hhvm.com

69 pointsanu_gupta59 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.

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.

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.

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.

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 :(

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

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.

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.

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.

A small fragment of the PHP community is doing things better than the rest, but it still seems like there's a lot of untamed wilderness out there.

StackOverflow is filled with people who've suffered badly at the hands of w3schools and various atrocious YouTube tutorials which perpetuate the absolute worst practices from the 1990s.

Perhaps the problem isn't having good resources so much as getting rid of the bad ones.

PHP still has a long, long way to go. The rampant infighting in the core team, the completely incoherent API and language design, the lack of innovation on core libraries, none of this is very encouraging.

You know, i keep hearing how most php developers are horrible, but it's not what i see at all. When you go the php events you meet really clever people who've programmed in a ton of languages in the past.

I think the thing that php needs right now is a 'good parts' book and an accompanying movement. Like javascript the way it was used around 2000 was embarassing, but that is simply no longer the way you use it.

There's a lot of encouraging things such as the list I just mentioned and the subject of this article HHVM. If you want to bury your head in the sand and continue to hum the tired "PHP is a fractal of bad design" chorus go ahead but please excuse those of us doing modern PHP development for really enjoying it, and being quite excited about it.

What I don't understand is what there is to enjoy. Nobody ever communicates this effectively.

PHP is a greasy pig at the best of times. You can kit it out all you want and it still isn't a first-class scripting language, it's only a web-site scripting system, and the way it's designed it will only ever be a web-site scripting system.

The only advantage to PHP has been, in historical terms, its ubiquity. Most if not all hosts support it. However, this is a blessing in disguise. Most of these hosts only support PHP 5.2 or maybe PHP 5.3, usually trailing two or three releases behind what's current.

For those who write WordPress-like "download, install on server" packages, sure, PHP is an effective delivery platform, but I'd hardly call it a great programming language.

Maybe I'm missing something, though, but I've never seen anything about PHP that's made me go "Yeah, I wish I had that in X language", but it's often the case in reverse.

I've done a lot of Python, Ruby, Perl, C++, Objective-C, and JavaScript and each of these has something interesting about them, a style that meshes well with their design philosophy.

What does PHP bring to the table that means choosing PHP is a good idea as opposed to just doing PHP by default?

You seem to have an axe to grind, I will let you find someone else with whom to grind it.

Seemed reasonable enough to me...

That's not really an answer.

What is there to enjoy about PHP? It's an honest question.

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.

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.

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.

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

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.

And the truth comes out.

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

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

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

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

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.

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.

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.

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?

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.

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.

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.

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

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)

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

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.

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

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

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.

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

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

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

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.

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.

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.

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.

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

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.

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.

phpBB is being rebuilt using Symfony components

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.

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

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

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

I wish there are a similar effort on Ruby VM.

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

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.

? 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)

Reply on news.ycombinator.com