Facebook Porting PHP To JVM(nerds-central.blogspot.com) |
Facebook Porting PHP To JVM(nerds-central.blogspot.com) |
Phalanger worked well even without using the DLR (dynamic language runtime) so a JVM implementation shouldn't be a massive undertaking (except for the lexer and parser parts...)
We have our own VM written and it isn't based on the JVM.
Bytecode: https://github.com/facebook/hiphop-php/blob/master/doc/bytec...
Code: https://github.com/facebook/hiphop-php/tree/master/src/runti...
"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.
Also, JVM Language Summit, not Java Language Summit. (OP got it wrong too.) More on http://wiki.jvmlangsummit.com/Main_Page
None. No links. No names. No quotes. No press releases. No blogs. No email archive. Nothing. Not a skerrick. Not a sausage. Not a sniff.
unfortunately my boss thinks as you do..
If you're going to make such a massive undertaking anyway (it's not just the new runtime, all existing code will have to be re-tested and re-debugged), why not sink the man-hours into putting it into a new language better suited to the task from the start?
As far as mainstream languages go, only C and C++ have a performance and scalability edge, but C++ at least comes with more complexity. JVM seems to hit the performance:complexity sweet spot.
As much as I love to rag on java the language the JVM is generally a solid piece of work that makes reasonable tradeoffs.
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.)
Did Google Translate write the article?
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.
It seems easier to me to port PHP to Rhino or node.js than to bring PHP to the JVM. Especially considering CoffeeScript, PHP just can't keep up.
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.
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 improving performance as they go. Then they'd not only get the benefit of a better runtime, but also a safer, faster language. In fact, if they're anything like most companies I know, they're always in the process of rewriting one service or another to improve performance or features, whether in a new language or not. All they'd need to do would be to switch to the new language whenever they were refactoring existing code anyway.
Of course I can't make the decision for them, and they are rightly hesitant to do an entire rewrite. But it seems like they're going to fairly extreme lengths to stay with PHP.
Also, developing a new implementation of PHP allows site development to continue in the meantime.
So while there are certainly good arguments to be made that rewrites can bite you in the ass and should often (though not always, IMO) be avoided, I wish people would stop referencing Joel's circa-2000 post unless they are willing to rewrite it in hindsight and still attempt to make his argument.
/sarcasm
Come on, they created Thrift, I think we can assume they use it?
If you read the methodology listed in their FAQ, they state in bold - "Time measurements include program startup time".
http://shootout.alioth.debian.org/help.php#time
If you read the section "What about Java?" they mention ADDITIONAL measurements, which are only shown on the Help page, and indicate how little difference JVM startup time makes once these programs have run for 5 seconds and 20 seconds.
I'm also a bit wary of leaping from one-guy-musing-in-a-hallway to FACEBOOK PORTING PHP TO JAVA.
of course, you can't do that with computer software
I didn't mean 2.5Mb per copy of the JVM. I meant per runtime within the JVM. These are run as threads, rather than processes.
So we're really comparing
n instances of MRI * 50Mb
1 JVM + (n * 2.5Mb)
Sorry, what I said originally is easily misleading.
The biggest problem I've had with the CLR is threads bouncing between CPUs but I'd attribute that to Windows as I worked around it with some Win32 calls to pin threads to processors.
Can't really compare to LLVM, I haven't personally encountered any of the known llvm bugs (clang to be fair) with Obj-C.
I'd try to increase the revenue my server generates rather than decrease the cost of servers, but I'm the kind of guy who thinks it's possible to pull more than 5 cents an hour in revenue from a server, but if you only get 5 cents per hour then it would be important to use linux so you maintain your 2 cent per hour profit margin.
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 very devoted developers cranking this out with good results towards the end of the year.