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)."
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.
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?
who are trying to make software be available only via a browser and clunky javascript
makes this rather ironic
"Page's Law" seems to be a tongue in cheek joke since it's sited primarily by the Google folks themselves. It definitely isn't true across the board. It's purely a matter of a) what the software application is and b) how the project is managed/developed. If the application is something like a web browser where web standards are constantly being changed and updated so the software must follow in suit, I could see where "Page's Law" might be true. But if the product is well managed and code isn't constantly grandfathered in (i.e., the developers know when to start from scratch) then it wouldn't necessarily be a problem.
"I have never let my schooling interfere with my education." --Mark Twain
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.
Sounds like someone is trying to cement their legacy in history by stamping their name on common knowledge. :-)
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.
One thing that rarely comes up when discussing bloat and slow underperforming applications is energy consumption. While you can shave off some percents off of a server by maximizing hardware energy savings you can save much more by optimizing its software in many cases.
I think it all comes down to economics. As long as the hardware and software industry lives in symbiosis with their endless upgrade loop we will have to endure this. To have your customers buy the same stuff over and over again is a precious cash cow they wont let go off volontarily.
HTTP/1.1 400
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.
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.
All of your points follows the argument "you can do 60 fps with higher quality". Which was pretty much my argument...
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.
It could or it could not. The point is the game can utilize the computing power of higher-end systems. It isn't just designed for a slow and memory-constrained machine and then runs at blazing fps on faster systems; you can change visual quality settings to use more computing power.
Because 10.0 sucked? I don't know if it was intentional or not, but that was slow enough that I noticed that speed was an issue (and I was using only the most pedestrian of software--browser and email). It was as if the OS was completely unoptimized. If subsequent releases had gotten slower, they'd have been going backwards.
My primary computer, my wife's computer, and our HTPC are all Macs, so I'm not trolling... but damn was it slow.
Interested in a Flash-based MAME front end? Visit mame.danzbb.com
The transcript leaves out a few things from the video, the main one being that Brin gives a list of applications he has specifically in mind: gmail, chrome, and Native Client. Of these, only gmail is a javascript application. Chrome doesn't run in a browser, Chrome is a browser. And Native Client is an attempt to get out of the very situation you're complaining about, where web-based apps have to be written in javascript. NativeClient (NaCl) is a browser plugin that allows native x86 code to run in a browser. If you read the paper on NaCl I linked to above, the emphasis on security is impressive. They clearly understand what a disaster things like ActiveX have been in terms of security, and they're serious about making it safe with all kinds of fancy techniques.
A couple of other observations:
They're not kidding about making performance a priority, it's not a new priority for them, and they seem to be doing well at it. When I first tried the Google Docs spreadsheet, its performance was completely unacceptable. A year or so later, it was mentioned on Slashdot again. I was all set to make a snarky post about its poor perfomance, but then I stopped and decided to try it again to see if the performance was still as bas as I remembered. It was much better, so I posted on Slashdot to say so. I then got an email from one of the developers working on Google Docs to say he was glad I'd noticed the improvement, because it had been their main priority recently.
In the video, Brin refers to "Page's law" as the "inverse of Moore's law." I would actually say it's not so much an inverse of it as a corollary of it. Developers are always going to be as sloppy as they can get away with being, and they're always going to prefer to work with languages and APIs that give them the maximum amount of abstraction, platform-independence, and expressiveness. Software houses are always going to market proprietary software based on features (which the user can read about before making a decision to buy), not on performance (which the user can't test until he's paid for the software and tried it out on his own machine). Therefore they're always going to write software that performs as badly as they can get away with. That means that if Moore's law improves hardware performance by a factor of x over a certain period of time, software developers are just naturally going to write software that performs worse by a factor of x over that same period of time.
The really scary thing about browser-based apps, in my opinion, is that they represent a huge threat to open-source software, exactly at the moment when the OSS software stack is starting to be pretty comprehensive, mature, and usable. If you look at the web apps out there, essentially all of them are under proprietary licenses, and nearly all of them are impossible to run without a server running the completely closed-source server-side code. Although Google generally seems pretty friendly toward OSS, I don't really want to have to rely on their good intentions. They are, after all, a publicly traded company, whose only reason for existing is to maximize returns for their shareholders. From this perspective, NaCl is actually pretty scary. The default with javascript is that at least you get to see the source code of the client-side software, even if it's under a proprietary license; I think it's only natural for me to demand this if my web browser is going to run random code off of some stranger's web site. With NaCl, the default will be that all I ever get to see is the object code of the program. This is even worse than java applets; java is actually relatively easy to disassemble into fairly readable source code. (And in any case, java applets never caught on.)
Find free books.
... isn't software v. hardware, but speed v. functionality, i. e., in the history of most software, the decrease in speed is disproportional to the increase in functionality. Of course, "disproportional" is subjective, and new, advanced functionalities are generally more complicated and resource intensive than old, basic ones. So a simple reverse-linear relationship might be unrealistic, but when many software don't even manage to beat the reverse-quadratic ratio, there's definitely something wrong.
I know you're trying to sound smart here. But it really doesn't take away from my point. Past point x (fill in whatever number you think is beyond the point of noticeability), you can run at any "stellar speed" you want and it wouldn't make a difference. Designing for slow systems with that in mind leads to not utilizing high-end systems.
Vista can aggressively cache *and* leave resources to user programs.
Caching is retaining resources obtained from a slow source medium in a higher speed medium after an initial request.
What Vista does is fill your RAM with stuff it thinks you're likely to use, in a background thread when your computer is idle. Thus it takes none of your (the user) time.
Nope. Not the same thing. That's precaching. A precache patch to Linux was rejected precisely because people noticed the same sorts of things Microsoft Vista users are complaining about.
The issue with precaching is lets say the operating system decides to load /usr/bin/emacs into pagecache, just because I might use it. Now, since I'm an XEmacs user that's all wasted pagecache space and the time it took to load it. Background or not, it consumes system resources.
I do want large data files, particularly obtained via NFS to be cached as long as reasonable. That's a typical work use case.
My two most frequently loaded apps are World of Warcraft and Mail.app. In neither case do I want those loaded at system boot or at any other time that I have not selected them to be loaded. WoW is for play and I want it to reside quietly on disk when I'm doing something else. Mail.app I only use when I'm connected to the company VPN. There's an idiot MSEXCHANGE server behind it, so a few seconds loading time doesn't impact the sync time once its loaded.
I certainly do not want NeoOffice precached because even though it's kind of slow to load, it's usually wasted space because I only ever need to use it once a week or so.
If Microsoft Vista is really doing precaching not caching, then perhaps you should listen to your users screaming out in pain.
The only real crime is that every other OS doesn't do the same thing.
Whatever. Linux doesn't do it because it causes performance issues. Precaching != caching. Linux, Solaris, Mac OS X seem to be pretty good at caching things people want to have cached. Or to put it in other terms, you have "invented" something that has been rejected as inferior technology in the Unix world. Can you guys please take out a software patent on it? Thanks.
Caching something that will never be used again will eventually correct itself. Precaching something that will never be used is a total waste of system resources.