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!

The Environmental Impact of PHP Compared To C++ On Facebook

Soulskill posted more than 4 years ago | from the efficiency-is-overrated dept.

Earth 752

Kensai7 writes "Recently, Facebook provided us with some information on their server park. They use about 30,000 servers, and not surprisingly, most of them are running PHP code to generate pages full of social info for their users. As they only say that 'the bulk' is running PHP, let's assume this to be 25,000 of the 30,000. If C++ would have been used instead of PHP, then 22,500 servers could be powered down (assuming a conservative ratio of 10 for the efficiency of C++ versus PHP code), or a reduction of 49,000 tons of CO2 per year. Of course, it is a bit unfair to isolate Facebook here. Their servers are only a tiny fraction of computers deployed world-wide that are interpreting PHP code."

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

php is bad for the environment (0)

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

All the more reason to use perl! notcop

Re:php is bad for the environment (5, Insightful)

Pieroxy (222434) | more than 4 years ago | (#30504262)

Seriously, is somebody taking seriously the 1 to 10 ratio of the story?

I mean, maybe raw execution of pure code is going 10 times slower in PHP than C++ (ouch, I didn't know that) but even then, it's far from representing the same ratio when talking about a number of servers. You have to take into account all other parameters (disk access, network, IO, etc... Those aren't 10 times as slow in PHP one would guess).

I would be astonished if this ratio is close to be the truth. Does anyone have any insight/information on this?

Re:php is bad for the environment (4, Informative)

tixxit (1107127) | more than 4 years ago | (#30504324)

Exactly. He using stats from benchmark results from pure number-crunching tests. Seriously, here are the tests: pidigits, reverse-complement, regex-dna, k-nucleotide, n-body, fasta, binary-trees, fannkuch, spectral-norm, mandelbrot. Yep. Looks like stuff a web page would do... The biggest bottle neck is probably data access, in which case the language really doesn't make much, if any difference.

Re:php is bad for the environment (0)

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

The biggest bottle neck is probably data access, in which case the language really doesn't make much, if any difference.

Not true, e.g. I/O operations in Perl are faster than in PHP.

P.S. in pure number crunching C++ is thousands of times faster than PHP.

Re:php is bad for the environment (1)

sznupi (719324) | more than 4 years ago | (#30504434)

"if any difference" is going slightly too far probably? There should be some, if only because of lower CPU utilization (plus possibility of using much more efficient, even if slower, CPUs?), and hence somewhat lower power usage (including cooling). However slight. But yeah, certainly nothing close to 10:1.

Re:php is bad for the environment (3, Interesting)

postbigbang (761081) | more than 4 years ago | (#30504614)

Some optimized assembler would make a difference (ducks).

But network latencies, number of sustainable TCPs per session, db latency, weird table lookups (even arp drags a server down when you have 20K+ connects) are all at issue. Add in various dirty caches, file locks/unlocks and other OS machinations, and life can be tough for any app written in anything.

Then there are the backup servers, the availability servers, the DNS servers, the coffee servers, it just gets bogged down. A 10:1 efficiency claim is probably just language fanboy-ing..... or a consulting job looking for a spot marked X.

Certainly it's nice to be green... but using better optimization tricks (like GCD) for multi-cores is bound to help.... tickless kernels..... SSDs..... C++ wouldn't be my first pick.

Re:php is bad for the environment (3, Funny)

Barnett (550375) | more than 4 years ago | (#30504382)

Seriously, is somebody taking seriously the 1 to 10 ratio of the story?

Only 1 to10 ?!? I would have thought 1 to 100.

Re:php is bad for the environment (1)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#30504446)

In addition to that, quite dodgey looking, ratio, you have to take into account why PHP was being used.

Even if the environment were a complete non-issue, nobody would pay substantial amounts of perfectly good money to keep ~20,000 servers humming. This tells us that either A) using PHP is substantially cheaper on the development side than using C++ would be(for this particular application or B) somebody used PHP long ago, because this facebook thing is just a quick hack, right? and now it is cheaper to live with their legacy than to break free of it.

While servers have a direct environmental impact that is pretty easy to measure(electricity consumption/year * nastiness of local form of electricity production), "development" also has one. The reason that development is expensive is that it involves forking over large sums of money to pay programmers and managers and such. With the occasional exception of that-weird-dude-who-telecommutes-from-his-solar-powered-eco-commune, pretty much every dollar spent on programmers and managers ends up being spent either on A) living a lavishly energy-intensive western lifestyle(if your dev team is local) or B) rapidly and dramatically increasing the already enormous population of the developing world's appetite for energy intensive lifestyles.

If you want to play the "OMG-environment" game, you can't just focus on the stuff that is trivial to measure and ignore the hard stuff.

Re:php is bad for the environment (1)

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

It isn't even clear that they measured the trivial stuff, they just took a guess (If Facebook cared to, they could probably come up with a slightly better estimate of their PHP overhead).

Re:php is bad for the environment (5, Insightful)

Znork (31774) | more than 4 years ago | (#30504642)

"development" also has one.

Not to mention clients. 20K servers is nothing compared to the millions of clients drawing higher power due to running looping flash commercials.

people use PHP? (1, Insightful)

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

I remember when it was the script kiddie's substitute for cgi-perl. What does it offer from a theoretical and engineering PoV, apart from a Visual Basic learning curve?

Re:people use PHP? (4, Informative)

jsdcnet (724314) | more than 4 years ago | (#30504454)

It's got a very rich set of features that are aimed straight at making web development dead simple. The syntax is fairly straightforward and familiar, being a typical mishmash of shell scripting, C and perlisms. It was built from day one to integrate with Apache, it's not a nasty bolt-on hack like mod_perl. It's in-process so there's no startup overhead like with CGI. I've been using it on some pretty large web sites for years and it's never let me down.

Re:people use PHP? (0)

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

It's got a very rich set of features that are aimed straight at making web development dead simple.

PHP has very few web-related features. It can handle HTTP headers, cookies, sessions, GET and POST, escaping for HTML and URLs... and that's about it.

The syntax is fairly straightforward and familiar

Straightforward, apart from all the stupid special cases.

It was built from day one to integrate with Apache, it's not a nasty bolt-on hack like mod_perl.

mod_perl is neither "nasty" nor "bolt-on" nor a "hack".

Re:people use PHP? (5, Insightful)

Lord Byron II (671689) | more than 4 years ago | (#30504542)

I use it because I can code up relatively fast, relatively secure dynamic websites in a very short amount of time. I can install it on a webserver in seconds and it integrates beautifully with Apache and MySQL. Maybe there is a better solution out there, but PHP has always done what I need it to and I've never had a problem with it. It's never given me a reason to look elsewhere.

What I don't understand is all of the PHP-haters out there. Really, who cares if it is "the script kiddie's substitute for cgi-perl"? Isn't the proper measure of a tool if it does what you need it to and not who else uses it?

eh (1)

unity100 (970058) | more than 4 years ago | (#30504554)

as with ALL things invented by humans and which can be used to create other stuff, php has grown over the 'homepage tools' it was initially created to be. now not only it has a huge set of functions inside it to create full fledged applications, but through server modules it can also acquire an immense sea of functionality that can be used to perform innumerable other tasks. it is pretty much at the point where it can take over some desktop applications too, with the right server setup and modules - with some scripts and the proper modules you can even do a fair amount word processing in any web front app. to the extent of being able to do drag&drop editing/drawing and pdf creation and so on. of course not quite as efficient as a native desktop program, however, regardless, you can.

just check php functions in php.net, and check some modules apache can use to supplement php. there is QUITE a lot.

Would be a non-issue (0)

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

if there was a run-time compiler solution for PHP!

Assumes PHP Dev Effort = C++ Dev Effort (5, Funny)

VampireByte (447578) | more than 4 years ago | (#30504240)

What about all the cycles compiling and debugging C++ code? Or all the trees torn down for C++ books? Or the environmental impact of C++ developers? I mean, have you ever had to share a cube with one of them? Pheewww.

Re:Assumes PHP Dev Effort = C++ Dev Effort (4, Insightful)

LBt1st (709520) | more than 4 years ago | (#30504304)

I know your being funny but you've got a good point. Developing and maintaining C++ code is not like developing and maintaining PHP script. Which of course is why we have PHP to begin with. It's designed for the web and ease of implementation. Sure C++ would be faster running but not necessarily more efficient in terms of dollars.

Re:Assumes PHP Dev Effort = C++ Dev Effort (3, Funny)

sznupi (719324) | more than 4 years ago | (#30504456)

Have no fear, turning devs into disposable resources will ensure bright future to efficiency being judged only in hardware terms.

Incompetent developers require more servers (3, Interesting)

Colin Smith (2679) | more than 4 years ago | (#30504664)

It's a phenomenon we have also noted.

Sure C++ would be faster running but not necessarily more efficient in terms of dollars.

I think you'll find that the servers come out of the operational budget, not the development one. So the costs of running 10x more servers don't factor into development effort. The costs should of course be charged back to the dev teams.
 

c++ is 'write-only' code (1)

TheGratefulNet (143330) | more than 4 years ago | (#30504392)

it sure seems to be, the way a lot of people write it. write it once and hope you never have to read it since its impossible to figure out what they intended. ever read someone's c++ code? has it been a good experience?

Re:c++ is 'write-only' code (1)

ckaminski (82854) | more than 4 years ago | (#30504472)

Yes, I have. And it ranges the gamut from horrible to beautiful.

What C++ has always lacked, and PHP, Java and others do not, is a bundle of standard libraries that let you do things like process XML, talk to databases, and make templating EASY.

That's it. php does the same things C++ does, but go one beyond and add a rich library and of course, the ability to skip the "compile" step in the write -> compile -> test

Re:c++ is 'write-only' code (5, Insightful)

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

What C++ has always lacked, and PHP, Java and others do not, is a bundle of standard libraries that let you do things like process XML, talk to databases, and make templating EASY.

That's it. php does the same things C++ does, but go one beyond and add a rich library and of course, the ability to skip the "compile" step in the write -> compile -> test

I agree with you, but there's one small thing I don't get.

Faced with this piece of information, someone thought the logical thing to do was to, er, write an entirely new language?

Re:Assumes PHP Dev Effort = C++ Dev Effort (1)

ilguido (1704434) | more than 4 years ago | (#30504506)

Or the environmental impact of C++ developers?

Are you assuming that C++ developers don't live when they're not coding?

Re:Assumes PHP Dev Effort = C++ Dev Effort (0)

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

OMFG zombies!

Ridiculous (3, Insightful)

SashaM (520334) | more than 4 years ago | (#30504242)

That's a ridiculous way to analyze it. What about the environmental impact of the extra time required to write the same functionality in C++? What about the impact of whole classes of C++ bugs that don't exist in C++ (and, perhaps, vice versa) with the downtime or security breaches resulting from them? Or a hundred other ways in which writing all that software in C++ would be different of which I can't think at the moment?

Re:Ridiculous (5, Funny)

Sygnus (83325) | more than 4 years ago | (#30504270)

What about the impact of whole classes of C++ bugs that don't exist in C++

I've spent many a sleepless night worrying about C++ bugs that don't exist in C++. I'm glad I'm not alone.

Re:Ridiculous (0)

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

What is ridiculous is that you are comparing the cost of the extra time programming in a single PC (okay, let's say 10 PCs) with the cost of maintaining 25000 servers all year when much more efficient languages (it doesn't have to be C) require much less horsepower and could suffice with 5.000 or less, as if they were on the same league.

Re:Ridiculous (1)

betterunixthanunix (980855) | more than 4 years ago | (#30504376)

"What about the environmental impact of the extra time required to write the same functionality in C++?"

Should be about equal to the environment impact of maintaining the PHP language itself; in fact, it is likely to be less than that, since there would be no need to maintain the actual interpreter, but only duplicate some functionality. This is really a one-off, and the libraries could be reused by thousands of enterprises.

Bugs and security breaches do not cause any more CO2 emission than bug-free code, so I do not really see your point in bringing them up. The other differences in development are pretty minor, since PHP derives its programming model from C.

Re:Ridiculous (1, Insightful)

Taur0 (1634625) | more than 4 years ago | (#30504420)

That's not an environmental impact at all. Hardly. What you're asking is: "What's the environmental impact of employing more programmers?" Sure, let's say worst-case, facebook hires programmers that would have got another job elsewhere, that other company must now hire different programmers and it trickles down eventually until some people who were going to be unemployed get a job programming somewhere. Okay, so now those people have a job. Let's ignore the fact that you're essentially saying that we should cut down emissions by making people unemployed. It's true that having a job will probably cause them to contribute a bit carbon emissions than if they were unemployed, but studies have shown that the large amount of our personal environmental impact is non-reducable (around 50%), even if you were to go homeless and live on the streets, we might see maybe a 10-20% increase of their personal carbon emissions. For even a couple dozen programmers that's nothing compared to running 20,000 more servers per year and that's absolute worst case. What you're arguing is the economic cost for facebook, whether it's worth all the man-hours to make their severs more efficient. That's debatable, but if you want an example, you just have to look at Google where they have a team that is devoted to increasing efficiency, despite the fact that they are already running some of the most power-efficient servers in the country.

Re:Ridiculous (0)

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

What about the environmental impact of the extra time required to write the same functionality in C++?

100 guys programming in C++ on their desktops is nothing compared to 30000 servers. So that doesn't make a lot of difference.

Re:Ridiculous (0)

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

You're missing the biggest benefit. If they were coding in C++ then they would only be using about 100 servers and workstations as they still wouldn't have got it running, thus saving 29,900 servers. Then there's probably millions of clients which could have been turned off too.

That's poor reasoning (0)

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

Very poor reasoning. What about the increased number of developers and their systems needed when using a lower level language. I also wonder what the impact of their servers compared to the impact of all of the user systems executing java script client side? Could that JS code be optimized to make the client side functions greener? Also, maybe investing time in optimization of the current code base to reduce server load would be a benefit. First Post ?

Re:That's poor reasoning (0)

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

What's poor reasoning about it? The summary supposes 25000 servers running PHP. If more efficient C++ code lets them reduce the number of servers by 10% that's a fairly significant reduction of energy consumption.

Lets say for the sake of argument that the energy requirements of the servers are equal to the energy requirements of the desktops used for code production. We'll neglect other energy requirement of the programmers by assuming those would be temporary for the most part and nonexistent after development of the more efficient code was complete.

Are they developing the code on 25000 desktop computers 24 hours a day for a year? No? 2500 desktop computers 24 hours a day for a year? Even fewer desktops?

Lets say they're developing more efficient C++ code for the servers on 250 desktops, 24 hours a day, for a year. Those 250 desktops would use 1% of the energy that the 25000 servers use. If after a year they came up with more efficient C++ code that allowed them to use only 22500 servers they'd have reduced their overall server energy consumption by 10% by expending 1% of their total energy consumption.

Seems a fairly reasonable tradeoff. Would probably be reasonable at a 5% reduction. If they only got a 2% or 3% reduction it'd be questionable. Below that it'd be pointless.

Re:That's poor reasoning (1)

moz25 (262020) | more than 4 years ago | (#30504650)

Considering a minimum cost per server in the range of $500-1000, 2500 servers equal between 1.25 and 2.5 million dollars...

That's certainly a budget for which you could get some C++ programmers... ?

Re:That's poor reasoning (1)

moz25 (262020) | more than 4 years ago | (#30504608)

Ah, but these points are not hard to counter.

1. Needing more developers: more jobs for skilled programmers, which is *good*
2. More developer systems: negligible compared to server farm reduction.
3. Javascript client-side: already being optimized (see Chrome stories)

Languages not for everyone (3, Insightful)

Darkness404 (1287218) | more than 4 years ago | (#30504264)

The thing that this article fails to see, is that some languages aren't for everyone. A PHP programmer who turns out good PHP code isn't going to magically make the same level of code for C++. It also doesn't see that Facebook can't be down for longer than an hour at most, otherwise risk user outrage. After all, they have many, many, many users and for it to go down for a day would be akin to Google going down for a day or so. The difference being that if Google is down for a day, most users can use Yahoo, Bing, Live, WolframAlpha, etc. to search. Not every Facebook user has a MySpace.

Re:Languages not for everyone (4, Funny)

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

A PHP programmer who turns out good PHP code

The Easter Bunny, Santa Claus, a PHP programmer who turns out good PHP code, and Steve Balmer are in the four corners of a room. In the center of the room is a chair. Who throws the chair first?

Steve Balmer, because the other three don't fucking exist!

Re:Languages not for everyone (5, Insightful)

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

> a PHP programmer who turns out good PHP code

Yeah, that'd be me. Hi! We do exist, and there are plenty of us.

Granted, we tend to be outnumbered 100:1 by the PHP programmers who produce complete crap. The same is probably true of nearly any language.

Re:Languages not for everyone (3, Funny)

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

A PHP programmer who turns out good PHP code

Ontological argument: A good PHP programmer is better than a PHP programmer that doesn't exist. Therefore a good PHP programmer must exist.

Fuck CO2 (0)

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

How about we talk money instead. Apparently the cost for power and cooling is less than the cost of rewriting, at least within the planning horizon of Facebook management.

And while we are at it, fuck C++ too. :)

Sounds like cheap C-- drugs ! (0)

redelm (54142) | more than 4 years ago | (#30504274)

... what are you smoking???

Yes, C-- (or even FORTRAN) is less CPU in-efficient than PHP (or most any interpreted langauge). Why do you think CPU is limiting performance and causing the high server count?

GOOG has so many servers to be _fast_ (keep their DB in RAM). Facebook may be doing the same, or for disk.

Can we _please_ moderate stories? This one is -1 {TROLL}.

Re:Sounds like cheap C-- drugs ! (3, Informative)

DI4BL0S (1399393) | more than 4 years ago | (#30504370)

Google.com: 12,056 servers Website Worth: $ 186,352,889,952 USD (€ 126,610,389,668 EUR) Facebook: 34,872 servers Website Worth: $ 5,253,772,177 USD (€ 3,569,475,862 EUR) I'd say 'GOOG' i doing a bit better atm :) for those interested: info comes from: http://websiteshadow.com/ [websiteshadow.com] it will show ad rev. etc for URL's you provide

Re:Sounds like cheap C-- drugs ! (3, Insightful)

peragrin (659227) | more than 4 years ago | (#30504594)

while true it ignores things like your comparing a simple search box, with millions of users who post multi megabyte files to their personal space for everyone to see. try it some day save a facebook user's page locally and see just how much data is coming down that pipe, on top of the scripts that are running.

Your comparing googles front door with facebooks entire company. Google probably has that many servers running web crawlers, and twice over again to store that massive database they use.

10:1... Really? (5, Insightful)

tixxit (1107127) | more than 4 years ago | (#30504278)

That's crazy. 10:1 is incredibly unfair. Especially when you consider that a cached C++ page takes just as much time to return as a cached PHP page. On top of that, majority of the work done is just searching a database. If would imagine a large part of processing a page is in getting and returning data, which is then up-to-the database. He is using stats that say PHP is 10 slower for running through loops, math that type of crap. Says nothing about querying a database then doing some minor presentation related logic. If I had to guess, for a web page the average "efficiency gain" of using C++ would be under 2x.

Re:10:1... Really? (0)

spikenerd (642677) | more than 4 years ago | (#30504462)

...a cached C++ page takes just as much time to return as a cached PHP page...

The 10:1 ratio refers to server load, not user experience.

Re:10:1... Really? (1, Informative)

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

A cached C++-generated page takes just as much server load as a cached PHP-generated page. Better?

Re:10:1... Really? (2, Informative)

Xeriar (456730) | more than 4 years ago | (#30504638)

PHP's primary issue in the database department is it doesn't have a clean way of say, maintaining prepared statement declarations across connection instances. Which is frustrating. APC's handling of shared memory is not the best, either, and the memcached extensions for it need polish. Don't get me started on how PHP treats constants.

Where PHP really fails, however, is in memory usage. It takes up dozens of times as much RAM as a well-built C program would. Facebook would not reduce their computer count by a factor of ten because PHP is that much less efficient at its job, but because more memory would be available in a given machine to handle more instances at once.

Note: PHP 5.3 addresses a lot of this, but though I haven't tested it, I doubt the memory efficiency of PHP is going to get far into the double-digit percentiles of C++ in one shot.

tax them! (0)

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

I think they should be charged a 10% pollution tax for every server above the amount needed by C++ code.

it's stoopid because (-1, Flamebait)

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

CO2 is NOT pollution! Its what you exhale for godsake! We are carbon life forms! Really, I expect more from /. but that just goes to show how thorough the brainwashing has been.

Re:it's stoopid because (2, Insightful)

sqlrob (173498) | more than 4 years ago | (#30504574)

And everything exuding heat is perfectly natural, no problems there.

The deaths and environmental changes from heat exchange in rivers near power plants don't happen, nope, uh uh.

Water's perfectly natural you need it to live, no way to drown in it, nope, uh uh.

Re:it's stoopid because (0, Troll)

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

You excrete shit as well. I suppose that sewage pond known as your mom's basement isn't polluted either.

Re:it's stoopid because (2, Informative)

Cougar Town (1669754) | more than 4 years ago | (#30504648)

And water isn't a poison, but you'll still die if you drink too much of it.

First post from TFA nails it (2, Informative)

hilather (1079603) | more than 4 years ago | (#30504292)

Read the first posters points (in TFA) he pretty much sums everything up.

The REAL solution (5, Funny)

DoofusOfDeath (636671) | more than 4 years ago | (#30504294)

Just serve up plain text files. Anything else is pure decadence!

Re:The REAL solution (1, Funny)

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

I agree. We can receive said text files via hand signals from the tree tops, to which we will have climbed back up after eschewing all technology to minimize our collective carbon footprints.

where did he get this factor? (5, Insightful)

quickOnTheUptake (1450889) | more than 4 years ago | (#30504296)

I'm thinking that these scripts are just thin front ends to a massive db. Thus, a lot of the computer's time is going to be spent on I/O, and a lot of the processing is going to be taking place in the db itself, which is probably written in C.

Re:where did he get this factor? (1)

betterunixthanunix (980855) | more than 4 years ago | (#30504424)

What you said might have been true 10 years ago, before all this AJAX code. When you have millions of users pumping out AJAX requests, your middleware is going to wind up working a lot harder, and the database is still doing all the things it was doing back in the 90s.

Re:where did he get this factor? (3, Informative)

cybiko123 (1223650) | more than 4 years ago | (#30504626)

OK, let's say AJAX didn't exist for a moment. People would have to refresh their browsers to display/submit forms, which would require Apache/PHP to serve a *full web page* for every form displayed and submitted. This in itself causes a load on servers, before dynamic content is even considered. If anything, AJAX *lowers* server load.

No. (5, Insightful)

A Friendly Troll (1017492) | more than 4 years ago | (#30504308)

Simply put: no.

The reason why they have so many servers is because Facebook contains so much data. The servers are there for a reason, and the reason is CACHING.

The overhead of PHP is very small for a platform that is all about sharing data and the bulk of processor time surely goes towards fetching that data in the first place. What, do you seriously think that when you hit your home page on Facebook, there are database queries issued for that? Lulz.

Besides, I'm almost sure that FB uses something like Zend Accelerator, which increases code execution speed a lot.

Anyway, just no.

Re:No. (2, Informative)

moz25 (262020) | more than 4 years ago | (#30504630)

Very true: they are are big contributor to projects like memcache.

Please (2, Informative)

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

I don't care about your environmentalism.

Re:Please (4, Informative)

AnotherShep (599837) | more than 4 years ago | (#30504550)

Even better, TFA is a page for a C++ web toolkit. It's just spam.

Why stop there? (5, Insightful)

Freestonepilgrim (1397833) | more than 4 years ago | (#30504330)

Why not rewrite everything in assembly? This comparison comes to a conclusion without any facts to back it up. As others have pointed out there is development time and compile time associated with C++... and what about ongoing development? Where does 10-1 come from? Are you assuming they aren't doing any optimization or using any sort of accelerator? I've personally re-written code in C++ from php, and then done the comparison. In our case, we decided the extra maintainability was worth the approx 10-20% increase in speed we saw.

Re:Why stop there? (1)

luzr (896024) | more than 4 years ago | (#30504568)

Because C++ is faster?

Seriously, if you take into account templates and inlining, there is a good chance that moderately good C++ code will run faster than moderately good assembly, on x86-64 of course - simply because assembler coder would not have the patience to take all opportunities of inlining.

Re:Why stop there? (1)

hackstraw (262471) | more than 4 years ago | (#30504600)

Why stop there. FPGAs FTW!!!

Just think how much greener they could be... (1, Funny)

John Hasler (414242) | more than 4 years ago | (#30504334)

...were they to rewrite it all in assembly language!

Re:Just think how much greener they could be... (1)

gander666 (723553) | more than 4 years ago | (#30504394)

Dang whippersnappers, Everything should be written in Assembly. Dag nabbit. I learnt Assembly (gasp - 6502 and PDP Macro 11) I think that the new fangled macro assemblers should be enough for anyone!

Seriously, use the best tool for the job, and move on. Nothing to see here...

Interpreted Languages... (2, Insightful)

zippthorne (748122) | more than 4 years ago | (#30504336)

For something that is deployed to tens of thousands of machines..

Is there some reason why these languages couldn't be compiled and optimized? Code is just the programmer's will expressed as text that the machine can somehow interpret, right? If there is so much PHP out there, why wouldn't/couldn't there be an efficient compiler (by which I mean something that produces executables and not just "executables that are really just an interpreter tacked onto a script")

The dearth of such compilers on the market suggests to me that the gains wouldn't be as great as claimed for the majority of applications where interpreted languages are used.

Re:Interpreted Languages... (1)

cryfreedomlove (929828) | more than 4 years ago | (#30504502)

Is there some reason why these languages couldn't be compiled and optimized?

Java is another language that has been knocked around for years by C++ puritans but it has, in fact, become very well compiled and optimized.

Re:Interpreted Languages... (0, Flamebait)

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

Java is another language that has been knocked around for years by C++ puritans but it has, in fact, become very well compiled and optimized.

Yes yes, very nice. Now make the language not shit, please.

Re:Interpreted Languages... (1)

djmurdoch (306849) | more than 4 years ago | (#30504514)

I've no idea about PHP, but the usual problem with interpreted languages is that their model of the computer is too high level to be a good match to the hardware. To compile to fast code, the operations being performed need to map predictably to machine instructions. If the same a+b line could, depending on what preceded it, mean adding integers, adding floating point values, or concatenating strings, then it's not going to compile to anything as fast as a statically typed language where it might be one or two machine instructions.

Re:Interpreted Languages... (1)

Virak (897071) | more than 4 years ago | (#30504566)

Because highly dynamic languages that do everything at runtime are not so easy to optimize at compile time. It is possible though to do all sorts of fancy things at runtime, such as with, for example, Java (though ironically Java is the exact opposite of this sort of language and doesn't really need it so much), and some traditionally purely interpreted languages like JavaScript have started getting snazzy JIT implementations these days. PHP wouldn't benefit from this sort of stuff too much as it's largely IO-bound in practice, and, as a few other users here have noted, most of the heavy lifting in PHP applications is done in databases which are most certainly not written in this sort of language.

Umm... no. (3, Insightful)

NitroWolf (72977) | more than 4 years ago | (#30504338)

Does the author seriously believe that Facebook isn't running some sort of PHP compiling/caching service, like APC or something similar?

It would be ridiculous for them NOT to be running something like that, which eliminates much of the advantage C++ would enjoy through being pre-compiled. While there still may be a reduction if Facebook were magically changed to precompiled C++ code, the reduction would be fairly minimal. In addition to that, you'd need to factor in the debugging and coding/compiling times, which would exceed the PHP times by an order of magnitude at least.

Even if PHP is running 10 times slower... (1)

sam0737 (648914) | more than 4 years ago | (#30504352)

I'm assuming the claim about 10 times is true, which I don't really think so...
But they could have done something - like precompile the PHP, just like JIT of Java, to make it better or on par with compiled C program.
There are PHP accelerators like Zend Accelerator for that.

Re:Even if PHP is running 10 times slower... (1)

canajin56 (660655) | more than 4 years ago | (#30504530)

Yeah, in fact, since we're just pulling numbers out of our asses, a quick Wiki check says that PHP pre-compilers give a performance boost of up to 10x, therefore neatly canceling out this d-bags assumed 10x ratio. Yay for fictional numbers.

Morons. (3, Informative)

Luke727 (547923) | more than 4 years ago | (#30504356)

This is why people don't take global warming seriously. Please, just stop it. If you really wanted to help, you could just fucking kill yourself and cut your carbon footprint to 0.

A trolling weak argument (4, Insightful)

Foredecker (161844) | more than 4 years ago | (#30504358)

What a troll. Any point or argument based on assumptions is very weak. Here there are two: "..Let's assume this to be ..." and "...assuming a conservative ratio of 10...".

Don't make stuff up.

-Foredecker

Hidden cost (0)

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

What about the environmental impact of all the coke bottles required to power the C++ programmers?

F1 car in normal street. (1)

Tei (520358) | more than 4 years ago | (#30504372)

This don't make much sense. You can go to work in a F1 car, or your normal car. You in theory will go faster in the F1 car.

In real world, there are other "fasters". The normal car is "faster to buy" (cheaper), "faster to mantain" (cheaper to mantain), and lots others "faster" that make faster your normal car than your F1 car.
Facebook is probably one of the few sites that could have written part of it on fast C++ code. In a F1 race, you will use a F1 car.

Re:F1 car in normal street. (4, Funny)

oddaddresstrap (702574) | more than 4 years ago | (#30504674)

You can go to work in a F1 car, or your normal car.

I wish. My F1 always gets stuck in the gutter at the end of the driveway.

Things Change, Efficiency Matters (1, Insightful)

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

Many many moons ago efficiency was everything. The CPU was expensive, the developer was (relatively speaking) cheap.

Then Moore's law really started to kick in, and we needed a paradigm shift. Developers were more expensive, and CPU cycles could be had on the cheap. The mantra was "code it fast, and only worry about efficiency for the bottlenecks if at all".

Fast forward to almost 2010, and we have web applications deployed on a massive scale. Guess efficiency matters again. Not only from a pure cost standpoint but also from a moral argument to cut back on greenhouse gases. Amazing that more people haven't seen this coming. Especially given that web services are normally free to the consumer, the cost side of the equation clearly matters.

Assuming... (4, Insightful)

Xugumad (39311) | more than 4 years ago | (#30504390)

"assuming a conservative ratio of 10 for the efficiency of C++ versus PHP code"

ARRRRRGGGGHHHHHHHHHHHHH

Why? On what evidence? I mean, I hate PHP as much as the next guy, but last time I wrote a web application platform in C++, I got to the end, analysed the result and went "Great, I've made the fast bit even faster. Now, about that database engine..."

Write it in Java! (0)

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

facebook should be re-written in Java.

It could run on a java interpreter, written in java, that would give it ultimate speed compared to C++.

C++ is dying, netcraft confirms it, Java is faster than C++, it's the wave of the future!

Re:Write it in Java! (0)

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

Fools, they should have written it in ASP.NET. Just ask Microsoft.

What a fucked up "assumed" "conservative" ratio (1)

nedlohs (1335013) | more than 4 years ago | (#30504470)

Yeah right serving a page out of cache in PHP takes ten times as long as C++.

How about this comparison (1)

YrWrstNtmr (564987) | more than 4 years ago | (#30504484)

Plain text vs. any web graphics. Who needs all that fancy graphics crap? If you can't get your message across with plain ASCII, then you are incompetent, lazy, and on the verge of being a mindless PowerPoint Ranger.

Hells about to freeze over ... (4, Interesting)

LizardKing (5245) | more than 4 years ago | (#30504486)

.. because I didn't ever think I'd be defending PHP.

However, it is a much better choice for a web application than C or C++ - and I say that as someone who codes C, C++ and Java for a living. There are no decent web frameworks for C++, memory management is still an issue despite the STL, and the complexity of the language means both staff costs and development time are inflated. Peer review is harder, as the language is fundamentally more difficult to master than PHP. Compared to Java, the development tools are poorer, and things like unit testing a more complicated despite the availability of things like Cppunit. There's no "standard" libraries for things like database access, and no literature that I am aware of that describes how you would go about designing a framework for C++. You'd most likely end up porting something like Spring to C++, and the even if you published your code on the web, I doubt much of a community would build up around it.

If you want a less contentious argument, and one which can be backed up with hard evidence, then argue PHP that should be replaced with Java. A well written Java web application, using a lightweight framework such as Spring or PicoContainer, should outperform ad-hoc C++ code.

optimization (1)

TheSHAD0W (258774) | more than 4 years ago | (#30504494)

It's likely most of the overhead in Facebook's server farm is database-related and not PHP-related, meaning switching to C++ would not help much. Also, depending on what tasks the PHP codeebase is performing, one can write binary libraries to speed up critical portions of the operation, improving performance to near-total-binary without reducing maintainability. I wouldn't be surprised if the people at Face book were already aware of this.

Re:optimization (1)

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

It seems that they already optimized into C++ what was worth optimizing. From the linked Facebook's presentation [wordpress.com] :

Back-end services that require the performance are implemente [sic] in C++.

Comparing carbon footprints is pretty complex: everything produces carbon, even optimizations, architectural changes, extra developers needed to create and maintain more complex systems written in less web-friendly languages, and I'm no fan of $this-> PHP thing ;-) Maybe this guy at webtoolkit should have made some more assumptions before writing that post.

what about production/maintenance costs (1)

unity100 (970058) | more than 4 years ago | (#30504510)

developing web applications in c is not exactly a walk in the park. neither c was designed to build web applications, or maintain them. whereas you can easily go through php code to develop new functions and improve new and existing functions efficiency speedily and economically, it wont be the sam with c. what about those costs ?

looking at the instantaneous state of the server/php/performance situation is as stupid as just looking at the instantaneous state of a mass production factory and declaring that certain assembly lines are not efficient or green. there are a lot many factors and costs to count into in the bigger picture.

a half assed approach, which, somehow, brings the word 'green' into the mix - maybe to garner some attention, since it is the issue these days.

He's not wrong.... But... (3, Interesting)

pjr.cc (760528) | more than 4 years ago | (#30504560)

Seriously, years ago I started working on a c++ version of j2ee (not just servlets, the whole kit) and i mean providing similar functions not identical methods of execution obviously. It wasnt terribly hard actually. But it all falls apart really quickly cause of several reasons:

1) platform architecture - the dependence here, even between different versions of the same distribution was a pain and essentially spelt the end of my work. So I was stuck with "do i make web apps c++ soruce, or shared library binaries?" to which there is only one real answer for portability - source.
2) its a systems langauge - dear god that makes it painful for so many reasons.

There are caveats to both those, but the reality is that php exists because it fulfils a need and it does it quite well. To compare the two (c++ and php) is a little ridiculous and ultimately this article just reeks of "please everyone advertise my c++ web tool kit for me!". Sure, facebook (and trillions of others) MIGHT move to c++ web tool kit, but find me a dev that knows how to code an app it, now find me 2, now find me 200 cause thats how many i'd need to write and maintain faceboot apps in c++.

Even taking the OP's assumtion c++ is 10 times more efficient at what php does and that you could actually code facebook in it as actually acurate and that php vs c++ is a one-to-one relationship for things like code maintenance, your still stuck with "how many API's am i going to have to re-write and how many php api's do i use that dont even exist in c++". Its ludicrous to assume that you could drop-in replace php with witty without ending up coding tonnes of c++ code just to do things that PHP already provided. Not to mention the zillions of little extensions that revolve around php to accelerate its web-abilities (memcached for example). The number of things that can be used along side php for web-related things and the number of api's in-built to php just mean witty is never even going to be viable as an alternative. Lets also not forget there are millions of people round the globe using php for web stuff - which ultimately leads to php being a good web language (i.e. security problems being found, optimizations, etc etc).

Of course, wouldn't facebook be using something like zend to compile php pages? I mean seriously, if the 25000 servers are running php and not running zend the waste here just in cost of servers would be unbelievable - shear idiocy on facebooks part (if it were true, and i'd very much doubt it) and I imagine zend would have almost given it away for free just so facebook could say "we got a x% improvement using the zend compiler".

So, I wonder how many people are now learning about witty for the first time (which seems like the only real reason for the article to begin with). Better advertising than adwords!

PHP vs C++?? (1)

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

That’s like a cage match between a slow drooling retard and your crippled grandpa in his electric wheelchair.

In other words: Run it at double speed, add Yakety Sax to it [slashdot.org] , and it’s awesome. :D

Take it further (1, Funny)

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

Code it in Asm, and you can get 100:1, so you can power down 29,700 machines...

Better yet, make ppl. post all their wall posts directly in binary code. That way, you can destroy the code necessary to translate UTF-8 back-and-forth, the HTTP/MIME wrappers, and the SQL. Imagine the amount of electricity saved! You can market it as a brain-booster too, since now you have to think before you post on Facebook.

Author needs a clue about metrics (4, Informative)

bokmann (323771) | more than 4 years ago | (#30504596)

Yes, PHP is a heck of a lot slower on proccessor-bound tasks than C++. In a pure benchmarking contest, no doubt C++ will win.

But what about when both languages have to query a database (be it mysql/postgress/oracle, etc)? In this case, both are blocked on the speed of the database. a 15 ms query takes 15 ms no matter what language is asking. Facebook is not calculating pi to 10 gazillion digits, and it is not checking factors for the Great Internet Mersenne Prime Search. It is serving up pages containing tons of customized data. This is not proessor-bound... it is I/O bound both on the ins and outs of the database and the ins and outs of the http request. It is also processor bound on the page render, but the goal of this many machines is to cache to the point where page renders are eliminated.

Once a page is rendered, it can be cached until the data inside of it changes. For something like facebook, I bet a page is rendered once for every ~10 times it is viewed by someone. Caching is done in ram, and large ram caches take a lot of machines.

So lets look at those 30,000 machines not by their language, but by their role. We can argue the percentages to death, but lets assume 1/3rd are database, 1/3rd are cache, and 1/3rd are actually running a web server, assembling pages, or otherwise dealing with the end users directly (BTW, I think 1/3rd is way high for that.)

So 1/3rd of the machines are dealing with page composition and serving pages. If they serve a page ~10 times for every render request, then abtou 1/10th of the page requests actually cause a render... the rest are being served from cache. Those page renders are I/O bound, as in the example above - waiting on the database (and other caches, like memcached), so even if they are taking a lot of wait cycles, they are not using processor power on the box. The actual page composition (which might be 20% of the processing that box is doing), would be a lot faster in C++... So 10,000 servers, the virtual equivalent of 2000 are generating pages using php, and could be replaced by 200 boxes using stuff generated in C++.

So the choice of using php is adding ~1800 machines to the architecture. or ~6% of the total 30,000. Given that a php developer is probably 10x more productive than a developer in C++, is the time to market with new features worth that to them? I bet it is.

Stop proselytizing for your cult (0, Flamebait)

digitalcowboy (142658) | more than 4 years ago | (#30504652)

AGW/CC is about as real as Scientology. Shut the fuck up already. "The Environment" has taken care of itself for billions of years. I'm not hurting it and it doesn't need you to save it.

Beyond that, this post has taken it to a brand new, stupidly religious place. You're now calculating numbers you pulled out of your ass to indict programming languages that you find to be "un-green."

That's my limit. Go sit in the stupid corner until you learn to interact with intelligent adults again.

gay as in south park gay (0)

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

gay, don't care

A C app would be much faster (2, Informative)

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

The proposed ratio of 1:10 is real, if not bigger. And here's why:

1.) For each request, PHP has to load entire application responsible for that particular response, including its configuration, etc. With memcache(d), you have to instantiate connection classes and reconfigure them, per request. Languages like C/C++, Python and Ruby have different architecture to begin with. They load ONCE and each request triggers a FUNCTION or METHOD of a class, with all the app-specific configuration, db and memcached connections done and configured on app init, NOT per request.

2.) TFA mentions microsecond relevance! Even a simple echo "Hello World" will take much more time than similar action in C. I have yet to see a PHP helloworld app that does it in under 1msec, let alone the microseconds required.

3.) Arrays in PHP are slow, being always hashmaps. Other data structures can speed up things. You don't always need hashmaps. SPLFixedArray() is a joke, btw, and available only as of 5.3. Can't compare it to a vector anyways, and lots of fixed structures can be represented by structs or classes in C which are anways faster than in PHP. Also the app can instantiate them once on init, and just (re)load when required.

4.) Even if all the app does it parse input vars and call memcache(d) / database funcs/methods to retrieve/store data, those calls are faster in C. Params can be parsed quicker in C, not requiring hashmaps for instance.

5.) FastCGI is crap. If this app were to be done in C, then it would require its own HTTP layer, epoll based (for Linux). It can take out all the crap in HTTP that is not requred to parse the AJAX calls, and does not need to be "generic" enough to deliver static content.

6.) For such dedicated and distributed deployments, garbage collection is sometimes not required. For instace, fixed-length stuctures can be preallocated upon app init, and the app can really take as much RAM as possible on startup. Yes, that would limit the MAX number of users/connections per server, but so what? The app dominates the server, nothing else is required to run (except basic OS environment for the app), so fixed memory consumption is not a problem.

7.) Even though each request has to wait for I/O of some sorts, either from memcache(d), from disk or from DB, you can process much more of these per front-end server and just scale backend servers as required. For example, with PHP your front-end server can serve 100k/sec, having X DB backends and Y memcached backends. With a C application, the front end can serve, say, 1M/sec. You still get to keep one front-end, even though you had to put more backends.

In short, you can significantly reduce the number of servers required if the app was written in C.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?