Live data from Hacker News

Facebook Porting PHP To JVM

nerds-central.blogspot.com

31–40 of 68 posts

Re: Facebook Porting PHP To JVM

#31
post #3

Earlier quoted context omitted.

No reason it should take that long. The article suggest 6 person years - which could mean 6 people for 1 year.

try reading The Mythical Man Month http://en.wikipedia.org/wiki/The_Mythical_Man-Month unfortunately my boss thinks as you do..

Errmm, if you actually read the book properly you'll realise that the baby/mothers analogy applies to synchronous sets of work and workloads that cannot be broken down into parallel running tasks. Once architected to a suitable degree I'd imagine that there are at least a few streams of work that could be carried out concurrently.

Re: Facebook Porting PHP To JVM

#32

Why do these companies like the JVM so much? Twitter, and now Facebook. Does it have that great of performance?

Yes. http://shootout.alioth.debian.org/u64q/which-programming-lan... Note that Java compares very favorably with C. (Of course, the real thing to take away from that chart is: why don't all the JVM users switch to Haskell? It's more concise, safer, and has a better community.)

The JVM can be bootstrapped relatively easily compared to Haskell. It's just C++ code. If I gave you a computer with a C and C++ compilers, and the ghc source, what would you do?

Re: Facebook Porting PHP To JVM

#33

Earlier quoted context omitted.

Yes. http://shootout.alioth.debian.org/u64q/which-programming-lan... Note that Java compares very favorably with C. (Of course, the real thing to take away from that chart is: why don't all the JVM users switch to Haskell? It's more concise, safer, and has a better community.)

Many JVM developers for whom programming is craft rather than a day job are definitely looking at both Scala and Haskell. Lots of excellent stuff going on with both, as you point out - concise, safer.

I'll just have to trust you on that I suppose.

Re: Facebook Porting PHP To JVM

#34
post #21
post #16

Earlier quoted context omitted.

Because there are millions of man hours of PHP from FB and it will cost less than one hundred thousand to port that work to the JVM. Yes the code will have to retested, but if you rewrite then you rewrite AND retest. Working code makes a great test suite, something you lose in a rewrite.

Yes, that sounds fine (and I'm aware of the Spolsky article posted in another comment.) But the fact is that a system of that size simply must already be split up into discrete services or components. (If it's not, then that should be their first priority. But I can't imagine Facebook is running everything they do out of one process). So they could port each service/component one at a time, rigorously testing and imp…

[deleted]

Re: Facebook Porting PHP To JVM

#35
post #17

Why do these companies like the JVM so much? Twitter, and now Facebook. Does it have that great of performance?

There aren't that many problems with the JVM compared with Java. Most of what makes java suck is the language and what makes the performance sluggish is the standard lib as well as the programming style the community encourages. As much as I love to rag on java the language the JVM is generally a solid piece of work that makes reasonable tradeoffs.

How does it compare with the CLR, or things like LLVM?

Re: Facebook Porting PHP To JVM

#36

This is all great but... why?

Because:

1. the JVM is an open, stable, mature, fast platform for server applications.

2. Facebook are not moving off PHP any time soon.

3. For stuff outside its written-in-C standard lib, PHP is quite slow. PHP's garbage collection, JITting etc is nowhere near as advanced as the JVM's.

4. Since porting dynamic languages to the JVM is a well-worn pathway, why not try porting PHP and see how it performs?

If Facebook can reduce their CPU and RAM requirements by just 10%, it pays for itself many times over vs the stock PHP runtime. And based on what I've seen with JRuby (going from 50Mb MRI runtimes down to 2.5Mb runtimes that are 3-10x faster) that's entirely reasonable.

Re: Facebook Porting PHP To JVM

#37
It should be noted that there is no direct evidence that this is happening, other than:

"The presence of Facebook engineers at the Java Language Summit in San-Francisco"

Is the author aware that Facebook is a multi-language shop? It's why they have Thrift, after all.

Re: Facebook Porting PHP To JVM

#38

At this point I have to just laugh. They literally already paid for the development of a prototype for a faster PHP, and decided not to pursue that route: http://morepypy.blogspot.com/2012/07/hello-everyone.html . I have to assume they have some insane internal politics, because there's no sane technical reason to develop HipHop (static subset-of-php to C++ compiler), then start the HipHop VM, then fund the PHP on Py…

I don't understand what's wrong with exploring your options. Why would you assume that the reasoning has something to do with politics rather than trying to find a better technical solution to their problem?

They're not exploring a research space, they're exploring a space where the options are incredibly well known, and they're jumping from solution to solution, even after they appear to find a success.

Re: Facebook Porting PHP To JVM

#39

Earlier quoted context omitted.

try reading The Mythical Man Month http://en.wikipedia.org/wiki/The_Mythical_Man-Month unfortunately my boss thinks as you do..

You either never read the book or are interpreting it wrong. The premise is that as you add more people to an EXISTING project, the amount of time it will take to complete will increase. However, if all of those people are involved from the beginning, then you are not subject to the same phenomenon - within reason of course. So while it might not be "6" developers working on it for a year, it could potentially be 9 v…

Brookes also talks about another issue, that in a team of 6 there are (6 choose 2) edges in the communication graph. I think this is what kyriakos was referring to.

Re: Facebook Porting PHP To JVM

#40

At this point I have to just laugh. They literally already paid for the development of a prototype for a faster PHP, and decided not to pursue that route: http://morepypy.blogspot.com/2012/07/hello-everyone.html . I have to assume they have some insane internal politics, because there's no sane technical reason to develop HipHop (static subset-of-php to C++ compiler), then start the HipHop VM, then fund the PHP on Py…

Standard feasibility work for any large project? Alternately the potential that all of their explorations have application in a stack somewhere in the organisation? At any rate testing and validating / invalidating alternatives is time well spent if you have the engineering capacity.
Post reply on HN