43 ms·

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

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

by girvo 12y ago

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.