Coming Soon in HHVM

http://hhvm.com/blog/8405/coming-soon-in-hhvm

by jwatzman • 11 years ago

114 58 11 years ago

girvo5• 11 years ago

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?

gsnedders3• 11 years ago

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.

eropple• 11 years ago

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

rll• 11 years ago

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?

jwatzman2• 11 years ago

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.

Tloewald• 11 years ago

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

gsnedders3• 11 years ago

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

tach4n• 11 years ago

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.

pjmlp2• 11 years ago

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.

bsaul• 11 years ago

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.

exacube• 11 years ago

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!

Gigablah• 11 years ago

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.

nightski2• 11 years ago

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

mmckeen• 11 years ago

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.

fishnchips3• 11 years ago

rewriting that application would have been a disaster

Or the best decision ever made by the company.

SamReidHughes• 11 years ago

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.

skore• 11 years ago

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.

tracker1• 11 years ago

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.

girvo5• 11 years ago

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,

coldtea• 11 years ago

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.

jamesgpearce• 11 years ago

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

datashovel• 11 years ago

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.

laichzeit0• 11 years ago

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.

mtbcoder• 11 years ago

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.

joesmo3• 11 years ago

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.

jwatzman2• 11 years ago

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.

joesmo3• 11 years ago

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

girvo5• 11 years ago

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/

Xorlev• 11 years ago

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

nodesocket• 11 years ago

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

fredemmott4• 11 years ago

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

pilif2• 11 years ago

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.

andrewchambers• 11 years ago

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

pilif2• 11 years ago

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.

girvo5• 11 years ago

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.

mrmondo• 11 years ago

Any sign of official PostgreSQL support?

Coming Soon in HHVM

Related Stories