Coming Soon in HHVM | Hacker News Reader

Coming Soon in HHVM

hhvm.com

114 pointsjwatzman58 comments

Yay! I'm so excited to use the `async` methods in production with MySQL. The biggest bottleneck for our PHP apps can now have a workaround in some cases, that's brilliant.

> Integration of LLVM as a further optimization step to make the hottest code run even faster on HHVM.

These multistage JITs are absolutely fascinating, I believe Safari is doing something similar with Javascript. Intuitively I would've assumed the overhead of firing up yet another JIT and VM to run it on would make it not worth it, but I guess the instructions currently generated are so far off optimal that it is worth doing.

EDIT: Anyone know of any papers regarding multi-stage JITs that I can check out?

Async MySQL queries have been available to you in PHP since PHP 5.3.0 released in 2009:

    http://php.net/mysqli.poll

If that has been your bottleneck, why haven't you been using them?

The async support you linked, while useful, isn't really the same thing. It requires explicit, manual coordination between different parts of the code that want to fetch data. You're responsible yourself for batching fetches, polling, and running other code until the results are returned.

With Hack's async support, the runtime manages all of this for you. You call "await $query", and then your function is suspended until the data is available. Other code automatically runs until it too hits an await statement -- which might block it on MySQL, memcache, curl, or anything else, with no extra manual coordination needed. The runtime manages it all for you.

http://hhvm.com/blog/7091/async-cooperative-multitasking-for... has some examples for what this looks like with curl -- in the final example, notice how you can just "await" on a bunch of different things and let the runtime worry about coordinating all of them.

^^^ What he said :)

The async stuff in HHVM is far more powerful than the meagre-at-best support for asynchronous operations in the original PHP runtime. In usage, HHVM's will be much more powerful.

LLVM isn't really a VM, it's just a compiler toolkit. And really, the overhead of converting your data structure to LLVM IR is almost certainly trivial compared with the cost of the optimizations it is performing.

LLVM IR is definitionally coding to a virtual machine. It doesn't bear a ton of similarity to the underlying architecture in most cases. gcc's GIMPLE is the same idea. (That it's compiled down to machine code doesn't make what you're working with not-a-virtual-machine.)

Heh, I originally wrote something more pedantic then edited it down. It's definitely a virtual machine insofar as its an abstract computational machine, but it's not in the probably more common definition of "an interpreter, possibly with a JITing compiler on the side, for an abstract computational machine" (though LLVM does have an interpreter, it's not really ever intended to be used for anything).

Multi-stage JITs are indeed fascinating and give some nice wins, but as a "user" (that is, a developer) I find them frustrating at times because they make it more difficult to reason about the performance and behaviour of my code.

Not only a priori, but in terms of testing actual code and designing benchmarks as well - you have to make sure the right sections of code are hot, hitting the right levels, etc. It's extra mental load and work. (and if you're a JS developer, you may have to do this across multiple platforms). And oh, regressions and updates.

I'm not entirely convinced it's all worth it, but so far I'm begrudgingly accepting it.

It is no different than using multiple AOT compilers (for any standardized language) across multiple platforms.

Even the same compiler can behave differently just by changing the target CPU.

Sure, but with most AOT compliers you only get one machine-code version of your code, which is easier to benchmark than worrying about the multiple levels of a JIT.

Actually I think many developers aren't aware of the right tools for this type of job.

JITs are easy to benchmark when tools like Oracle Studio, Java Flight Recorder, dotTrace and so forth are used.

The problem is trying to benchmark them using old style concepts, e.g. outputting time differences to a text file.

Those tools don't exist for all JITed platforms. Hence the problem.

All the major javascript engines are multistage now, not just safari.

Though only Safari (well, JavaScriptCore) is using LLVM (as a fourth tier).

I wonder how long it'll be before HHVM starts driving the PHP project, implicitly or explicitly.

I'm rather disappointed that full, non-experimental xdebug support isn't on this list. I can't think of a more pertinent feature. I like HHVM's development as well as Hack, but without proper remote debugging, it remains rather inaccessible. I would personally love to contribute to getting some of the major frameworks that are not quite 100% compatible up to par but have been deterred in being able to fix bugs in a timely matter because of the lack of debugger support.

It's not on the list since it was released a few versions ago! Try it in the latest stable version, and please file issues on GitHub if you run into problems. There are already a couple of known issues filed there that are being looked into, but at least the PHPStorm developers have told us that it works well enough they are able to work on XDebug+HHVM support in their IDE.

Awesome! I must've missed the announcement (if there was one). I'll definitely be checking it out soon.

It's already there! I've connected Codebug[0] to it, I believe even the latest stable has it running by default!

[0] http://codebugapp.com/

I have recently tried out to run our huge, about 10 years old application using HHVM. Interestingly enough, aside of few 5.6 features it didn't support yet, the process was surprisingly painless.

However, HHVM was generally between 2 and 5 times slower than vanilla PHP at rendering pages. In micro benchmarks it was way ahead, but running the whole application was a very different matter.

I decided to wait until the thing matures a bit more before trying again and then hopefully with more time to investigate the causes of this huge difference in performance.

That's really interesting, as I brought one of our services at my old job over onto HHVM and gained 4 times more performance, I'm really curious what workload you were throwing at it, and I know that the HHVM people would love to take a look at it; performance regressions from PHP to HHVM have been basically nil for me over the past 12 months.

Did you run enough requests to allow the jit to work? some jits require thousands of runs (in this case requests) to warm up.

I would hope ab -c 5 -n 1000 would be enough. I've used -c 5 because the VM wasn't exactly beefy, but that's still quite a few requests.

do you have any profiling information to share? if you could post it as a github issue, we'd be very interested. This sounds unusual.

also, if this is an open source workload, any chance you could submit it to https://github.com/hhvm/oss-performance ? We generally optimize based on those benchmarks, and Facebook itself.

Any sign of official PostgreSQL support?

We just need the Mongo extension (https://github.com/mongodb/mongo-php-driver) to be supported to try HHVM out.

People are having lots of success with https://github.com/mongofill/mongofill-hhvm

Sorry for yet another rant against php, but does anyone else here feels a bit sad that those obviously brilliant people work so hard to improve this language instead of basically any other main one ?

Edit : seems like i wasn't clear. I don't mean sad for the people working on the project ( i'm sure they love what they're doing), i mean sad because as a non-php dev ( but basically everything else dev), i know many "better" languages that would benefit from having those kind of people on board.

Shared nothing. Simple deployment. "Web" focused. Those are PHP's strengths, and why it continues to do well, despite it's huge amount of quirks.

Modern PHP, with Composer, the PSR standards, and the Framework Interoperability Group's efforts is a very different beast to PHP4 or <=PHP5.3. Sure, one can make an argument that a "better" language would be a nicer target for this sort of amazing talent, but that ignores reality: So many things run on PHP, that it's a good idea to fix PHP's issues. HHVM and Hack are doing sp (in parallel with the communities efforts), and I thank them for it,

>despite it's huge amount of quirks.

Besides inconsistent/bad library argument order/naming, and a couple parser related issues that are slowly being fixed (like the "immediately use an array returned from a function" issue fixed in 5.4) I don't see any "huge amount" of quirks.

I do see a lot of bikeshedding, from people who could have found similar BS in most languages in major use.

Yup. The argument order of similar functions being inconsistent is the only thing I run into on a day to day basis. I never remember the order or even names of most functions anyways and with proper tools it's irrelevant. Honestly, I think people like to bust on PHP mainly because it's in vogue and "acceptable" by a lot of ignorant folks. I assume in some circles it gets one brownie points. It's almost as if they're pretending that bad code doesn't exist in the language of their choice, that somehow the choice of language can protect one from others' stupidity and bad code. In the meantime, PHP developers are actually getting things done and the good ones are writing extremely clean code. Like most of the PHP community, I'm extremely glad for the effort going into HHVM which I see as the future of PHP.

Most languages aren't templating languages at first place. PHP was saved because it decided to look like Java,which neither Ruby or Python do,which allows writing these huge codebases like Doctrine or Symfony.

I personnally started coding with Actionscript 3, I wish PHP looked exactly like that,while keeping the scripting and the execution model.

> PHP was saved because it decided to look like Java,which neither Ruby or Python do,which allows writing these huge codebases like Doctrine or Symfony.

What does looking like Java have to do with being able to write huge codebases? Both Python and Ruby have libraries just as big as (or bigger than) Doctrine and Symfony.

> What does looking like Java have to do with being able to write huge codebases? Both Python and Ruby have libraries just as big as (or bigger than) Doctrine and Symfony.

which ones?you didn't name them.

Django and Rails, to name just two open source projects, and I've seen proprietary Python apps with hundreds of thousands of lines of code. You still haven't said how PHP allows you to write bigger codebases than Python or Ruby, and what that has to do with looking like Java.

>Besides inconsistent/bad library argument order/naming

These issues are the least of it's 'quirks'. The most important thing that is wrong with it is the badly or 'un-designed' core of the language. This result of this is that when you are implementing modern programming constructs, you won't be able to implement it in a consistent way (Most of the time the implementers does not care, but even if you do you ill see quickly running out of options.). So the modern features PHP get are often half-baked so that if you try to put it to real use, it ll come to a grinding halt.

Another aspect of this 'un-designed' core is that there will be a big fight over introduction of any 'core-like' feature. And often implementers wont be able to go with one philosophy and is forced to make everyone happy, ending up with very weird behaviors in the implementation.

Another thing is Exceptions. Because the exceptions was not available from the start, only a part of the language uses them. So you cannot rely on exceptions being thrown in a consistent way.

Another important thing is the most people who have been working on the language are hobbists and students with no sort of professional experience, and they end up implementing the features in the most awkward fashion (Eg: Methods on the datetime object mutating it).

One could go on and on and on..http://www.reddit.com/r/lolphp

RE exceptions: in HHVM at least you can change this:

1. set hhvm.error_handling.call_user_handler_on_fatals=true in your ini file 2. throw exceptions from your handler :)

HHVM is the answer to the following conversation:

P1 - "PHP sucks, it's a terrible language with no proper design and no serious person would ever want to use it"

P2 - "But tons of large projects are built on it and people ship with it everyday"

P1 - "So? It's still terrible"

P2 - "What do you think is so terrible?"

P1 - "Oh lots and lots of things, I wouldn't even know where to begin"

P2 - "How about this: let's throw boatloads of cash on it for a while and see where we get."

P1 - "Oh gee, I dunno if..."

P2 - "Boatloads of cash it is.

[edit] After seeing how my comment could be seen as ridiculing HHVM: I'm a PHP dev and I'm loving every second of what they're doing. I think they're right on the money.

I actually appreciate the work that Facebook is doing in this space... it's definitely beneficial to those running PHP codebases that have been around a long time. While I don't like PHP the language, I can understand the utility of it.

That said, I'm appreciating the move to containerization and micro-services more... replacing some pieces with better options becomes far easier when those pieces are smaller. I can prototype in something like node, and move those troublesome bits to something like go or c++ if needed.

This comment is sad. First people complain about problems with PHP. Then when problems are being solved people complain about people fixing them. It honestly looks like PHP is simply in a lose / lose situation with many people. That's the real disappointment in my eyes.

PHP is a lose / lose only to people that are not using it / won't bother learning it. It's the same with Perl. It's not hot nor trendy and that's why many people get so frustrated when they hear about people still using it because there's something "newer and better". Haters gonna hate.

It's simply not viable from a time-investment point of view to throw away tools you know extremely well, are well entrenched, well supported and stable every few years because something new comes along.

PHP is also a fairly new language, so it certainly wouldn't be my first choice if that was my main concern. In fact it isn't for this exact reason.

New language?

1995: PHP, Javascript, Java, Ruby

I think much of the hatred towards PHP fundamentally comes down to the fact that it broke down a lot of barriers to entry in the web development world which allowed for anyone with a basic text editor to patch together CRUD apps. This led to an army of "w3cschools.com developers" referring to themselves as software engineers, which offended many in enterprise Java land.

Knowing how large Facebook's PHP/Hack codebase is/was, rewriting that application would have been a disaster.

Hack is a fantastic language and the work by the HHVM team benefits the PHP ecosystem as a whole.

PHP may have its problems, but many companies use it for its many benefits, mainly the ease of finding developer talent.

> rewriting that application would have been a disaster

Or the best decision ever made by the company.

Based on what? They rewrote the language into another that is largely backwards compatible, fixes PHP's quirks and is insanely fast.

Given the choice of migrating / transpiling an entire codebase or making the underlying interpreter / compiler and language fantastic and speedy, the latter is a big, big win.

What would rewriting the whole thing in, say, Ruby or Python have done beyond limiting the amount of "PHP sucks!" critique they so often get?

Seriously, take a look at Hack. It's very well done.

This is not to diss any particular language but an architectural problem - frontend and backend are very tightly coupled which makes it difficult to develop anything outside this stack. By splitting a humongous (and always growing) homogenous application into smaller services you get smaller failure domains and better interoperability with acquisitions and potential new groundbreaking projects that do not easily fit into the current development model. Again, I have no opinion about HHVM and Hack which are completely orthogonal to the problem at hand.

Can you expound on this? I don't perceive front end and back end being especially more coupled than, say, Node.

The coupling has nothing to do with the language and everything to do with the fact that FB grew organically into this giant monolithic mess of spaghetti. Can you do SOA in PHP? Of course. Does FB do it? Nope. Will this bite them in the long run? I believe so.

I'm sorry but that's extremely condescending of you.

You might as well feel sad that these brilliant people are not "curing cancer" or "eliminating AIDS" or something.

About as condescending as saying it is a waste of time to improve methods for bloodletting to cure disease.

Bloodletting is still used in modern medicine. With the leeches and everything.

As is PHP ;)

PHP has merits relative to other web development tools, like the way the environment for every request starts "clean" and global state has to be explicitly managed. Adding typechecking to PHP with Hack and making it run fast is very useful and not sad at all.

They're making a widely used bad language better, so people using (or forced to use) said bad language can improve their code. I think it's noble!

I don't know if you've seen what we're doing with JavaScript :)

Reply on news.ycombinator.com