Live data from Hacker News

Speeding up PHP with the HipHop VM

facebook.com

31–40 of 122 posts

Re: Speeding up PHP with the HipHop VM

#31
post #19
post #2

Why is the blog on facebook?

We work for Facebook, and make a lot of announcements on the engineering blog. We also have a group blog on WordPress-in-HHVM running here: http://www.hiphop-php.com/wp/

Didn't realize that until I actually went to the page. I need to learn to keep my pie hole shut more often.

Re: Speeding up PHP with the HipHop VM

#32
First off thanks for all the hard work. Do you have a list of the php extensions you support? I’m wondering if things like cURL, memcache, pdo MySQL etc are supported. I found https://github.com/facebook/hiphop-php/wiki/Extensions-and-m... but its a bit outdated (last mod 2yrs ago).

Also wondering what APC methods you support.

Re: Speeding up PHP with the HipHop VM

#33
post #13

Earlier quoted context omitted.

PHP is used for a subset of development at Facebook. I'm not sure what the split is, but I would not be surprised if PHP is the primary language used by less than 60% of Software Engineers at Facebook. The rest code in C++, Java, Python, and then a bunch of other languages that are less used. The PHP development environment at Facebook is unlike that found at any other company I'm aware of, and common PHP pitfalls an…

re-writing the code of any big project is insane. You are going to face those walls you faced in the past - again. Using this logic you would change the whole codebase every few years.. ridiculous

Amazon did it in the 2002/2003 timeframe when they moved from Obidos (C++) to Gurupa (Perl/Mason).

Re: Speeding up PHP with the HipHop VM

#34
post #29

By the way, there is an alternative to HipHop that is actually easier to implement because it makes php extensions. It's called PHC http://phpcompiler.org and it's open source. It was Paul Biggar's PhD thesis http://blog.paulbiggar.com/archive/a-rant-about-php-compiler... It just needs some community contributions to catch up.

While you are very kind to say so, even the original Hiphop blew past what phc could do. Importantly, phc did not support the full PHP language (we had basic object support, and no support for magic methods).

There were two cool things about phc: that it had a really advanced static analyzer, and that it compiled to modules compatible with zend. However, these are somewhat mutually exclusive, and making them work well together is an open problem (though I had some ideas).

I moved on from phc, and there's no-one left in the community really. I now run https://circleci.com (applying my compiler knowledge in a different way). I tried to pass the reigns on, but nobody stepped up. Hard to find people who love PHP but are also able to hack on compilers.

Re: Speeding up PHP with the HipHop VM

#35
post #34
post #29

By the way, there is an alternative to HipHop that is actually easier to implement because it makes php extensions. It's called PHC http://phpcompiler.org and it's open source. It was Paul Biggar's PhD thesis http://blog.paulbiggar.com/archive/a-rant-about-php-compiler... It just needs some community contributions to catch up.

While you are very kind to say so, even the original Hiphop blew past what phc could do. Importantly, phc did not support the full PHP language (we had basic object support, and no support for magic methods). There were two cool things about phc: that it had a really advanced static analyzer, and that it compiled to modules compatible with zend. However, these are somewhat mutually exclusive, and making them work wel…

Maybe you were just half a decade before your time and the rest of us had to catch up.

I worry the php community is losing or has lost some of the really smart folks.

Suhosin (Stefan Esser) is also fading away without any updates to work with php 5.4 and that's really sad, especially considering the radical performance improvements and memory-use reductions found in 5.4 and 5.5 vs 5.2 - 5.3

Re: Speeding up PHP with the HipHop VM

#36
This is curious. Their trace-based approach looks like Mozilla's Tracemonkey - even using the same terminology like side-exits. Mozilla discontinued Tracemonkey because it was really good for deep loops and not much else. They moved to JaegerMonkey, which is a method-compiled VM like v8 (at the time), and are now moving to IonMonkey, which is a best-of-all-worlds version.

So I'd love to hear why using a circa-2009 technology was the right one? Is PHP sufficiently different from Javascript for this to make sense (as someone who has worked on VMs for both, I think there's a good chance of that)? Why not use a method-compiler instead? Very interested in the answers and comparison to other JITs out there, if any HHVM people are here.

Re: Speeding up PHP with the HipHop VM

#37
post #36

This is curious. Their trace-based approach looks like Mozilla's Tracemonkey - even using the same terminology like side-exits. Mozilla discontinued Tracemonkey because it was really good for deep loops and not much else. They moved to JaegerMonkey, which is a method-compiled VM like v8 (at the time), and are now moving to IonMonkey, which is a best-of-all-worlds version. So I'd love to hear why using a circa-2009 te…

One more thing - the use of a stack-based bytecode is also curious. PHP itself (the Zend engine) uses a register-based bytecode (well, it uses a horror-show of an in-memory bytecode-like-thing, which could best be described as a register-based bytecode). The PHP engine details leak into the language a lot, so the difficulties they describe aren't unexpected.

Not only that, but bleeding-edge JITs typically use register-based bytecode. Java's JIT and all the modern versions of Javascript VMs use register-based (in many cases actually translating from stack-based bytecode that the parser outputs, to register-based bytecode consumed by the JIT compilers). Since 2003, when my PhD advisor and his co-authors (Google "David Gregg" and "Anton Ertl") showed register VMs could be much more efficient that stack-based ones, the jury has settled on register-based VMs.

So I'm curious as to why a stack-based instruction set was used in the VM design?

Re: Speeding up PHP with the HipHop VM

#38
post #36

This is curious. Their trace-based approach looks like Mozilla's Tracemonkey - even using the same terminology like side-exits. Mozilla discontinued Tracemonkey because it was really good for deep loops and not much else. They moved to JaegerMonkey, which is a method-compiled VM like v8 (at the time), and are now moving to IonMonkey, which is a best-of-all-worlds version. So I'd love to hear why using a circa-2009 te…

It isn't tracing. Don't be fooled by the name "tracelet".

Unlike trace trees, tracelets contain no control flow. It is just a type-specialized basic block. This means that the jit output does not combinatorially explode when we encounter polymorphism. In many ways, our approach is the opposite of tracing; we jit the first time we hit any code at all. And we look terrible on loopy microbench code, but run FB's multi million LOC application very well.

Re: Speeding up PHP with the HipHop VM

#39
post #35
post #34

Earlier quoted context omitted.

While you are very kind to say so, even the original Hiphop blew past what phc could do. Importantly, phc did not support the full PHP language (we had basic object support, and no support for magic methods). There were two cool things about phc: that it had a really advanced static analyzer, and that it compiled to modules compatible with zend. However, these are somewhat mutually exclusive, and making them work wel…

Maybe you were just half a decade before your time and the rest of us had to catch up. I worry the php community is losing or has lost some of the really smart folks. Suhosin (Stefan Esser) is also fading away without any updates to work with php 5.4 and that's really sad, especially considering the radical performance improvements and memory-use reductions found in 5.4 and 5.5 vs 5.2 - 5.3

The PHP internals community is quite a poisonous place, IMO. Its a community that destroyed itself by being hostile to everyone who wasn't one of them.

Re: Speeding up PHP with the HipHop VM

#40
post #38
post #36

This is curious. Their trace-based approach looks like Mozilla's Tracemonkey - even using the same terminology like side-exits. Mozilla discontinued Tracemonkey because it was really good for deep loops and not much else. They moved to JaegerMonkey, which is a method-compiled VM like v8 (at the time), and are now moving to IonMonkey, which is a best-of-all-worlds version. So I'd love to hear why using a circa-2009 te…

It isn't tracing. Don't be fooled by the name "tracelet". Unlike trace trees, tracelets contain no control flow. It is just a type-specialized basic block. This means that the jit output does not combinatorially explode when we encounter polymorphism. In many ways, our approach is the opposite of tracing; we jit the first time we hit any code at all. And we look terrible on loopy microbench code, but run FB's multi m…

Very interesting. Rereading with that insight makes your approach clearer - side exits aren't control flow, they're for the weird shit that PHP can throw at you. Aliased local variables are one of the major differences between PHP and Javascript, and that's a really good way of handling them.

So it avoid trace explosion, and I would describe this as a sort-of local (in the compiler sense of "basic block") version of a method compiler. Can you compare the approaches?

Post reply on HN