Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speeding up PHP with the HipHop VM

facebook.com

Post reply on HN
Print view View original

51–60 of 122 posts

Re: Speeding up PHP with the HipHop VM

#51

Post by maratd »

mcmire wrote: post #46

Does anyone else think this is a tremendous waste of time for Facebook? I mean, obviously PHP powers a lot of stuff at Facebook, I'm sure there are zillions of lines of code they can't just replace today, and now they're forced to make it scale. I don't mean to be negative -- building faster, better systems is inspiring, and the stuff they are doing with PHP is pretty neat, and there are really smart people trying to…

> But, you have to ask, why are they still using PHP??

If you read the comments, you'll find the answer further down. They do address it. At their scale, all languages/platforms break and they would need to invest the same amount of time and effort getting it to work.

It won't make a difference if you switch to the latest hipster language. You'll still need an effort of this magnitude to get it to scale the way they need it to.

Furthermore, rewriting an entire code-base is a monumental undertaking that is both expensive and complex. Especially for something as large and diverse as Facebook. It also makes zero business sense and Facebook is a business.

Why should they take a risk with a new code-base, when what they're doing is clearly working? PHP just works.

Re: Speeding up PHP with the HipHop VM

#52

Post by tangue »

MichaelGG wrote: post #18
untog wrote: post #16

Earlier quoted context omitted.

I think you underestimate the number of PHP developers out there. There aren't many on Hacker News because we're all too cool for that stuff, but in the developer world in general there are a ton.

I think his point is that real top-tier developers are going to despite working with such a grotty language as PHP, so it hurts their hiring process that way. Whereas if they worked in a superior language (an ML, Haskell, a LISP...) they'd attract talent. Who wants to deal with a language such such inane design decisions all day? I'd imagine people signing up to work at FB do so despite the fact they use PHP, not bec…

Facebook lives in a SOA. PHP is probably the best choice for dispatching services written in more "advanced" language. The beauty of SOA is that you can use the right tool for the right job.

Re: Speeding up PHP with the HipHop VM

#53

Post by pbiggar »

haberman wrote: post #48
pbiggar wrote: post #42

Earlier quoted context omitted.

I wouldn't know if that's the reason, but totally agree that the internals need a total overhaul. The entire codebase was a complete mess - hacks built on hacks built on hacks. Each variable takes what - 96 bytes I think on 64bit machines? The opcodes are terrible. The interpreter dispatch is switch based, and funnily enough it doesn't matter because the rest of the engine is so slow (function dispatch in particular)…

What's wrong with switch based dispatch? Lua's dispatch is switch based, and it is the fastest mainstream bytecode-based VM out there last I checked.

Lua's dispatch wasn't chosen because it was the fastest. If you read their Lua5 paper, they discuss how they prioritized being portable ANSI C over speed. Indirect threading is the fastest simple technique, but you can do even better. See section 3.3 of http://www.cs.tcd.ie/publications/tech-reports/reports.07/TC... for a discussion.

Re: Speeding up PHP with the HipHop VM

#54

Post by pbiggar »

byroot wrote: post #49
notJim wrote: post #45

Earlier quoted context omitted.

Uhh, to the extent that it makes sense to compare speeds of programming languages, PHP is faster and uses less memory than both ruby and python in many or most cases: Python: http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... Ruby: http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

Did you looked at the source ? For example for the pidigits bench: The PHP version use the GM extension http://shootout.alioth.debian.org/u64q/program.php?test=pidi... And Ruby do it in pure Ruby http://shootout.alioth.debian.org/u64q/program.php?test=pidi... So basically it's a C vs Ruby benchmark. Many peoples complained on the forum, take a look. The Debian shootout is interesting, but don't take it as an absolute…

The Debian shootout has made some very questionable decisions, and the author has defended them by saying that you cant rely on the results. Which is definitely true.

Re: Speeding up PHP with the HipHop VM

#55

Post by snissn »

maratd wrote: post #10

For those who want to get their hands dirty: CentOS 6.3 x64: https://github.com/facebook/hiphop-php/wiki/Building-and-ins... Ubuntu 12.04 x64: https://github.com/facebook/hiphop-php/wiki/Building-and-ins...

Instructions for Ubuntu 12.04 x64: http://pastie.org/5456298

Re: Speeding up PHP with the HipHop VM

#56

Post by sb »

haberman wrote: post #48
pbiggar wrote: post #42

Earlier quoted context omitted.

I wouldn't know if that's the reason, but totally agree that the internals need a total overhaul. The entire codebase was a complete mess - hacks built on hacks built on hacks. Each variable takes what - 96 bytes I think on 64bit machines? The opcodes are terrible. The interpreter dispatch is switch based, and funnily enough it doesn't matter because the rest of the engine is so slow (function dispatch in particular)…

What's wrong with switch based dispatch? Lua's dispatch is switch based, and it is the fastest mainstream bytecode-based VM out there last I checked.

I don't know about the exact definition of "mainstream bytecode-based VM", but just for the record: both the OCaml interpreter and the GForth interpreter usually score pretty well, too.

Probably the de facto fastest interpreter is the one of the Sun HotSpot Java virtual machines. There is a paper by Robert Griesemer detailing some information, but AFAIR it is a hand-coded optimized assembly interpreter that does not too bad. LuaJIT's interpreter is doing quite well, too. (Mike Pall said in the LTU thread about trace-based compilation that the LuaJIT2 interpreter is mostly on par with the LuaJIT1 compiler, or at least not much slower.)

EDIT: replaced "LuaJIT1 interpreter" with more accurate compiler as pointed out by haberman.

Re: Speeding up PHP with the HipHop VM

#57

Post by eropple »

pbiggar wrote: post #37
pbiggar wrote: 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 registe…

Java's HotSpot is a stack machine, AFAIK. Dalvik is a register machine, but I wouldn't want to point to that as a positive. ;)

Re: Speeding up PHP with the HipHop VM

#58

Post by sb »

pbiggar wrote: post #37
pbiggar wrote: 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 registe…

AFAICT, two reasons come to mind:

1) A stack-based ISA is still more space-compact. (AFAIR the Shi et al. paper mentions something like a 40+% increase in space requirement for the instructions.)

2) The performance improvement of a register-based ISA is only visible for interpreters that suffer most from instruction dispatch [1]. PHP is a rather complex programming language that is most certainly not bound by instruction dispatch at all. So I guess it could very well make sense to stick with a simple stack-based ISA, which incidentally is also easier to compile from the AST.

[1] for the sake of completeness: the stack architecture emits many instructions to push operands onto the operand stack. A register-based interpreter does not need those. Hence, the overall number of dispatches is lower, and if dispatch cost is your bottleneck the overall performance increases. OTOH, you need more space, because in addition to the opcodes, you need to specify/encode which registers to take operands from and put results to. (Hint: quadruple code and the likes.)

Re: Speeding up PHP with the HipHop VM

#59

Post by sb »

pbiggar wrote: 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…

This is somewhat different from my memory. AFAIR, TraceMonkey was a trace-based JIT. JaegerMonkey was a JIT (however not just-in-time like V8 with a template-based JIT, but still using an interpreter initially). IonMonkey is--to the best of my knowledge--JaegerMonkey plus type inference (there was a paper by two Mozilla employees at PLDI'12 about their type inference.) So I guess it's not really using anything from trace compilation.

I think a trace-JIT still gives you a lot of bang for the buck and is (in theory at least) easier to implement. Two known projects using trace-compilation are LuaJIT2 (usually well known) and Dalvik VM's JIT compiler (not so well known, needed to watch the Google I/O 2010 announcement.)

Re: Speeding up PHP with the HipHop VM

#60

Post by haberman »

pbiggar wrote: post #53
haberman wrote: post #48

Earlier quoted context omitted.

What's wrong with switch based dispatch? Lua's dispatch is switch based, and it is the fastest mainstream bytecode-based VM out there last I checked.

Lua's dispatch wasn't chosen because it was the fastest. If you read their Lua5 paper, they discuss how they prioritized being portable ANSI C over speed. Indirect threading is the fastest simple technique, but you can do even better. See section 3.3 of http://www.cs.tcd.ie/publications/tech-reports/reports.07/TC... for a discussion.

If you're giving up portability, you might as well go all the way and create a JIT. Techniques like what the paper calls "inline-threaded dispatch" seem of limited usefulness, since they give neither the speed of a JIT nor the portability of a bytecode VM.

My main point was that switch()-based dispatch isn't that bad. I'm surprised that this recent literature distinguishes between switch dispatch and token-threaded dispatch, since as Mike Pall notes, "Tail-merging and CSE will happily join all these common tails of each instruction and generate a single dispatch point," so the goto-spaghetti of token-threaded dispatch is likely not even worth it. (http://article.gmane.org/gmane.comp.lang.lua.general/75426)

> Indirect threading is the fastest simple technique

I'm confused; the paper itself says: "However, because of a level of indirection, indirect-threaded dispatch is not be as efficient as direct-threaded dispatch."

Even direct-threaded dispatch still results in an indirect branch for every VM instruction, it just tries to save a table lookup over token-threading.

Ultimately the most common and practical dispatch techniques seem to boil down to either a single indirect branch or replicated indirect branches.

Post reply on HN