Facebook Rewrites PHP Runtime For Speed 295
VonGuard writes "Facebook has gotten fed up with the speed of PHP. The company has been working on a skunkworks project to rewrite the PHP runtime, and on Tuesday of this week, they will be announcing the availability of their new PHP runtime as an open source project. The rumor around this began last week when the Facebook team invited some of the core PHP contributors to their campus to discuss some new open source project. I've written up everything I know about this story on the SD Times Blog."
Re:High performance in scripting languages? (Score:1, Interesting)
It's not just websites. I don't know what the fascination is with scripting languages on the Linux platform or with FOSS in general, but it results in slow programs with flaky UIs.
I like to use refurbished/recycled machines; which means that I'll have an old P4, 512M RAM and a slow bus. Many times, applications written in a scripting language, whether it be Perl, Python, PHP, or whatever, will hang often and then start working. I can always tell. That's why I knew Open Office was written in something like C when others on the Net were stating it was written in some such interpreted language.
HyperPHP, or HPHP (Score:5, Interesting)
According to that article posted recently [slashdot.org] about Facebook's master password being 'Chuck Norris', the project is indeed a compiled PHP that goes by the name of HyperPHP, or HPHP. It will supposedly lower the load on the servers by 80% and speed up things 5x, according to the unnamed source in the original blog post.
VM's (Score:2, Interesting)
Re:High performance in scripting languages? (Score:5, Interesting)
Exactly, and it's not like there is so much heavy processing cpu wise. Facebook probably has calculated that they can get enough performance out of recoding the runtime (even 1% is large enough for site as large as facebook). While doing that they also create a faster runtime that everyone can use. Everyone moving to write their sites in C/C++ doesn't make any sense.
Also a lot of the site structure can be cached in memcache or accelerating proxies like squid, so you aren't actually interpreting PHP code lots of the time. Facebook also did a lot of work towards memcache, because they are mostly a DB heavy site, not CPU.
PHP is slow (check), now what.... (Score:5, Interesting)
Why not just stash your farm of slow php systems behind some heavy duty caching appliance(s)?
Something like aicache might fit the bill.
Complexity and cost of embedded approach (Score:4, Interesting)
If your developers are noobs and can't use real languages and there just Object Oriented kids who can't work on memory and need to access everything through abstracted methods, then fire them and get in some embedded developer
Embedded developers tend to 1. work on smaller, more focused systems, and 2. charge more. For one thing, a module inside Facebook deals with data types more complex than those in the firmware of a car engine's microcontroller. And below a certain scale, the money you save by hiring noobs (and taking the tax credit for recent graduates if available) can pay for throwing more hardware at the problem.
Assembler? Really? (Score:5, Interesting)
Re:Assembler is High Performance (Score:2, Interesting)
You are kind of person I would never hire. Period. ..
Assembly doesn't mean speed. there is only potential not more. It has become increasingly difficult to develop in assembly as the architecture and complexities involved (drivers, APIs, hardware, devices, underlying os, etc.) has evolved so much. Decent optimizing compilers nowadays out perform hand written assembly. Further more in commercial software development time is pretty much the most important factor. If you could do in 1 day same thing that would take 2 weeks with assembly? The choice is clear. Not to mention concerns about portability, maintainability, extendibility,
So really everything considered you should seriously rethink your ideals about developers because any seriously minded person just laughs at statements like yours.
Sorry, but true.
Re:Is compiled PHP even possible? (Score:3, Interesting)
http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/ [mit.edu]
Worth a look.
Re:Facebook's architecture is the problem, not PHP (Score:4, Interesting)
I'm no PHP fan but I won't be surprised if FB decided that optimizing the interpreter and investing resources in new functionality is a better business decision than investing in a giant rewrite of what they have now. That would effectively stop them for many months in the best case, or double their costs as a team keeps adding features to the PHP architecture and another one plays catch-up in another language. But maybe they also have some plan to rewrite some core components in a faster language, like twitter did porting the backend tasks from Ruby to Scala.
We could say that they started with the wrong technology but using PHP Zuckerberg was able to deliver what turned out to be a successful product back in 2004. Had he wrote it in Java he could have missed a window of opportunity and people could be using some different social network now. Same logic applies to twitter's choice of Ruby, which by the way they still use for the frontend. Many recent interpreted languages (I'm thinking about Ruby) trade execution speed for speed of coding and delivering products. Many products totally fail and many others don't get so successful to need optimizations so IMHO speed of delivery is the key factor: deliver, get customers, get money and only then we'll think about making our servers run fast.
Ah... If only FB's new interpreter could access instance variables without that redundant $this-> construct that clutters all OO PHP code...
They should spend more on the upload tool (Score:4, Interesting)
That thing is a broken buggy piece of garbage. Any time I go out to an event or something and want to upload anything more than half a dozen photos, it inevitably blows up on random photos for no reason (completely fresh off the camera unedited photos). I have to babysit the upload and instead of just hitting select all and letting it go, I end up having to upload it in chunks of 5 photos at a time.
Re:JavaScript (Score:4, Interesting)
One scripting language has a huge deployment advantage over everything else: ECMAScript.
This is a nice lead-in to my point, though; Facebook is one of those websites that make it look like Firefox is murdering your machine. In reality, it's sites which misuse Javascript. (Sorry, but ECMAScript is just too unwieldy. I wouldn't say it. Too bad, because it desperately needs renaming.) If I leave Slashdot open all night, nothing bad happens. If I leave a long Facebook tab open all night, I have to close it before I can use my browser in the morning, even on my shiny new 4GB RAM system, let alone on my 1GB machines. If they want to improve the user experience, they should try cleaning up their crap Javascript.
Re:Complexity and cost of embedded approach (Score:4, Interesting)
My impression tends to be that the best overall programmers are those with a solid understanding of algorithmics theory, programming language design in general (meaning they have had exposure to all kinds of solutions), and most interestingly, tend to have an understanding of functional programming. The true programmer gods I have come across have always been Lispers, almost without exception.
On the other hand, I never understood what is supposedly so educational and intellectually important in things like assembly. If one only learned that, it wouldn't still mean that one could actually use it for anything... it's just "manipulate state in registers and RAM by making use of extremely rudimentary basic operations". The transformations into machine code from higher-level program solution descriptions are much more consistently handled by a compiler than a human, and as that is manual, automatable work, it may be more important to study compiler construction... (which Lisp is pretty good for)
Resin Quercus (Score:4, Interesting)
Akamai sucks (Score:3, Interesting)
Re:They should spend more on the upload tool (Score:5, Interesting)
For PHP this is the APC Cache module. You send an id with your file upload form then "Load that page using that ID" till the progress gets to 100%. According to the docs the module can poll at a period of "0 seconds" meaning as fast as possible. This halves upload speed.
On the client end, the old HTML way(no feedback) was a simple form with a submitted page. If you arrive at the submit page then the upload worked. The new way is 50-60k of javascript, which is a collection of fragile code. Yahoo's GUI upload for example. Try moding their code and your GUI *will* fail. The file may or may not upload.
br Given the modern web is *all about* uploading user submitted media, I am amazed there arent headlines "Mozilla forgets everything and rebuilds file upload in partnership with Apache...then thinks about HTML 5"
Re:High performance in scripting languages? (Score:3, Interesting)
What you call a crutch, most developers call an enormous time saver. The web moves so fast that you simply cannot afford to take forever developing it just so that the code executes efficiently. Sure, PHP, Perl, Python, and Ruby are slower than C or C++. But for at least the last decade, hardware has been cheap enough that it makes a lot more business sense to just throw more servers at the problem than it does to delay your product launch for a year and/or double your programming staff while you make everything "perfect" in a lower-level language. Most of the problems around making web apps scalable to millions of concurrent users have been solved or will be in the near future. (CDNs, memcache, load balancers, etc.) When you find bottlenecks, you rewrite those specific parts using a better design or a lower-level language. If your developers are any good, they will have modularized the code, making such upgrades relatively painless. Trying to optimize the entire codebase for performance before it's even out in the wild ensures that it will never get there.