Can "Page's Law" Be Broken?

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

Comments

Of Course

[eldavojohn]

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.

Re:Of Course

[Z00L00K]

The law isn't linear, it's more sawtooth-style.

Features are added all the time which bogs down the software, and then there is an effort to speed it up and then there are features added again.

One catch in performance is that it sure is faster to use RAM for data, but there is also a lot of useless data floating around in RAM, which is a waste of resources.

And this is often the curse of object-oriented programming. Objects carries more data than necessary for many of the uses of the object. Only a few cases exists where all the object data is used. A lot of object-oriented programming is somewhat like using 18-wheelers for grocery shopping.

This often explains why old languages like C, Cobol etc. are able to do the same thing as a program written in C++, Java or C# at the fraction of the resource cost and at much greater speed. The disadvantage is that the old languages require more skills from the programmer to avoid the classical problems of deadlocks and race conditions as well as having to implement functionality for linked lists etc.

Re:Of Course

[Anonymice]

I can't speak to emacs...

RTFM.
C-x M-c M-speak

Re:Of Course

[AmiMoJo]

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

Re:Of Course

[drsmithy]

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.

Re:Of Course

[grumbel]

Well, that depends, OOP alone is certainly not the guilty one for causing all the slowdown, but abstraction in general is guilty for a lot of things. Todays software is just way to removed from the actual hardware to allow certain kinds of optimizations. Random example: When you have a 2D game on older hardware (say GBA or similar) you could scroll by manipulating two bytes that represent the scroll offset, everything else was done in hardware. How do you scroll in a 2D game today? Fullscreen refreshes, as you don't have any access to the hardware to allow faster ways to scroll. So in the worst case you have to manipulate not 2 bytes, but around six million of them. Thats quite a few orders of magnitude difference there, that you can't really optimize away today.

Now for real games of course you might have a GPU that can handle that amount of speed and since modern games are 3D you don't really have a choice of not doing fullscreen refreshes to begin with, but as soon as you look into web games you can see all the problems, games in Flash or Javascript most of the time run completly terrible, worse then games you might have played a decade or two ago, because those games don't even have GPU access but instead pump their data through layers upon layers of abstraction before they finally hit the graphics card.

In the end I think the core problem is simply that todays software is written far to often for an abstract black box, instead of for a actual hardware. Especially web development is just way to removed from the actual machine to even have a chance of running quickly. To make things really fast you would have to optimize all layers of abstractions that the code has to run through, but most often you just don't have the control over it, as development is far more spread out these days. Its no longer your code and the hardware, its your code, dozens or even hundreds of libraries and then maybe far far away some piece of hardware again.

Most bang for the buck.

[rotide]

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?

Re:Most bang for the buck.

[cylcyl]

When companies go into feature race, they forget that it quickly becomes diminishing returns. As the features you enable are less and less likely for your client base to be interested in.

However, if you improve the performance of your core functions (thru UI or speed), your entire customer base gets improvement and have a real reason to upgrade

Nope

[Colin Smith]

You just get an app which uses 100k of RAM and 32gb of filesystem buffer.

 

Re:I don't think that holds up

[Keith_Beef]

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.

They probably will.

[fuzzyfuzzyfungus]

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.

Re:The 'easy' way

[imgod2u]

The problem there is that there gets to a point where the user just won't notice "stellar" speeds. Take a video game for instance. Anything past ~70 fps is really unnoticeable by the average human eye. If you design the game to run at 70 fps for a slow and memory constrained machine, the user won't really notice his quad-SLI or whatever vacuum cleaner box being any better. And you've sacrificed a lot in visual quality.

Re:The 'easy' way

[Abcd1234]

Make developers target a slow and memory constrained platform. Then you get stellar performance when it runs on the big machines.

Hardly. Have you never heard of space-time tradeoffs? ie, the most common compromise one has to make when selecting an algorithm for solving a problem? If you assume you have a highly constrained system, then you'll select an algorithm which will work within those constraints. That probably means selecting for space over time. Conversely, if you know you're working on a machine with multiple gigabytes of memory, you'll do the exact opposite.

In short: there's *nothing wrong with using resources at your disposal*. If your machine has lots of memory, and you can get better performance by building a large, in-memory cache, then by all means, do it! This is *not* the same as "bloat". It's selecting the right algorithm given your target execution environment.

Grosch's (other) Law

[Anonymous Coward]

Herb Grosch said it in the 1960's: Anything the hardware boys come up with, the software boys will piss away.

Adding RAM to an existing device

[tepples]

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.

Re:Page's Law.

[mdmkolbe]

Do you remember Moore because of his law or because he co-founded Intel?