Recki-CT: PHP compiler in PHP(blog.ircmaxell.com)
blog.ircmaxell.com
Recki-CT: PHP compiler in PHP
http://blog.ircmaxell.com/2014/08/introducing-recki-ct.html
3 comments
To get the best performance out of HHVM, you have to let it "warm up" (JIT the functions you're using), and compile the bytecode ahead of time. Otherwise it assumes you could include new files it hasn't seen before, and has to skip out on some optimizations to accommodate that. So he can't claim he's faster when he's running it like this: @exec('hhvm ' . __FILE__ . " $test");
It's also worth noting that Facebook is actually pursuing this same approach with Hack (making the language more optimizable). And they've tried the AOT approach, and it turned out to be a huge pain for several reasons.
It's also worth noting that Facebook is actually pursuing this same approach with Hack (making the language more optimizable). And they've tried the AOT approach, and it turned out to be a huge pain for several reasons.
Please look at the test script again. It does indeed warm up the JIT.
The timing results come from within HHVM. Basically, the test is dispatched within HHVM, isolating just the function call itself. It's then executed 5 times (timed independently) and then the bottom 2 executions are thrown away. See: https://gist.github.com/ircmaxell/8859d7f1bbee7b2f6e16#file-...
So the warm-up period happens. It's not just "benchmark `hhvm file.php`". The benchmark happens inside of HHVM.
So yes, JIT warmup is accounted for 100%. In fact, PHP, HHVM and Recki-CT all execute with the exact same pre-compile steps (parsing and any pre-compiling are ignored in the benchmark).
And their AOT approach that they tried was all-or-nothing. Meaning the entire code base had to be converted. This is a "compile what you want, and run the rest normally". In fact, this is 100% compatible with Hack and HHVM...
The timing results come from within HHVM. Basically, the test is dispatched within HHVM, isolating just the function call itself. It's then executed 5 times (timed independently) and then the bottom 2 executions are thrown away. See: https://gist.github.com/ircmaxell/8859d7f1bbee7b2f6e16#file-...
So the warm-up period happens. It's not just "benchmark `hhvm file.php`". The benchmark happens inside of HHVM.
So yes, JIT warmup is accounted for 100%. In fact, PHP, HHVM and Recki-CT all execute with the exact same pre-compile steps (parsing and any pre-compiling are ignored in the benchmark).
And their AOT approach that they tried was all-or-nothing. Meaning the entire code base had to be converted. This is a "compile what you want, and run the rest normally". In fact, this is 100% compatible with Hack and HHVM...
While I happy for all the php coders out there, I am so sad this kind of things could help make php more important in the market place.
With WordPress still powering a _very large portion_ of the internet - the potential gain in this is huge.
According to surveys (http://w3techs.com/technologies/details/cm-wordpress/all/all) wordpress powers over 20% of the whole internet. PHP is still going strong and is huge and a lot of websites simply need something simple that works.
If this thing can introduce even a 10% performance gain in a CMS like WordPress - that can save millions of dollars in hosting bills worldwide.
As a programmer - I'm not very excited about WordPress to say the least but as an entrepreneur who has to pay hosting bills I can see the value in this. (Plus, compilers are insanely cool to begin with!)
According to surveys (http://w3techs.com/technologies/details/cm-wordpress/all/all) wordpress powers over 20% of the whole internet. PHP is still going strong and is huge and a lot of websites simply need something simple that works.
If this thing can introduce even a 10% performance gain in a CMS like WordPress - that can save millions of dollars in hosting bills worldwide.
As a programmer - I'm not very excited about WordPress to say the least but as an entrepreneur who has to pay hosting bills I can see the value in this. (Plus, compilers are insanely cool to begin with!)
But if it improves the quality of PHP coding and development in general, then that's a good thing.
Laravel is already making php more important in the market place.
HHVM is impressive largely because of the strides in performance despite PHP being an obnoxiously dynamic language, in the same way that V8 is impressive in the optimisations they're able to do on Javascript.
It's certainly a cool side project, but I don't think anyone is under the illusion that HHVM (or the official PHP interpreter) wouldn't be orders of magnitude faster if they didn't have to support the idiosyncrasies of PHP.