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

41–50 of 122 posts

Re: Speeding up PHP with the HipHop VM

#41

Post by dkhenry »

pbiggar wrote: post #39
ck2 wrote: post #35

Earlier quoted context omitted.

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.

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 do, and I don't know if there is enough community around the zend core to really get it done even if they wanted to.

Re: Speeding up PHP with the HipHop VM

#42

Post by pbiggar »

dkhenry wrote: post #41
pbiggar wrote: post #39

Earlier quoted context omitted.

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.

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) that interpreter dispatch doesn't even matter.

Disclaimer: I dont think I've looked at PHP source in 3 years, it might have changed significantly but I suspect it has not. I'd love to be corrected with some detail!

Re: Speeding up PHP with the HipHop VM

#43

Post by dkhenry »

lbrandy wrote: post #20
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…

> ...about just shifting from PHP to a more performant language We already shift lots of things out of PHP into more performant (c++, java, etc) languages when we are building services and/or extensions and/or other computationally intensive things. But I think more to your point (and if not, let me indulge in the strawman), since this comes up frequently on reddit/hn: php is not somehow -uniquely- broken. While PHP…

So is your argument then that there is so much vested in facebook in dealing with and optimizing for PHP at scale that the real cost would be acquiring that knowledge a second time on a different platform since you _will_ run into scale problems no matter what language you use ?

From my experience in dealing with PHP performance warts. You can make it somewhat fast, but man the insides are so messed up every time I get into the core and try to do anything I want to rip my hair out.

Re: Speeding up PHP with the HipHop VM

#44

Post by dkhenry »

kmavm wrote: post #15
timdorr wrote: post #14

What version of PHP does HPHP match? 5.3 or 5.4? I ask because I've become very accustomed the short array syntax ([1,2,3]) and other goodies in 5.4.

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.

Re: Speeding up PHP with the HipHop VM

#45

Post by notJim »

dkhenry wrote: post #41
pbiggar wrote: post #39

Earlier quoted context omitted.

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.

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…

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

Re: Speeding up PHP with the HipHop VM

#46

Post by mcmire »

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 figure this stuff out. But, you have to ask, why are they still using PHP?? Why not use some of the new stuff that's out there now or heck, why not go with the JVM instead of reinventing the wheel here?

No I'm genuinely asking. Isn't some of the stuff here already being done by other languages, or is Facebook really breaking new ground here? (yes lbrandy I saw your earlier comment)

Re: Speeding up PHP with the HipHop VM

#47

Post by Firehed »

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…

I just don't understand the hate. Like any language it has some syntactic quirks and inconsistencies. There's no way to objectively say that one language is superior to another, because there are so many metrics that contribute to superiority and every person in the world is going to weight those various metrics slightly differently.

I imagine it's neither "despite" nor "because" of PHP use; any top-tier developer is going to use the tools available to him/her, rather than pick an employer in order to use a specific set of tools. Lower-quality developers may do so, but that's probably because they're less likely to know the right tool for the job (eg someone may hate functional programming and avoid jobs that use it, but that's because they don't know when FP is the ideal way to solve the problem)

Re: Speeding up PHP with the HipHop VM

#48

Post by haberman »

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

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.

Re: Speeding up PHP with the HipHop VM

#49

Post by byroot »

notJim wrote: post #45
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…

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

Re: Speeding up PHP with the HipHop VM

#50

Post by mitchellh »

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…

My personal opinion on it is that this is in fact a very efficient way of doing things at Facebook. Facebook probably doesn't hire more than a couple people working on HHVM. Let's say their salaries individually are around $100,000 a year. That's cheap for them versus the value they're getting out of it.

Facebook probably has millions of lines of PHP code, PHP code proven to work. This isn't just Facebook.com, but internal websites, their bug tracker software (that is open source), analytical software for PHP, etc. etc. Rewriting all that would be _expensive_.

Running it on normal Zend PHP, based on the benchmarks they get on HipHop, requires _way_ more hardware at the scale of Facebook, so again, very expensive.

PHP developers are abundant, PHP is a relatively easy language to teach, resources are everywhere. Due to their abundance, PHP developers (even at Facebook quality) are probably less expensive than other languages. Easier hiring and lower cost developers, cheaper.

Post reply on HN