Slashdot Mirror
Facebook Rewrites PHP Runtime For Speed
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."
Is this what they're using on the newly redesigned site? Because if so, it's pathetically slow. Facebook is one of those places that with every attempt to "improve" things somehow manages to make it worse and worse. They're a perfect candidate for a Microsoft buyout.
PHP is for lazy developers. I develop my webapps in C and I even wrote my own httpd to improve performance.
At some point, if you are lucky enough, you will require extremely high performance from your web pages. You start out coding HTML in Notepad and move on to Perl CGI then on to PHP with scripting embedded right in the generated HTML. All the time you gain programming crutches at the expense of processing speed, and for a while this is a great tradeoff.
But one day you start having server hiccups because your scripts can't keep up with your traffic. Sites like Amazon have already run into this and have moved away from scripting languages and back to system languages. Running applications directly on the CPU instead of relying on a runtime to translate (at best) bytecode into machine instructions means maximizing CPU cycles.
So I wonder what longterm benefit there is in improving the language runtime.
Don't starting talking about high performance and then naming languages that don't have the chance to deliver. What you really need to do is just program the entire web page in Assembler and then your going to have speed and performance that can't get any faster. 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 who know speed = good code and good languages. If you don't want to use assembler then use good old C!
You want speed use languages that can deliver and don't try to rewrite slow scripting languages to do the job of the trusted old methods, assembler and C.
Sounds like Facebook rewrote PHP and then invited PHP core developers to adopt it as their core development platform? I can't imagine that went over all that well... probably hit a number of them in the pride region. And the article said it is to be released as open source, but failed to mention the license. Will this be some sort of twisted "FriendFace Public License" or some perversion?
This is not what is meant when a party contributes to an open source project. "Here, I rewrote it for you. It's better. Now just throw away everything else you've done and use this." Really?
According to that article posted recently 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.
From TFA: UPDATE: After sifting through the comments here and elsewhere, I'm inclined to agree with the folks who are saying that Facebook will be introducing some sort of compiler for PHP.
Not a fork. Not as newsworthy as implied.
This PHP compiler item was revealed three weeks ago by a Facebook employee. Read at http://therumpus.net/2010/01/conversations-about-the-internet-5-anonymous-facebook-employee/?full=yes
So there is one guy at Facebook doing this PHP rewrite. It must be possible to figure out who he is. Have they hired any high profile PHP developers?
Would a language that runs in a VM, like Java, Scala or C#, be faster? After all, Twitter rewrote their backend in Scala and they seem to have gotten better performance.
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
Speed of development is faster in a scripting language, and in developed countries, below a certain scale, throwing hardware at it is cheaper than throwing programmers at it. The point of the article is that Facebook is above that scale, and programmers to write a new PHP interpreter have become cheaper than adding hardware+power+cooling.
with flaky UIs.
Citation needed. True, the often use a different widget set from the rest of the desktop (e.g. Tk from Tcl and Python and Swing from Java), but the popular widget sets also have scripting language bindings. how can one really tell the difference between a wxWidgets or GTK app written with Python vs. C++?
I like to use refurbished/recycled machines; which means that I'll have an old P4, 512M RAM and a slow bus.
Do these use more electric power than, say, an Acer Aspire Revo? The power consumption of a Pentium 4 and the power to remove the heat it generates can become an issue, especially for a server that's turned on 24/7.
Many times, applications written in a scripting language, whether it be Perl, Python, PHP, or whatever, will hang often and then start working.
There are three causes for this, and you can distinguish them with 'top' or 'Task Manager' or something else that can count CPU time and page file accesses:
Why not just stash your farm of slow php systems behind some heavy duty caching appliance(s)?
Something like aicache might fit the bill.
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.
Assembly language isn't platform-independent. It's really easy to screw up and hard to optimize. And it's not much faster than C/C++. The issue at hand is balancing the cost of writing the code with the cost of running it. I don't see how the cost of writing and maintaining software in assembly language will ever compete with the costs of C/C++, potential speed increases and all. Object-oriented languages make small performance sacrifices in return for much greater maintenance, and that's how it should be. Scripting languages take this even further, and for these large websites have lost their advantage. The only time assembly will prevail is when we return to incredible memory constraints, but even embedded systems pack tons of memory now so I don't see that being an issue.
You can lead a horse to water, but you can't make it dissolve.
http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/
Worth a look.
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...
Flaky UIs - click on a button and nothing happens. Or things not drawing properly.
I've seen buttons do nothing and redraws fail even in compiled programs.
A refurb machine is about a third the cost of a new machine
By "cost", do you include or exclude the cost of power and cooling? And do you include or exclude the cost of replacing failed components? Capacitors die.
scripting languages are not appropriate for large applications with GUIs.
One scripting language has a huge deployment advantage over everything else: ECMAScript. It interacts with Document Object Models exposed by various runtime environments, and it's sandboxed so that users can more or less safely run a program without getting an administrator to install it. You might know it as JavaScript (ECMAScript + HTML DOM) or ActionScript (ECMAScript + SWF DOM). Or would you rather go back to ActiveX, where the web site sends the equivalent of a compiled DLL to each user, which runs with the user's full privileges and doesn't run on anything but a convicted monopolist's operating system?
http://wiki.answers.com/Q/Is_gotten_correct_grammar
Can't you?
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
If you could do in 1 day same thing that would take 2 weeks with assembly? The choice is clear.
Unless the two weeks of hand-tweaking the assembly language code of your program's single biggest bottleneck would reduce your program's system requirements so that twice as many users can use it. Such a case is reportedly common in video game development, where the increased revenue is often worth it.
Not to mention concerns about portability
"Portability" has more than one meaning. There's portability of the code, or its suitability for execution in multiple environments whose hardware isn't compatible. For this, you can keep a fallback implementation of each asm module in C. That's useful for running test cases such as whether the asm version still works correctly or whether it's worth continuing to maintain. The other kind of portability is the ability to run on small, battery-powered devices. These tend to have underpowered CPUs to save manufacturing cost and increase battery life, and the code to run on these CPUs must be extremely efficient in order for the application to be responsive. Go try to make a software 3D renderer on a handheld device with a 16.8 MHz ARM CPU and tell me you don't need assembly anymore.
I'm guessing you haven't gotten laid recently.
Instead of putting a band-aid on the current architecture
But that's exactly how you run a successful system.
1) Design product to meet needs of your audience
2) Design the implementation that you think will handle the load the best (with lots of load testing and simulations to make sure it meets expected demand)
3) Build product
4) Watch it behave in the wild... Realize that actual demand is considerably higher than expected demand and will continue to grow
5) Performance slows with more users... you need a solution that will the push the date of catastrophic overload further into the future, to buy time to work on *really* fixing the problem
6) Migrate to a new or adjusted architecture that will solve this current problem
7) Go to step 4
Facebook is on phase 5. You sound like scripting languages are the bane of slow products. Yet in reality, the main bottleneck is generally the database. If facebook rewrote everything in C or some other non-scripting language, not only would it be an incredibly long process, but the the end result would be far less beneficial than if they revamped their existing technologies and worked to up database performance. There is no ultimate solution for scaling a product. You need to be constantly adjusting your strategies, implementations, and systems to cope with resource usage.
The goal of computer science is to build something that will last at least until we've finished building it.
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.
Caucho Resin has a mostly pluggable replacement for PHP which is written in Java. It adds web friendly features to PHP like distributed sessions and load balancing. Given the JVM JIT is already plenty fast and the benchmarks show that Java/PHP beats regular PHP handily - I wonder if Facebook considered using it at some point.
If Facebook really wants to speed up the customer experience all they need to do is remove Akamai from their content delivery network (CDN). That's where my browser is always stuck in a Waiting status when I notice a connectivity issue.
The key architectural performance issues in large web apps like Facebook are about scalability by clustering and parallelism and caching... usage of proper higher-level languages helps in this (think how pure-functional programming removes shared state and Google's mapreduce for example), while using a lower-level language may give a speedup on single individual machines but makes the architectural problems harder to tackle.
I want to play Free Market with a drowning Libertarian.
For a recursive Fibonacci calculation, implementing the same algorithm in C, Objective-C and Smalltalk took 2.35, 6.60, and 5.69 seconds, respectively (calculating fib(30) 100 times), with about a 50% variation margin on successive runs. The Smalltalk version was not always faster than the ObjC version (it was most of the time; not sure why, probably some weirdness with the Smalltalk code happening to line up with cache boundaries better), so it's safe to consider them roughly the same speed.
It's worth noting that the Smalltalk version, unlike the C and Objective-C versions, will never suffer from integer overflow. Tweaking the benchmark so that it computes fib(47) in the three versions, the timing results are: 50, 130, and 280 seconds, respectively.
The difference is that the Smalltalk version generates the correct answer, while none of the others do. Personally, I'd rather have slow code generating the correct answer, but maybe that's just me. It is, of course, possible to write code in C that would check for overflow (in this case it's relatively easy, you can just test whether the sign bit flipped because you're just adding two positive integers), but returning something that is either an integer or an arbitrary-precision value in C is a bit harder and you'd end up with at least four times as much code to make the C version, and a lot more potential for bugs.
By the way, calculating fib(47) with a sensible algorithm in Smalltalk takes a tiny fraction of a second, highlighting the fact that good algorithms are usually more important than good compilers.
The compiler targets the (GNU) Objective-C ABI, so Smalltalk and Objective-C classes can be used interchangeably (you can, for example, subclass an Objective-C class with Smalltalk and then call the Smalltalk methods from Objective-C). Some of the improvements I've recently made to the Objective-C runtime mean that the compiler can now emit code to do polymorphic inline caching and speculative inlining. It doesn't yet do either, but in benchmarks these reduce the cost of a message send to within a hair of the cost of a C function call. For most uses, Objective-C is already fast enough, so I'll probably only implement these as a profile-driven optimisations and enable them for hot code paths where the message sending overhead is actually important.
I'm giving a talk about this at FOSDEM in the GNUstep developer room next weekend.
I am TheRaven on Soylent News
PHP is an example of a scripted language. The computer or browser reads the program like a script, from top to bottom, and executes it in that order: anything you declare at the bottom cannot be referenced at the top.
This was true in PHP3, but since PHP4, even declaring functions at the bottom of a file, they were still available at the start of a file execution. Everything got compiled in to an intermediate stage before execution.
creation science book
Speed of "Java" and ".Net"? Is it a joke?
No, it's not.
"Java" hangs all the time
No it doesn't.
and the ".Net" code to do a simple task is so convoluted that it is just ridiculous.
No, it's not.
Honestly, you really have no fucking clue what you're talking about, do you?
Really the only time you have to handle assembly in a PC application is when you're implementing a just in time compiler, and it's becoming the fashion to let LLVM do that for you.
That's an interesting combination of overstating and understating the case.
For one thing, your favourite C/C++ compiler likely contains a hand optimized memcpy() routine, down to assembly if it exposes a worthwhile gain, or coded in C with or without intrinsics if it doesn't. Many C/C++ compilers contain hand-optimized floating point routines, even more so in the embedded world. Plus there are many performance libraries out there to handle the heavy lifting in multimedia, mathematics, and encryption, some of which are vendor tuned to the n'th degree. It's been a while since I've used an Intel library, but this is likely one of the breed:
Intel MKL
As for LLVM, I'd say it's more than fashion. The differences in performance characteristics from one micro-architecture to another are nightmares to cope with at the assembly language level. The average tablet computer these days could probably play Kasparov to a draw, and there are still macho programmers out there who think they can do register assignment and live range analysis better than your compiler? Dude, if you've got that much talent, roll up your sleeves and fix the freaking compiler. Hopefully LLVM will solve that old problem of first having to swallow the gcc ast syntax enzyme.
Tautology #1: I can beat my computer at chess => your chess computer sucks (or it's running on your wristwatch).
Tautology #2: I can beat my compiler at coding a non-trivial loop => your compiler sucks.
Unless your goal in life is to win rigged competitions, LLVM is a lot more than a fashion statement.
In today's modern processors you wont gain much performance in assembly. A core2duo simply reads the x86 instructions and converts them to risc and much of the optimizations happen at the compiler and during execution on the fly. You can always gain some speed but its nowhere near what it could do just a decade ago.
What also needs to be taken into account is the costs and time to rewrite years of development work from scratch. Sunken costs drive accountants crazy and threaten the job of any IT manager.
Instead of starting from scratch its better to use tens of millions of dollars of existing code.
Its nice from an engineer perspective but facebook is a corporation and money needs to come first and foremost.
Also assembler can crash a system and freeze it. The point of switching to NT or Unix was the point of stability of using c api's that are managed rather than using Windows95 which had assembly code that could freeze your computer.
http://saveie6.com/