Forgot your password?
typodupeerror
Earth Facebook PHP

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

Posted by Soulskill
from the efficiency-is-overrated dept.
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by VampireByte (447578) on Sunday December 20, 2009 @11:57AM (#30504240) Homepage

    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.

    • by LBt1st (709520) on Sunday December 20, 2009 @12:03PM (#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.

      • by sznupi (719324) on Sunday December 20, 2009 @12:20PM (#30504456) Homepage

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

      • by Colin Smith (2679) on Sunday December 20, 2009 @12:45PM (#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.
         

      • Re: (Score:3, Insightful)

        by vegiVamp (518171)
        > Sure C++ would be faster running

        If you take APC or similar compile caches into account, I think you'll find that the gap is remarkedly smaller than you'd expect. It'll never close entirely, but given that I've seen 20x speedups on some pages, the benefit is huge.
    • by Jesus_666 (702802) on Sunday December 20, 2009 @02:16PM (#30505378)
      C++ is much too slow and carries too much of an overhead. And it usually requires an operating system on a general-purpose processor. You could go to hand-optimized binary code written directly for the processor but that still leaves us with inefficiencies.

      Imagine if every website was implemented as an ASIC. Then we could talk about efficient datacenters. Maybe, if you're relly strapped for cash, you could implement each website in an FPGA. But that should only be a stopgap measure until you can afford a proper implementation.
  • Ridiculous (Score:3, Insightful)

    by SashaM (520334) <`msasha' `at' `gmail.com'> on Sunday December 20, 2009 @11:57AM (#30504242) Homepage
    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?
    • by Sygnus (83325) on Sunday December 20, 2009 @12:00PM (#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.

  • by Darkness404 (1287218) on Sunday December 20, 2009 @11:59AM (#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.
    • by Anonymous Coward on Sunday December 20, 2009 @12:05PM (#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!

      • by Anonymous Coward on Sunday December 20, 2009 @12:30PM (#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: (Score:3, Funny)

        by Anonymous Coward

        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.

      • Re: (Score:3, Interesting)

        by digsbo (1292334)

        Unfortunately, the C++ programmer who writes bad C++ code is more common than the C++ programmer who writes good C++, and the bad C++ is probably harder to rework than bad php.

        I once rewrote a bit of software that some MIT grads did. Theirs was 20K lines of C++, used 110 MB ram (constantly newing and deleting), used dozens of threads (constantly spawning and harvesting), and drove the system to its knees (90% system, 10% user load). My 2K (yes, one-tenth) lines of straight C used 5 threads (preallocated)

        • Re: (Score:3, Insightful)

          by GreatBunzinni (642500)

          I once rewrote a bit of software that some MIT grads did. Theirs was 20K lines of C++, used 110 MB ram (constantly newing and deleting), used dozens of threads (constantly spawning and harvesting), and drove the system to its knees (90% system, 10% user load). My 2K (yes, one-tenth) lines of straight C used 5 threads (preallocated), a configurably preallocated ring buffer (about 100K in practice), and used less than 5% of user time with no measurable system load. And I was able to do this adding functional

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

    by tixxit (1107127) on Sunday December 20, 2009 @12:01PM (#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: (Score:3, Informative)

      by Xeriar (456730)

      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

    • Re: (Score:3, Informative)

      by butlerm (3112)

      In terms of total page delivery latency for a typical I/O bound application, sure. In terms of actual cpu usage, 10x overhead for any dynamically typed language is to be expected. If the application servers are CPU bound, that means a lot more servers.

      In addition, dynamic languages do not compile or JIT well, compared to statically typed languages, which severely limits the overhead reduction achievable.

  • Read the first posters points (in TFA) he pretty much sums everything up.
  • by DoofusOfDeath (636671) on Sunday December 20, 2009 @12:02PM (#30504294)

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

  • by quickOnTheUptake (1450889) on Sunday December 20, 2009 @12:02PM (#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.
  • No. (Score:5, Insightful)

    by A Friendly Troll (1017492) on Sunday December 20, 2009 @12:04PM (#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: (Score:3, Informative)

      by moz25 (262020)

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

  • Please (Score:2, Informative)

    by Anonymous Coward

    I don't care about your environmentalism.

  • Why stop there? (Score:5, Insightful)

    by Freestonepilgrim (1397833) on Sunday December 20, 2009 @12:07PM (#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.
  • ...were they to rewrite it all in assembly language!

  • by zippthorne (748122) on Sunday December 20, 2009 @12:07PM (#30504336) Journal

    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.

    • by FooAtWFU (699187) on Sunday December 20, 2009 @12:49PM (#30504696) Homepage
      A lot of the power of interpreted languages comes from the abstractions that are put in place to make programming easier. These abstractions have a price in terms of execution time. Furthermore, once you're using an abstraction, there's not a simple way in the imperative paradigm for a compiler to determine that your code needs XYZ part of the abstraction, but not part ABC. You need to do the whole thing.

      For example, consider the following. Say bad things about PHP all you want (it deserves it) but one of the things you don't generally see with PHP code is a buffer overflow, where you try to copy a bunch of strings and concatenate them together and you run out of room and don't notice it and you go clobbering memory. That's because the string manipulation code goes through a bunch of checks when you're appending strings. You can't just skip these checks and hope that everything will work the same. You may know that such and such a code-path isn't going to need all the bounds checking because you're, say, idunno, assembling fixed-length ZIP+4 codes or something, but the scripting language can't be informed of that fact using any extant mechanism (nor is it clear how you could integrate such a mechanism with the powerful abstraction that lets you not worry about the rest of your strings to begin with).

      Moreover, as has already been pointed out, a lot of the computational price of rendering a web page is database queries and memory-cached-object queries which employ compiled code already. The string-manipulation overhead isn't all that significant compared to the abstraction that it buys you. It's probably a better idea to track down logic issues, where your code does stupid useless computations that it doesn't need that make it slow, or could do certain computations in advance to make it faster, or such.

      I think there's a lot more potential for interesting machine optimization of code for things coming from the functional paradigm, where you can mathematically show the equivalence of certain portions of code with its optimized replacement, and that this paradigm will be making a resurgence in some places during the upcoming era of 128-core processors. This might be interesting.

    • by musicalmicah (1532521) on Sunday December 20, 2009 @01:28PM (#30505000)

      Actually, Facebook uses APC [facebook.com] to compile and optimize the code in the shared memory so it doesn't have to be compiled over and over again.

      There are other libraries for caching PHP functions on many different levels as well, and they're open source, for the most part. Some real bright minds from Facebook and other large PHP applications have contributed to them.

      Bottom line: PHP is quite powerful and efficient when built and extended properly.

  • Umm... no. (Score:4, Insightful)

    by NitroWolf (72977) on Sunday December 20, 2009 @12:07PM (#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.

    • Re:Umm... no. (Score:5, Interesting)

      by mariushm (1022195) on Sunday December 20, 2009 @12:58PM (#30504762)

      The author is pulling numbers out of his ass and has no clue about what uses most time (waiting for database results mostly), about PHP accelerators and about caching systems like memcached.
      He's comparing performance of php script running on a raw PHP installation versus running a C++ version of the same script, doing calculations that almost never apply to real world scenarios.

      I don't see how any company would use C++ to develop their whole systems except maybe for some CGI scripts. Not even Google does it, afaik they use Perl and Python a lot.

      Anyway, the number of servers has no direct correlation to the programming language. Out of those thousands of systems, lots of them are read only database servers in a cluster, lots are only serving static files (thumbnails, images used in CSS files on people's pages and so on), some servers are used solely for memcached instances and content used very rarely, some are load balancers....

      Basically, the author has no clue.

      I always found Livejournal's presentation about scaling very insightful, especially as it's a pretty big site, just like Facebook and other big time sites. The second link gives a lot of details about how they fine tune mysql and other parts of the system, which just goes to show how the apparent speed improvement of C++ versus PHP can overall be actually insignificant.

      http://video.google.com/videoplay?docid=-8953828243232338732&ei=3VUuS5-hLaKi2ALXqanJBQ&q=livejournal# [google.com]
      http://www.danga.com/words/2004_mysqlcon/mysql-slides.pdf [danga.com]

      • Re: (Score:3, Informative)

        by butlerm (3112)

        the author...has no clue about what uses most time (waiting for database results mostly)

        Like many here, you are confusing page delivery latency with total processor overhead. If you need more than one processor for page processing, how many you need has little or nothing to do with how much latency there is elsewhere in the system.

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

  • by Foredecker (161844) * on Sunday December 20, 2009 @12:10PM (#30504358) Homepage Journal

    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

  • Assuming... (Score:5, Insightful)

    by Xugumad (39311) on Sunday December 20, 2009 @12:13PM (#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..."

    • Re: (Score:3, Informative)

      by butlerm (3112)

      Latency is a different question than efficiency. If your page generation efficiency is bad, on a small setup the difference may be imperceptible. On a large installation, i.e. one with a large number of servers dedicated to page generation, the efficiency of those servers makes a big difference. Holding latency constant, in a large installation less efficient page generation means more servers. In a small installation, not so much.

  • by LizardKing (5245) on Sunday December 20, 2009 @12:24PM (#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.

  • by pjr.cc (760528) on Sunday December 20, 2009 @12:33PM (#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!

  • by bokmann (323771) on Sunday December 20, 2009 @12:38PM (#30504596) Homepage

    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.

  • This is stupid (Score:3, Insightful)

    by Fnkmaster (89084) on Sunday December 20, 2009 @12:58PM (#30504760)

    Companies use PHP to develop and run web app functionality because it saves them huge amounts of time and money over rolling out the same thing if you were to write it all in C++. Realize what the cost structure of a company like Facebook is - the amount they pay their engineers, marketing personnel, and so on is significantly more than their amortized server expenses and server operating expenses (including energy costs, etc.).

    Furthermore, the 10x speedup assumption seems ridiculous - how much time is spent on their server in compute-intensive PHP loops where huge gains would be made from switching to C++? And how much of the "code" is really database queries of various sorts? Furthermore, you can generally isolate small areas like that in your codebase and rewrite them as modules in C or C++ to be invoked from PHP land - and if they could easily cut their server expenses even in half (let alone by 90%) by having a few engineers spend a few weeks rewriting some components, don't you imagine they've probably set about doing that already?

    Re-casting a discussion in terms of greenhouse gas emissions or energy use doesn't change any of this - saving energy generally means saving money, unless it takes more expensive resources (such as 100s of humans, who have to spend hundreds of months re-writing code in C++, while they, their families, and dependents emit tons upon tons of greenhouse gases, use electricity, buy groceries, and so-on and so-forth). The cheapest solution certainly isn't always the most environmentally friendly solution (such as when negative externalities are involved - lower labor and pollution standards in China, for example, that make a less "green" product manufactured there less costly in the US), but a vastly more expensive solution that no company in its right mind would implement isn't necessarily greener just because it might save some electricity and a few servers once it was implemented.

  • by dirkdodgers (1642627) on Sunday December 20, 2009 @01:35PM (#30505044)

    This is brilliant! I think it's clear now the direction we must go. Overuse of energy-guzzling languages like PHP have put us on an unsustainable trajectory fueling out of control global warming.

    Congress must act to regulate the use of these energy-guzzling languages. No longer will programmers and corporations be permitted to turn out inefficient code with impunity.

    PHP, Perl, Ruby, Bash, your days are numbered!

    Just wait until we can get UN involved. Python, you and your CO2 spewing simplicity are next!

  • Wasted Energy (Score:3, Insightful)

    by ChaoticCoyote (195677) on Sunday December 20, 2009 @01:53PM (#30505196) Homepage

    Isn't this "study" a waste of energy?

    I am a C/C++ programmer by trade; I'm not fond of PHP. Yet this "C++ saves energy over PHP" argument smells like more selfish politics to me. And selfish politics is what is bringing doom down on humanity's head -- the use of PHP vs. C++ is a sideline, a distraction, and only truly valuable for people who have a philosophical axe to grind.

    You want to save a lot of energy? Shut down all the computers running MMOs. And stop wasting cycles looking for alien signals in cosmic radio waves. And get rid of banal YouTube videos... and... the list is endless. The science behind Global Warming is being used to further political and social agendas that have little or nothing to do with adapting our species from a potential environment change.

    In the end, selfish politics will kill us all. We will become a footnote in history is we do not discover enlightened self-interest.

  • Green Languages?? (Score:3, Insightful)

    by nurb432 (527695) on Sunday December 20, 2009 @01:54PM (#30505204) Homepage Journal

    Ok, this has gone WAY too far .. we all need to just take a step back..

  • PHP vs. C++ (Score:4, Insightful)

    by Brian Knotts (855) <(moc.sseccaedacsac) (ta) (sttonkb)> on Sunday December 20, 2009 @04:05PM (#30506170)

    This is idiotic, and is typical of the kind of pseudo-science underlying much of the climate alarmism currently en vogue. Like a lot of things, it is pretty much impossible to quantify which language ultimately uses more power, because of all the variables. As others have pointed out, you might save some power in the deployment of the code, but you would surely use more power in the development of that code. Then, you have to figure out what the total impact of that is, since you'd have more man-hours of coding, using human coders, who sit at desks, in offices, which must be heated and cooled, etc., etc.

  • This logic is crap (Score:4, Interesting)

    by Giant Electronic Bra (1229876) on Sunday December 20, 2009 @04:35PM (#30506386)

    It would take a really serious amount of in-depth analysis of the server application to even approach knowing what the efficiency impact of using a compiled language vs an interpreter would be on any specific stack. Or even stacks in general. Plus we don't even know what it really means to be "using PHP". What is PHP doing? Is it processing templates, doing just some post or pre processing with some kind of XML pipeline in the middle, how is the PHP deployed, etc?

    It is simply ridiculous to make any assertions and claim accuracy for them. I'm no PHP fan boy by a LONG shot, but I know from hard experience that often a higher level tool which is optimized for a particular job can get the job done quite a lot MORE efficiently than a lower level one that isn't.

  • by D4C5CE (578304) on Sunday December 20, 2009 @05:50PM (#30506856)
    Their decision for using PHP might have to do with being able to get their business up and running now using PHP rather than envisaging go-live a few years down the road with their developer resources and learning curve adjusted to C++ (which in all its well-deserved glory does take its time to master). Probably C's savings in power don't outweigh PHP's savings in manpower.

"There is nothing new under the sun, but there are lots of old things we don't know yet." -Ambrose Bierce

Working...