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

81–90 of 122 posts

Re: Speeding up PHP with the HipHop VM

#81

Post by pjmlp »

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…

Because you also need to consider the human factor.

Changing languages in the scale of Facebook, means that everyone, internal or external, need to know the new language.

This transition is a big process, which usually costs much more money in trainings and loss of productivity, than having a dedicated team improving the performance of existing tools.

Re: Speeding up PHP with the HipHop VM

#82

Post by nicholassmith »

jebblue wrote: post #63
nicholassmith wrote: post #17

Amazed at all the 'engineer X policy or feature request slackers'. Can't say I'm the biggest fan of Facebook as a service but what their engineers are doing in terms of pushing the state of the art is fantastic. Out of curiosity if there's anyone involved in Facebook on HipHop, has there ever been a discussion about just shifting from PHP to a more performant language, or is a case of still reaping the benefits of PH…

>> Can't say I'm the biggest fan of Facebook as a service but what their engineers are doing in terms of pushing the state of the art is fantastic. They let people upload comments and pictures. Anything fancy is done mostly in the client or am I overlooking something?

Well, for a non-client example they do a lot of analytics, probably more than we know. Plus they created their own highly optimised php compiler from scratch that isn't just production ready, but battle hardened.

HipHop alone should get Facebook's development team praise.

Re: Speeding up PHP with the HipHop VM

#83

Post by pjmlp »

xxpor wrote: post #33
propercoil wrote: post #22

Earlier quoted context omitted.

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

I though Amazon was still C++ at their main infrastructure.

Re: Speeding up PHP with the HipHop VM

#84

Post by ZeroGravitas »

pbiggar wrote: post #42
dkhenry wrote: post #41

Earlier quoted context omitted.

I think that's a function of their inability to let go of their own work. The internals of PHP need a _complete_ overhaul to make PHP competitive on a speed/memory basis with the python and rubys of the world, but that would mean throwing away a lot of work by the current contributors and probably re-architecting things like zvals and internal opcode representation. That's something I don't think they are willing to…

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)…

Genuine question: Couldn't we all just move to HipHop if the PHP internals are so bad?

Re: Speeding up PHP with the HipHop VM

#85

Post by dparoski »

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…

As noted elsewhere in this thread, a stack-based design typically produces more compact bytecode. Compactness was a concern for us because of the size of FB's PHP code base. Also, generally speaking a stack-based design tends to be easier to deal with when working to get a prototype VM up and running quickly.

Many of the advantages of register-based designs (ability to optimize by rewriting the program at the bytecode level, ability to write faster interpreters, ability to map bytecode registers to physical registers, etc.) weren't particularly attractive to us because we knew we were going to build an x64 JIT that did its own analysis and optimization to take advantage of type information observed at run time.

Thus, we drafted a stack-based design for HipHop bytecode. It captured PHP's semantics correctly and happened to fit in fairly well with PHP's evaluation order, so we ran with it and here we are.

Re: Speeding up PHP with the HipHop VM

#86

Post by nickik »

masklinn wrote: post #76
kmavm wrote: post #38

Earlier quoted context omitted.

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…

So it's closer to V8's "basic" JIT?

Im not a expert but I think the V8 compiles methods that contain controlflow even in the basic compiler.

Re: Speeding up PHP with the HipHop VM

#87

Post by aardvark179 »

bascule wrote: post #26
kmavm wrote: post #12

Earlier quoted context omitted.

HHVM was pretty far along when we started talking to the PyPy folks; it was already able to run the site, and hosting internal development at Facebook. Our interest in PyPy wasn't an immediate, drop-everything-and-change-to-PyPy kind of interest. It was a research project, which had a positive outcome. Making a production-ready, PyPy-based system for PHP would still be an enormously big undertaking, though. PyPy is t…

I'm kind of surprised you didn't pursue the JVM and InvokeDynamic for this purpose instead of PyPy

I think there is a project of that sort going on, there was a guy from Facebook at the jvm language summit this year.

Re: Speeding up PHP with the HipHop VM

#88

Post by debacle »

nicholassmith wrote: post #17

Amazed at all the 'engineer X policy or feature request slackers'. Can't say I'm the biggest fan of Facebook as a service but what their engineers are doing in terms of pushing the state of the art is fantastic. Out of curiosity if there's anyone involved in Facebook on HipHop, has there ever been a discussion about just shifting from PHP to a more performant language, or is a case of still reaping the benefits of PH…

The PHP language is performant just fine, though it has a few warts (that could be solved by making HHVM support a superset of PHP).

The problem is that the interpreter is shite.

Re: Speeding up PHP with the HipHop VM

#89

Post by debacle »

dkhenry wrote: post #44
kmavm wrote: post #15

Earlier quoted context omitted.

It is closer to 5.3, though we've adopted some 5.4 features: traits, our closures' treatment of $this, and f()[$x] syntax. Edit: notably not short array syntax, at least yet.

This makes me sad. That's one of the nicest features of 5.4 not needing to type array() all over the place.

It's a relatively trivial feature to implement (really just syntactical sugar), it probably just wasn't prioritized.

Re: Speeding up PHP with the HipHop VM

#90

Post by debacle »

olaf wrote: post #8

"So, when you combine XHP with HipHop PHP you can start to imagine that the performance penalty would be a lot less than 75% and it becomes a viable approach." http://toys.lerdorf.com/archives/54-A-quick-look-at-XHP.html

That's from 2 years ago. What is its relevance now?
Post reply on HN