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

Re:Of Course

[falcon5768]

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.

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.

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.

Benefits of being able to render over 100 fps

[tepples]

Anything past ~70 fps is really unnoticeable by the average human eye.

I disagree. If you can render the average scene at 300 fps, you can:

• Apply motion blurring (think 4x temporal FSAA) at 60 fps. Film gets away with 24 fps precisely because of motion blur.
• Keep a solid 60 fps even through pathologically complex scenes.
• Render at 60 fps even when four players have joined in on the same home theater PC.

If you design the game to run at 70 fps for a slow and memory constrained machine [...] you've sacrificed a lot in visual quality.

A well-engineered game will have (or be able to generate) meshes and textures at high and low detail for close-up and distant objects respectively. On high-spec PCs, you can use the high-detail assets farther from the camera; on the slow and memory-constrained PCs that your potential customers already own, they get the low-detail assets but can still enjoy the game.

Re:Benefits of being able to render over 100 fps

[Shin-LaC]

Mod parent up. And here is a page that explains some common misconceptions.

KDE4 is ~30% faster than KDE3

[kojot350]

KDE4 is ~30% faster than KDE3, mainly because of the Qt4 vs. Qt3 improvements and vast redesign of the KDE itself...

Page's Law is really May's Law!

[Winter Lightning]

"Page's law" is simply a restatement of May's law:

"Software efficiency halves every 18 months, compensating Moore's Law".

David May is a British Computer scientist who was the lead architect for the Transputer. See:
http://en.wikipedia.org/wiki/David_May_(computer_scientist)
and page 20 of:
http://www.cs.bris.ac.uk/~dave/iee.pdf