11 ms·

Coming Soon in HHVM

114 points by jwatzman 12y ago

girvo 12y 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?
- gsnedders 12y 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 12y 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.)
    - gsnedders 12y ago
      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).
- rll 12y 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?
  - jwatzman 12y 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-hack 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.
    - girvo 12y ago
      ^^^ 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.
- Tloewald 12y ago
  All the major javascript engines are multistage now, not just safari.
  - gsnedders 12y ago
    Though only Safari (well, JavaScriptCore) is using LLVM (as a fourth tier).
- tach4n 12y 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.
  - pjmlp 12y 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.
    - lmm 12y ago
      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.
      - pjmlp 12y ago
        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.
        RussianCow 12y ago
        Those tools don't exist for all JITed platforms. Hence the problem.
bsaul 12y 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 12y 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 12y 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.
  - nightski 12y ago
    About as condescending as saying it is a waste of time to improve methods for bloodletting to cure disease.
    - ta_6c_0677Fr 12y ago
      Bloodletting is still used in modern medicine. With the leeches and everything.
      - nightski 12y ago
        As is PHP ;)
    - deleted 12y ago
      [deleted]
- 12y ago
joesmo 12y 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.
- jwatzman 12y 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.
  - joesmo 12y ago
    Awesome! I must've missed the announcement (if there was one). I'll definitely be checking it out soon.
- girvo 12y 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/ http://codebugapp.com/
Xorlev 12y ago
I wonder how long it'll be before HHVM starts driving the PHP project, implicitly or explicitly.
nodesocket 12y ago
We just need the Mongo extension (https://github.com/mongodb/mongo-php-driver https://github.com/mongodb/mongo-php-driver) to be supported to try HHVM out.
- fredemmott 12y ago
  People are having lots of success with https://github.com/mongofill/mongofill-hhvm https://github.com/mongofill/mongofill-hhvm
pilif 12y 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 12y 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.
  - pilif 12y 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.
    - fredemmott 12y ago
      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.
      - fredemmott 12y ago
        also, if this is an open source workload, any chance you could submit it to https://github.com/hhvm/oss-performance https://github.com/hhvm/oss-performance ? We generally optimize based on those benchmarks, and Facebook itself.
- girvo 12y 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 12y ago
Any sign of official PostgreSQL support?

114 points by jwatzman 12y ago

girvo 12y 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?

gsnedders 12y 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 12y 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.)
  - gsnedders 12y ago
    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).
rll 12y 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?
- jwatzman 12y 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-hack 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.
  - girvo 12y ago
    ^^^ 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.
Tloewald 12y ago
All the major javascript engines are multistage now, not just safari.
- gsnedders 12y ago
  Though only Safari (well, JavaScriptCore) is using LLVM (as a fourth tier).
tach4n 12y 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.
- pjmlp 12y 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.
  - lmm 12y ago
    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.
    - pjmlp 12y ago
      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.
      - RussianCow 12y ago
        Those tools don't exist for all JITed platforms. Hence the problem.

bsaul 12y 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 12y 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 12y 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.
- nightski 12y ago
  About as condescending as saying it is a waste of time to improve methods for bloodletting to cure disease.
  - ta_6c_0677Fr 12y ago
    Bloodletting is still used in modern medicine. With the leeches and everything.
    - nightski 12y ago
      As is PHP ;)
  - deleted 12y ago
    [deleted]
12y ago

joesmo 12y 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.

jwatzman 12y 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.
- joesmo 12y ago
  Awesome! I must've missed the announcement (if there was one). I'll definitely be checking it out soon.
girvo 12y 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/ http://codebugapp.com/

Xorlev 12y ago

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

nodesocket 12y ago

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

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

pilif 12y 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 12y 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.
- pilif 12y 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.
  - fredemmott 12y ago
    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.
    - fredemmott 12y ago
      also, if this is an open source workload, any chance you could submit it to https://github.com/hhvm/oss-performance https://github.com/hhvm/oss-performance ? We generally optimize based on those benchmarks, and Facebook itself.
girvo 12y 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 12y ago

Any sign of official PostgreSQL support?