Slashdot Mirror

← Back to Stories (view on slashdot.org)

Can "Page's Law" Be Broken?

Posted by CmdrTaco on from the sounds-about-right dept.

theodp writes "Speaking at the Google I/O Developer Conference, Sergey Brin described Google's efforts to defeat "Page's Law," the tendency of software to get twice as slow every 18 months. 'Fortunately, the hardware folks offset that,' Brin joked. 'We would like to break Page's Law and have our software become increasingly fast on the same hardware.' Page, of course, refers to Google co-founder Larry Page, last seen delivering a nice from-the-heart commencement address at Michigan that's worth a watch (or read)."

8 of 255 comments (clear)

  1. Of Course by eldavojohn · · Score: 5, Insightful

    Can "Page's Law" Be Broken?

    I think it gets broken all the time. At least in my world. Look at Firefox 3 vs 2. Seems to be a marked improvement in speed to me.

    And as far as web application containers go, most of them seem to get faster and better at serving up pages. No, they may not be "twice as fast on twice as fast hardware" but I don't think they are twice as slow every three months.

    I'm certain it happens all the time, you just don't notice that ancient products like VI, Emacs, Lisp interpreters, etc stay pretty damn nimble as hardware takes off into the next century. People just can't notice an increase in speed when you're waiting on I/O like the user.

    --
    My work here is dung.
    1. Re:Of Course by Anonymice · · Score: 5, Funny

      I can't speak to emacs...

      RTFM.
      C-x M-c M-speak

    2. Re:Of Course by AmiMoJo · · Score: 5, Insightful

      OO was never designed for speed or efficiency, only ease of modelling business systems. It became a fashionable buzz-word and suddenly everyone wanted to use it for everything, so you end up in a situation where a lot of OO programs really only use OO for allocating memory for new objects.

      I'm not trying to be a troll here, I just find it odd that OO is considered the be-all and end-all of programming to the point where people write horribly inefficient code just because they want to use it. OO has it's place, and it does what it was designed to do quite well, but people should not shy away from writing quality non-OO code. I think a lot of programmings come up knowing nothing but OO these days, which is a bit scary...

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    3. Re:Of Course by drsmithy · · Score: 5, Funny

      agreed. Apple always manages to break it too with OS X. from 10.1 to 10.4 the OS notably improved in speed on even older equipment each time it upgraded, even on older PPC G3 and G4 machines.

      Of course, when you're starting from a point of such incredibly bad performance, there's not really anywhere to go but up.

      It would have been more impressive if they'd somehow managed to make it slower with each release.

  2. Most bang for the buck. by rotide · · Score: 5, Insightful
    Why would a company spend money to make software more efficient when the current incarnation does its job just fine?

    While I like the idea of being as succinct and efficient as possible with your code, at what point does it become fruitless?

    Obviously, if you're testing your code on a "new" workstation and it's sluggish, you'll find ways to make it work better. But if it works well? What boss is going to pay you to work on a project for no real benefit other than to point out it is very efficient?

  3. Re:I don't think that holds up by Keith_Beef · · Score: 5, Informative

    All he has done is put numbers into Wirth's law.

    I remembered this as "software gets slower faster than hardware gets faster", but Wikipedia has a slightly different wording: "software is getting slower more rapidly than hardware becomes faster".

    http://en.wikipedia.org/wiki/Wirth%27s_law

    In fact, that article also cites a version called "Gates's Law", including the 50% reduction in speed every 18 months.

    K.

  4. They probably will. by fuzzyfuzzyfungus · · Score: 5, Insightful

    I'd suspect that Google probably will. Not because of any OMG special Google Genius(tm), but because of simple economics.

    Google's apps are largely web based. They run on Google's servers and communicate through Google's pipes. Since Google pays for every server side cycle, and every byte sent back and forth, they have an obvious incentive to economize. Since Google runs homogenous services on a vast scale, even tiny economies end up being worth a lot of money.

    Compare this to the usual client application model: Even if the scale is equivalent, the maker of the software doesn't pay for the computational resources. Their only pressure is indirect(i.e. customers who don't buy because their machines don't meet spec, or customers who get pissed off because performance sucks). They thus have a far smaller incentive to watch their resource consumption.

    The client side might still be subject to bloat, since Google doesn't pay for those cycles; but I suspect competitive pressure, and the uneven javascript landscape, will have an effect here as well. If you are trying to sell the virtues of webapps, your apps are (despite the latency inherent in web communication) going to have to exhibit adequate responsiveness under suboptimal conditions(i.e. IE 6, cellphones, cellphones running IE 6), which provides the built in "develop for resource constrained systems" pressure.

  5. Adding RAM to an existing device by tepples · · Score: 5, Insightful

    RAM is cheap these days.

    Unless you would need to add RAM to millions of deployed devices. For example, the Nintendo DS has 4 MB of RAM and less than 1 MB of VRAM, and it broke 100 million in the first quarter of 2009. Only one DS game came with a RAM expansion card.