Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Facebook Rewrites PHP Runtime For Speed

timothy posted more than 4 years ago | from the if-not-this-then-something-else dept.

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

cancel ×

295 comments

Sorry! There are no comments related to the filter you selected.

is this being used now? (5, Funny)

Anonymous Coward | more than 4 years ago | (#30969806)

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.

Re:is this being used now? (5, Informative)

Daengbo (523424) | more than 4 years ago | (#30969866)

Try the "Lite" [facebook.com] version. It's much faster, and doesn't have that annoying chat bar.

Re:is this being used now? (0)

Anonymous Coward | more than 4 years ago | (#30970010)

Thanks for the tip. It looks like there are some big things that it's missing, but it works well for the basics. For those trying it out, there's a setting that puts a link/bar at the top of the window that lets you easily switch between the lite and full versions at any time.

hackity hack (0)

Anonymous Coward | more than 4 years ago | (#30970098)

its why its the way it is
now facebook
will faceplant

Nice. (1)

IANAAC (692242) | more than 4 years ago | (#30970144)

I was using touch.facebook.com on my N800, but I like the look/feel of this better.

Thanks!

Re:is this being used now? (1)

ehrichweiss (706417) | more than 4 years ago | (#30970418)

I have to agree fully here. The lite version is missing some things that I like but I can live without them for the speed tradeoff. Only problem I have is that the toolbar for Firefox only points at the main site, otherwise it keeps the bloat way down.

Re:is this being used now? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30969906)

Facebook: bringing together children and the adults who "love" them since 2006!

Facebook company credo: If there's grass on the field, they're old enough to play with your balls.

Re:is this being used now? (0, Troll)

amn108 (1231606) | more than 4 years ago | (#30970114)

Microsoft isn't exactly known for speed either.

Re:is this being used now? (0)

Anonymous Coward | more than 4 years ago | (#30970378)

Microsoft isn't exactly known for speed either.

Context, buddy. What I'm saying is that Facebook tried to improve it, but ended up making it slower. Microsoft does the same thing a lot of them. Ergo, Facebook makes a good candidate for a Microsoft buyout because the two are very similar in that regards. Got it?

PHP versus (0)

Anonymous Coward | more than 4 years ago | (#30969818)

OK, so can we put the "PHP is comparable to JSP and ASP.NET" to rest now?

Screw PHP, I write everything in C (5, Funny)

Anonymous Coward | more than 4 years ago | (#30969824)

PHP is for lazy developers. I develop my webapps in C and I even wrote my own httpd to improve performance.

Re:Screw PHP, I write everything in C (4, Funny)

biryokumaru (822262) | more than 4 years ago | (#30969928)

C is for lazy developers. I develop my webapps in JWASM and I even wrote my own httpd to improve performance.

Re:Screw PHP, I write everything in C (4, Funny)

sopssa (1498795) | more than 4 years ago | (#30969994)

JWASM is for lazy developers. I develop my webapps in machine code and I even wrote my own internet to improve performance.

Re:Screw PHP, I write everything in C (1)

aBaldrich (1692238) | more than 4 years ago | (#30970030)

Programmable chips are for lazy developers. I even invented a new architechture to improve performance.

Re:Screw PHP, I write everything in C (5, Funny)

biryokumaru (822262) | more than 4 years ago | (#30970068)

Servers are for lazy developers. I develop my webapps in my head and I even deliver the pages manually to improve performance.

Re:Screw PHP, I write everything in C (4, Funny)

deniable (76198) | more than 4 years ago | (#30970136)

Excuse me, I'm still waiting for the last page and it's almost bed time.

Re:Screw PHP, I write everything in C (0)

Anonymous Coward | more than 4 years ago | (#30970194)

Screw you, I invented time to allow you to wait for increased performance.

Re:Screw PHP, I write everything in C (5, Funny)

Anonymous Coward | more than 4 years ago | (#30970244)

Webapps are for lazy developers. I sip my coffee, causing a multiply entangled photon to collapse and resolve the location of countless electrons throughout the universe, spurring various exotic species of butterflies to flap their wings a twitch differently, which in turn subtly alters the flow of the viscid gaseous matter in Earth and various other planets, affecting the touch organs of living matter that can feel moving fluid, which messenger or nervous impulses relay to their minds, creating customer-tailored web content for my clients.

Re:Screw PHP, I write everything in C (1)

AmberBlackCat (829689) | more than 4 years ago | (#30970390)

Every time I telnet to your brain, I keep getting something about Chuck E Cheese...

Re:Screw PHP, I write everything in C (4, Funny)

eclectro (227083) | more than 4 years ago | (#30969960)

I develop my webapps in C and I even wrote my own httpd to improve performance.

C is for lazy coders if you ask me. I hand code and tune assembly language programs on an altair 8800 flipping switches on the front panel. As all real programmers should do.

Re:Screw PHP, I write everything in C (0, Redundant)

AikonMGB (1013995) | more than 4 years ago | (#30970166)

I don't know why this has not yet been linked, but... obligatory XKCD reference [xkcd.com]

Aikon-

Re:Screw PHP, I write everything in C (3, Insightful)

Galactic Dominator (944134) | more than 4 years ago | (#30970482)

I don't know why this has not yet been linked

Just taking a shot in the dark here, but I'll attempt an answer. The reason no one else linked to it is because you're the only one who considers it obligatory. Slashdot regulars will know that this type of thread happens on a near daily basis and with all due respect to xkcd there is simply no need to make another tired attempt at karma whoring.

Re:Screw PHP, I write everything in C (0)

Anonymous Coward | more than 4 years ago | (#30970234)

Coding is for lazy people. I create my programs with ICs.

Re:Screw PHP, I write everything in C (3, Funny)

BRSQUIRRL (69271) | more than 4 years ago | (#30970526)

Steve Gibson [grc.com] , is that you [grc.com] ? :)

Re:Screw PHP, I write everything in C (0, Redundant)

TheRaven64 (641858) | more than 4 years ago | (#30970000)

Meh. I write my code in Smalltalk and if it's not fast enough then I hack on the compiler and runtime until it is.

High performance in scripting languages? (5, Insightful)

BadAnalogyGuy (945258) | more than 4 years ago | (#30969846)

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.

Re:High performance in scripting languages? (5, Insightful)

sakdoctor (1087155) | more than 4 years ago | (#30969922)

1. Static HTML
2. PHP
3. ???
4. Rewrite the PHP runtime

Truth is, that step 3 involves a whole load of steps where 90% of the problem will be database bound. Complied languages are not going to the magic solution in a real world situation.

Re:High performance in scripting languages? (4, Interesting)

sopssa (1498795) | more than 4 years ago | (#30970024)

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.

Re:High performance in scripting languages? (1, Informative)

Anonymous Coward | more than 4 years ago | (#30970046)

Not true. When you start using memcache (which FB heavily relies on), the latency of data retrieval drops down below the latency to execute PHP opcode.

PHP has a big problem, it executes scripts from scratch on every request. Every request has to load over and over again same configuration data, even if it comes from memcached -- there is TCP latency involved.

Applications that use regex-based URL mapping to controllers suffer heavily in PHP because on each request the interpreter has to compile the regex and then do the matching.

Instead of preparing all the app specific configuration once upon startup, and use that as process-local data.

Re:High performance in scripting languages? (4, Insightful)

amn108 (1231606) | more than 4 years ago | (#30970310)

Check your facts better next time please.

PHP does not have to execute scripts from scratch on every request. APC cache API transparently caches JIT-compiled PHP script intepretations and these are run instead upon request.

Apache does not have to compile regular expression for mapping each URL request, when you specify RewriteRule directives in virtual server or server context it compiles them (or however else it wishes to cache these) on server startup and that is it. During the entire lifetime of the server, the specified rules are no longer interpreted.

Other than that I agree that the current style of server infrastructure we are "enjoying" can be improved at least 100-fold, database access including.

* Truly persistent (across HTTP requests) user memory is a good step in the right way - extend the lifetime of all scripted objects to persist across entire application lifetime (i.e. forever - servers are not supposed to die)

* Many database requests are so primitive that these could bypass TCP socket layer and benefit from extra speed at the cost of no longer being asynchronious. Most PHP developers use blocking database query APIs anyway, even though non-blocking calls are available.

* Compile scripts and run from compiled cache, preferrably as machine code. Think about environment - all those quad-core datacenters wasting cycles, because programmers are supposedly very expensive. Well, they are not that expensive that when a good team get together they cannot re-think this. They can. If nothing, they should worry about the environment too - it is not cheap.

* Offer asynchronious calls where these make sense (i.e. where they can benefit from hardware parallelization). Those devs who know how to make use of them will be happy to do speed up their applications.

In short, cache everything, whenever you can. Memory is cheap. Cache SQL query strings, cache script compilation output, cache, cache, cache.

Re:High performance in scripting languages? (2, Informative)

Anonymous Coward | more than 4 years ago | (#30970454)

You should check your facts first.

I did not say PHP had to PARSE each script per request -- which would happen without an opcode cacher. It has to EXECUTE the script, opcode cached or otherwise, from scratch on each request.

So there is no way for PHP to hold application data in memory between requests, except by using shared memory or a memcache. Other languages like Python, Java, etc... allow you to instantiate your classes and their data upon startup, and then call methods per request, without having to instantiate all the classes over and over again in each request.

Of course, sometimes you have to, but PHP does not even allow you to pre-instantiate those classes that do not have to.

So on each request, the application has to load its configuration, even if it is stored as PHP array in some config.inc.php. It has to re-evaluate the arrays (construct the array, build hash keys, etc...) even when opcode cached.

Granted, certain important extensions do keep pools of resource handlers between requests, like PDO, memcached, etc...

Also, I did not mention Apache. I said (PHP) applications that map URL patterns to controllers -- aka central index.php that patches URL to controllers and their methods. That is different from Apache rewriting that maps URL patterns to PHP scripts.

Re:High performance in scripting languages? (4, Informative)

Lennie (16154) | more than 4 years ago | (#30970514)

Facebook added to memcache the ability to use UDP instead of TCP. They also changed MySQL so one replication-command from one datacenter to the next would also invalidate what is in memcache on that location.

At some point they have so much traffic from their webservers to their backendsystems, they saturated their internal network and were dropping UDP.

That's the kind of problems/scale they deal with, I'm surprised PHP wasn't their biggest bottleneck before (they did some work on PHP already, but not something like this).

After all Facebook is the second site after www.google.com-search page (which handles 'just' one task) and Google has pretty much a custom-build platform.

Re:High performance in scripting languages? (1, Informative)

Anonymous Coward | more than 4 years ago | (#30970614)

That's the kind of problems/scale they deal with, I'm surprised PHP wasn't their biggest bottleneck before (they did some work on PHP already, but not something like this).

It is easy to add new front end servers, they all connect to the same pool of backend resources. Backend coordination is the most fragile point in the life of a request. You can't just add backends, which they realized with memcached, adding more did not help.

However, if they used a faster language, which is the point of TFA, they would have to use LESS front end servers and with that spare the money.

Because, the backend is already working as fast as possible -- in terms of programming language used -- native on CPU. I guess the backend could get faster only if they reimplemented MySQL and memcached, taking out the functionality that is not required, or adding critical new functionality. Oh, wait... they did.

So that leaves removing PHP from the chain.

Re:High performance in scripting languages? (1)

amn108 (1231606) | more than 4 years ago | (#30970332)

You are however, dead on on the loading application configuration (including libraries!) once as process local memory, the way "normal" client software functions.

Re:High performance in scripting languages? (3, Insightful)

gbjbaanb (229885) | more than 4 years ago | (#30970228)

Complied languages are not going to the magic solution in a real world situation.

whilst that's perfectly true, its only true to a point. Lots of people run eaccelerator or apc on their PHP sites, simply to improve performance. If these pre-compile caches didn't do anything for performance then you'd be totally right, but as they do, you've got to appreciate that replacing the PHP with a compiled language will make a significant difference.

as always, don't guess where performance problems live, measure them. Often you'll be surprised, especially as load increases.

Re:High performance in scripting languages? (0)

Anonymous Coward | more than 4 years ago | (#30970506)

1. Static HTML
2. PHP
3. ???
4. Rewrite the PHP runtime

Truth is, that step 3 involves a whole load of steps where 90% of the problem will be database bound. Complied languages are not going to the magic solution in a real world situation.

I think that It depends upon where the bottlenecks are. Traffic that is reads only can be very parallel and shouldn't be "database" bound. There are ways to get very high performance (in terms of transaction throughput) for write traffic as well. It sounds to me like they want to get rid of an obscene number of PHP servers. This would be profit (cooling, power, hardware, licenses).

Those interested may wish to look at all the previous work on compilers (e.g. hotspot java), or carve out another solution by identifying and coding the heavy weight transactions in a more efficient way altogether.

Re:High performance in scripting languages? (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30969930)

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.

Three sources of scripting language inefficiency (5, Insightful)

tepples (727027) | more than 4 years ago | (#30970026)

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:

  • Swapping: More dynamic languages tend to use more general data types, which incur memory overhead. For instance, they might use UTF-16 strings instead of 8-bit strings with an assumed encoding. Or they might use double-precision floating point instead of short integers for large arrays. This might cause a program to run out of RAM and fail over to the disk more often.
  • Garbage collection: This covers ways of determining which resources are no longer in use by any active part of the program. Python, Objective-C, and lately C++ primarily use an incremental garbage collection method called reference counting, which keeps track of the number of things that "know about" an object. But some other language interpreters use only tracing garbage collection, which in the naive form causes the application to pause and make a list of all live objects once memory allocations exceed some amount. This will cause a CPU spike.
  • Blocking: A lot of the APIs available to programs in scripting languages don't have well-known non-blocking versions. For example, a host name lookup might freeze the program until it finishes. The only way to work around these is to start a thread. This will cause a pause with 0 CPU and 0 disk.

Re:Three sources of scripting language inefficienc (0)

Anonymous Coward | more than 4 years ago | (#30970132)

Flaky UIs - click on a button and nothing happens. Or things not drawing properly. These are my observations.

A refurb machine is about a third the cost of a new machine - even cheaper than the cheapo Acers.

Interesting list of possible causes. I don't care what the reasons are - scripting languages are not appropriate for large applications with GUIs. And as far as time savings for development is concerned, there are these things called "frameworks" - like gtk+ and Qt - that can speed up development to be just as fast as the scripting languages.

JavaScript (3, Insightful)

tepples (727027) | more than 4 years ago | (#30970416)

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?

Re:JavaScript (3, Interesting)

drinkypoo (153816) | more than 4 years ago | (#30970612)

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:Three sources of scripting language inefficienc (1)

amn108 (1231606) | more than 4 years ago | (#30970360)

with flaky UIs.

Citation needed.

Run Eclipse.

Re:High performance in scripting languages? (0)

Anonymous Coward | more than 4 years ago | (#30970050)

Lol wut? You must be a computer science genius!

I like to use refurbished/recycled machines; which means that I'll have an old P4, 512M RAM and a slow bus.

So its obvious you don't do any of this professionally then?

Assembler is High Performance (5, Funny)

Murdoch5 (1563847) | more than 4 years ago | (#30969884)

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.

Re:Assembler is High Performance (4, Insightful)

erroneus (253617) | more than 4 years ago | (#30969978)

Actually, that isn't necessarily true. It might be true in a linear sense, but when it comes to juggling different threads and the like, assembly language as I knew it wasn't all that capable of describing the process all that well. Assembly language is a go-cart with rocket boosters.

I would truly like to see an assembly language revival though. I truly would. It would be a return to sensibilities in programming. It would be a return to being careful with memory usage with improved focus on small efficient programming. It would be a really good thing. I just don't see it happening.

The purpose for these more complex languages is about being able to more symbolically describe the processes to be executed by the machine. Assembly language was some of the worst about that -- if there wasn't a very detailed set of comments for nearly every line of code, it would be nearly impossible to follow in source. These more complex languages will always have their place and purpose. Trying to make them more efficient is a good and useful thing. Now if we were talking about writing the PHP interpreter in assembler, I'd say you had a winner compromise.

Assembly language revival (1)

tepples (727027) | more than 4 years ago | (#30970052)

I would truly like to see an assembly language revival though.

The revival is here. It is called NESdev [nesdev.com] . It's just not for making PC programs because the processes to be executed on a PC tend to be much more complex.

Now if we were talking about writing the PHP interpreter in assembler, I'd say you had a winner compromise.

You'd have to do so over and over for x86, x86-64, ARM, PowerPC, and other architectures on which PHP runs. That's why these interpreters are most often written in C, with occasional reference to the assembly language code that the compiler generates. 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.

Assembler? Really? (5, Interesting)

Atmchicago (555403) | more than 4 years ago | (#30970080)

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.

Re:Assembler? Really? (0)

Anonymous Coward | more than 4 years ago | (#30970312)

Assembly language isn't platform-independent. It's really easy to screw up and hard to optimize.

You wouldn't necessarily use it for your app, but having developers understand what's going on at a lower level, can help even when using higher level languages.

Perhaps this won't help with developers making VB-written corporate apps, but at the scale of Facebook, knowing a larger part of the whole stack helps you makes things run better. And since you don't necessarily know where you're working in your career, covering it in school (or doing it yourself, if self-taught), could be useful.

Even if you don't ever use it, personally I think knowledge and exploration are their own rewards, regardless of any "useful" benefit.

Re:Assembler is High Performance (0)

Anonymous Coward | more than 4 years ago | (#30969986)

I believe you mean "assembly."

Complexity and cost of embedded approach (3, Interesting)

tepples (727027) | more than 4 years ago | (#30970072)

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.

Re:Complexity and cost of embedded approach (1)

Murdoch5 (1563847) | more than 4 years ago | (#30970102)

true, but on the other hand most of what I've seen is that the embedded developers can program the higher level languages with more care anyway. So throw a bunch of embedded developers at a sever level project and you'll probley end up with a faster solution.

In no way I'm I trying to imply there aren't great desktop level programs because I know a few that are top notch. On the other hand it is cheaper to hire the dime a dozen desktop guys and coops and just get it working and never speak of it again.

Re:Complexity and cost of embedded approach (3, Interesting)

CptPicard (680154) | more than 4 years ago | (#30970624)

true, but on the other hand most of what I've seen is that the embedded developers can program the higher level languages with more care anyway

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)

Re:Assembler is High Performance (2, Interesting)

Anonymous Coward | more than 4 years ago | (#30970138)

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.

Writing the single biggest bottleneck in asm (2, Insightful)

tepples (727027) | more than 4 years ago | (#30970470)

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.

Re:Assembler is High Performance (0)

Anonymous Coward | more than 4 years ago | (#30970192)

People, this comment is a joke or written by a moron. It is not insightful and whoever modded it up should be ashamed.

Re:Assembler is High Performance (1)

neoform (551705) | more than 4 years ago | (#30970392)

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.

Yeah, us assholes with +10 years experience developing web applications are just a bunch of "noobs" because we never needed to learn Assembler or C. Enjoy spending two weeks developing what would take me an hour.

Sounds like a fork... (1)

bogaboga (793279) | more than 4 years ago | (#30969900)

...though traditional forks do not get started after "friendly" meetings. But it still sounds like one; which is not a very good thing in my opinion.

What they (Facebook) should have done is to combine resources with the PHP folks, then later release a "new" PHP version with this new engine.

This would be dubbed progress by the majority here.

By the way, where are the stats that show how wanting the current PHP engine's speed still is? I want to see some serious comparison.

Re:Sounds like a fork... (0)

Anonymous Coward | more than 4 years ago | (#30970094)

What they (Facebook) should have done is to combine resources with the PHP folks, then later release a "new" PHP version with this new engine.

And which version would that be? PHP 7? Coming to your nearest web server in 2021!

C'mon. 5.3 was supposed to be out in fall 2009. It came out late spring 2010. It will be another year (from that date) until all the distros start supporting it in their stable repos. PHP 6 won't be ready for year(s) to come. What "new" PHP version are you talking about?

The only obvious thing is to screw it and fork on your own.

Better yet, drop that crap of PHP altogether, but I guess FB has invested too much into PHP already so rewriting everything in another lang (Python for instance) would be too expensive.

Or maybe rewriting the application in a better performing language might be cheaper than running thousands of servers for PHP now, because it would reduce the number of required front-end application servers greatly, which translates to money spared to invest into rewriting in a new language.

So is it a fork or isn't it? (3, Insightful)

erroneus (253617) | more than 4 years ago | (#30969918)

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?

Re:So is it a fork or isn't it? (1)

maxume (22995) | more than 4 years ago | (#30970174)

They tend to work with the Apache Software Foundation:

http://developers.facebook.com/opensource.php [facebook.com]

I would imagine the licensing for this will be similar.

And it is probably best described as an implementation; if they start adding language features not present in other PHP interpreters, then it becomes a fork (lots of languages have multiple implementations, for instance, C, C++, C#, Java, Python, Perl, Ruby, etc.).

Re:So is it a fork or isn't it? (1)

Lennie (16154) | more than 4 years ago | (#30970608)

I think it will use the same license as regular PHP, as it's based on regular PHP. Of the projects they adapted they all used the same license.

HyperPHP, or HPHP (4, Interesting)

hkz (1266066) | more than 4 years ago | (#30969940)

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.

Dinosaur (0)

Anonymous Coward | more than 4 years ago | (#30969942)

May be presumptuous, but, if it is better and liberally licensed; one would be foolish not to use it. This happens in all industries, someone re-invents the wheel and does it better, faster, cheaper with newer techniques, and the dinosaur quickly disappears. If the article is correct, Facebook is giving the dinosaur a chance to avoid extinction.

Misleading Summary (surprise!) (5, Informative)

Anonymous Coward | more than 4 years ago | (#30969946)

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.

Re:Misleading Summary (surprise!) (0)

Anonymous Coward | more than 4 years ago | (#30970032)

Did they have a play with the likes of Eaccelerator (http://eaccelerator.net/) first? (DNRTFA)

Re:Misleading Summary (surprise!) (2, Informative)

paziek (1329929) | more than 4 years ago | (#30970048)

If thats so, then they are reinventing wheel, since there is already PHP compiler available, with is also open source: http://www.roadsend.com/home/index.php [roadsend.com]

Re:Misleading Summary (surprise!) (1)

gmuslera (3436) | more than 4 years ago | (#30970532)

Maybe the round wheels don't fit well in what they are doing, how they are using PHP, as dynamic language the approach that was taken in roadsend could bump against some core practice in Facebook and thats why they must use another approach to fit into that scheme.

Compile (1)

hey (83763) | more than 4 years ago | (#30969962)

Would be nice of there was an option to compile it to say .phpc files like Python. Would be a nice thing for Perl too.

Is compiled PHP even possible? (1)

RJabelman (550626) | more than 4 years ago | (#30970078)

PHP is a weakly typed language, so for any given operation, the interpreter will have to check the types of the operands and then figure out which operation(s) on the CPU to call to solve it. Also, as it's dynamic, the operand may not even exist yet.

So, even if you did write a compiler for PHP, instead of the PHP interpreter doing the type checking and figuring out what to do, you'd have to compile in some runtime checks to implement the same logic that's currently in the interpreter for every single operation. This doesn't sound to me like it'll be significantly faster (Although I'll freely admit it's just a gut feeling.)

So, a question to the room - if it's even possible, is there any advantage in compiling a dynamic weakly typed language to native code?

Re:Is compiled PHP even possible? (1)

TheRaven64 (641858) | more than 4 years ago | (#30970106)

I've written a static compiler for Smalltalk, so I'm pretty sure it's possible for PHP.

Re:Is compiled PHP even possible? (1)

RJabelman (550626) | more than 4 years ago | (#30970124)

Ah, that's interesting. What was performance like compared to the interpreted version?

Re:Is compiled PHP even possible? (1)

TeknoHog (164938) | more than 4 years ago | (#30970278)

PHP is a weakly typed language, so for any given operation, the interpreter will have to check the types of the operands and then figure out which operation(s) on the CPU to call to solve it. Also, as it's dynamic, the operand may not even exist yet.

I think Python has basically the same problem. Compiled .pyc files are actually bytecode, like Java. They save the time of the initial interpretation, but do not make the actual execution faster. Then there is also Psyco [wikipedia.org] .

Re:Is compiled PHP even possible? (1)

maxume (22995) | more than 4 years ago | (#30970522)

Python has strong, dynamic typing. The dynamic part makes it difficult to compile.

Projects like Cython and Shedskin each compile a less dynamic subset of Python.

Re:Is compiled PHP even possible? (1)

maxume (22995) | more than 4 years ago | (#30970314)

Python (and Java) compile source files into an intermediate byte code that a virtual machine executes. The byte code does not have to be run through a parser, so overall execution is faster.

Re:Is compiled PHP even possible? (1)

kobaz (107760) | more than 4 years ago | (#30970428)

'Overall execution' being faster is a misnomer. The change to bytecode only improves startup time, but what counts is runtime speed. Many of the modern interpreted languages: php, perl, python, ruby, etc, have a just in time compiler that will internally bytecodeify your raw source before execution. Assuming a straight non-optimizing JIT, The actual executing part, running the application will have the same speed running raw source or bytecode.

In the case of an optimizing JIT, then you gain some speed in runtime. But many implementations of said modern scripting languages lack the optimizing part.

Re:Is compiled PHP even possible? (1)

FlyingGuy (989135) | more than 4 years ago | (#30970484)

Not just possible but my WAG is that probably not that hard. Yes PHP is dynamic and variables are typed at runtime, but the logic analyzer and parser would figure all that out and then the resulting machine code would be type appropriate.

Internally all interpreters of loosely typed languages have to figure out what the they types are before it can perform the requested operation. One way to speed up loosely type languages is to remove the looseness and force variable and type declaration. This simplifies matters greatly as the interpreter now knows exactly what do do with the operation and does not waist valuable cpu cycles figuring it all out beforehand.

Re:Compile (1)

Linker3000 (626634) | more than 4 years ago | (#30970400)

http://eaccelerator.net/ [eaccelerator.net]

"eAccelerator is a free open-source PHP accelerator, optimizer, and dynamic content cache. It increases the performance of PHP scripts by caching them in their compiled state, so that the overhead of compiling is almost completely eliminated. It also optimizes scripts to speed up their execution. eAccelerator typically reduces server load and increases the speed of your PHP code by 1-10 times. "

Was revealed 3 weeks ago by insider (5, Informative)

diretalk (1712478) | more than 4 years ago | (#30969966)

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 [therumpus.net]

Re:Was revealed 3 weeks ago by insider (1)

gyepi (891047) | more than 4 years ago | (#30970160)

Moreover, was featured on Slashdot [slashdot.org] a week ago! But then again the Chuck Norris part of the story captivated more the ./ crowd.

One man effort (3, Insightful)

hey (83763) | more than 4 years ago | (#30969970)

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?

VM's (2, Interesting)

MattBD (1157291) | more than 4 years ago | (#30969996)

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.

Re:VM's (1)

BadAnalogyGuy (945258) | more than 4 years ago | (#30970022)

How are you differentiating between a virtual machine and a runtime?

Re:VM's (1)

MattBD (1157291) | more than 4 years ago | (#30970066)

Really I mean a runtime, I guess. I do think the JVM is somewhat misnamed.

How about... (0, Redundant)

Hurricane78 (562437) | more than 4 years ago | (#30970012)

...rewriting your site, to use a real language, instead?

I had to use PHP for 4 years, and I’d rather die than to do it again. (Same thing with the Internet Explorer.)
Get yourself a real language. One that makes sense! One with an actual spec. One that makes sense! (Has to be said twice!)
Even Python would make more sense. Java would be a professional choice. And if you want to get futuristic, I’d recommend Haskell. ^^
Everything is better than PHP. (Ok, except perhaps Intercal/Malbolge/Piet. Perhaps...)

PHP is slow (check), now what.... (4, Interesting)

Ritz_Just_Ritz (883997) | more than 4 years ago | (#30970062)

Why not just stash your farm of slow php systems behind some heavy duty caching appliance(s)?

Something like aicache might fit the bill.

Re:PHP is slow (check), now what.... (3, Insightful)

jimicus (737525) | more than 4 years ago | (#30970146)

Why not just stash your farm of slow php systems behind some heavy duty caching appliance(s)?

Something like aicache might fit the bill.

When your application is with each iteration generating more content dynamically than it was before (and you want to continue down that route), the benefit of caching starts to drop quite quickly.

Re:PHP is slow (check), now what.... (2, Insightful)

slim (1652) | more than 4 years ago | (#30970178)

Facebook does as much caching as it can - I mean, they're not daft. They're probably the world's greatest experts on large scale MySQL + memcached.

But sometimes cached data isn't good enough. Facebook users expect their statuses, messages and comments to reach their friends within seconds.

Facebook's architecture is the problem, not PHP (1)

QuietLagoon (813062) | more than 4 years ago | (#30970096)

Facebook is dependent upon a scripting language, and then Facebook complains about speed? Facebook's real problem here is their short-sightedness. Instead of putting a band-aid on the current architecture via some sort of acceleration for PHP, Facebook should re-architect their site with a structure and language that is capable of handling the current and future loads.

.

I am sure we will be hearing all about how successful this project is, but is the auccessful application of a band-aid really the long-term solution Facebook needs?

Re:Facebook's architecture is the problem, not PHP (0)

Anonymous Coward | more than 4 years ago | (#30970258)

Do you even build websites?

Re:Facebook's architecture is the problem, not PHP (1)

QuietLagoon (813062) | more than 4 years ago | (#30970318)

Yes. I've built some, and I've architected a few more. Facebook is in reactionary mode with regards to their website performance. They need to get proactive.

Re:Facebook's architecture is the problem, not PHP (1)

the eric conspiracy (20178) | more than 4 years ago | (#30970274)

If you read the article, it sounds like it might be more than just an accelerator.

Re:Facebook's architecture is the problem, not PHP (3, Interesting)

pmontra (738736) | more than 4 years ago | (#30970276)

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

Re:Facebook's architecture is the problem, not PHP (2, Insightful)

kobaz (107760) | more than 4 years ago | (#30970508)

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.

Gotten (0, Flamebait)

heffrey (229704) | more than 4 years ago | (#30970404)

What the hell kind of word is gotten?! Can't you people learn the language?!!

Re:Gotten (2, Funny)

Snarf You (1285360) | more than 4 years ago | (#30970498)

I'm guessing you haven't gotten laid recently.

They should spend more on the upload tool (3, Interesting)

crossmr (957846) | more than 4 years ago | (#30970520)

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.

Old news (0)

hmckee (10407) | more than 4 years ago | (#30970566)

Not that surprising if you've read the book "The Accidental Billionaires" [amazon.com] . They specifically mention that there is one person dedicated to writing a PHP compiler and compiling all Facebook PHP.

Also, I don't understand why they don't use one of the currently available PHP compilers, phc [phpcompiler.org] or Roadsend [roadsend.com] . It's possible they started their initiative earlier, but they should have announced it and possibly prevented some duplicate work.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>