Slashdot Mirror
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)."
Exactly firefox 3 vs 2 is an excelent example. Especially because Firefox between major releases have been know for the opposite: Getting slower with each minor release.
There are also examples of the opposite. The KDE 3.x got faster and faster for the entire generation, while KDE 4.0 was much slower again, but here 4.1, 4.2 and especially the next 4.3 is many times fast than the 4.0 release.
So I don't think Google's ideas are unique. The issue is well known and fought against in many different ways in especially open source.
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
That's definitely a large part of the problem, but probably the bigger problem is just the operating assumption that we can add more features just because tomorrows hardware will handle it. In most cases I would rather have the ability to add a plug in or extension for things which are less commonly done with an application than have everything tossed in by default.
Why this is news is beyond me, I seem to remember people complaining about MS doing that sort of thing years ago. Just because the hardware can handle it doesn't mean that it should, tasks should be taking less time as new advancements are going, adding complexity is only reasonable when it does a better job.
Let me give you an example. 10.2 introduced Quartz Extreme, which offloaded certain 2D graphics operations from the CPU onto the graphics card. If you had a graphics card capable of supporting non-powers-of-two textures, it was snappy.
OSX 10.3 introduced Expose, a method of manipulating windows that leveraged Quartz Extreme. Flashy, but it also made skilled users more productive. It is dog slow on any mac with non-QE graphics card. It imposed a somewhat minimal load on any modern mac. 10.3 feels faster than 10.2, even though there's more going on in the background.
As for memory, memory's cheap. I recall someone defining supercomputing as "buying processing power with increased memory usage..."
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.
I would like to see your fancy C++ with templates stuff compile onto some of the proprietary toolkits I have seen for small ARM and gate array systems. Writing code that uses a number of fixed sized simple data structures all written in C makes it very easy to port it to embedded systems. The moment you use something that seems as innocuous as C++ exceptions...
This was not (and never was going to be) an application for an embedded or real-time system. I'm not sure what I said that left everyone with the impression that I'm bashing real-time or embedded development practices. I know (more now than I did before) that there are reasons for doing such things in those environments, but none of those applied in this situation.
My point wasn't that they should switch to C++ or something else. Personally, I don't like fancy C++ template stuff; I'd rather just stick with ANSI C. What I was trying (but apparently failing) to do was make the point that needless memory bloat isn't some curse that only applies to OO development, as was suggested in the post I initially replied to.
[b.belong('us') for b in bases if b.owner() == 'you']
That's still about 100 times more memory than is required to edit a text file. How do you think people got by in the 286 days when 640 Kb was standard ? Does vim allocate ridiculously oversized buffers just to show a blank screen ?
I don't mean to pick on vim specifically, all software is guilty of this pointless bloat. Instead of having tiny apps that load and run at lightning speed, we continue to build these sloppy behemoths that can't accomplish the simplest things without triggering a dozen page faults and diddling some redundant spinlocks. It's fine to add media to make things esthetically pleasing, but code bloat benefits no one.
With today's hardware and its ludicrous speed, we should be adding intentional delays to our code, because it should be running so damned fast that usability would suffer. The user should be the bottleneck, not the software. We have machines that are literally a thousand times faster than that heavy old 286, yet the load times for today's software are longer than booting Wordperfect 5.1 from a 360k floppy.
-Billco, Fnarg.com