Can "Page's Law" Be Broken? 255
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)."
Of Course (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.
Comment removed (Score:4, Informative)
Re:Of Course (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.
Re: (Score:3, Informative)
Then MS and Vista must have knocked your sox off!
Funny you should say that, because it's an example that drives the point home so well. For all the flack Vista got about performance, on the day it was released, you could buy a PC - for less than the price of the cheapest iMac (a machine that would barely run OS X at all) - that would run it *well* (dual-core, 2GB RAM, 256MB GPU).
In contrast, it took Apple *years* after OS X 10.0 - and due at least as much to dramatically faster hardware as improved soft
Re: (Score:3, Interesting)
IMO, the measure of new softwares speed is best measured on older (6-12mo old) hardware since the older version was not written with the newer hardware in mind and the newer software was written with the old and new hardware in mind (or at least should have been).
I grant that early versions of OS X were not r
Re: (Score:3, Insightful)
You give developers far too much credit. They don't code to previous-gen and current-gen hardware, they let the compiler worry about making it run fast. New compilers = new optimizations. New processors = new compiler flags to enable. I don't think the average Mac developer actually tunes his/her code for any specific hardware generation. If it runs on their development machine, it gets shipped an hour later.
Re: (Score:2)
Re:Of Course (Score:4, Interesting)
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..."
quote (Score:3, Informative)
A supercomputer is a device for turning compute-bound problems into I/O-bound problems.
-- Ken Batcher
Re: (Score:3, Interesting)
Re: (Score:2)
10.5 puts a bit of a load on older machines. Time Machine, though very useful, occasionally bogs down my 1.25 PMG4. On a modern mac, it's just an extra thread.
Re: (Score:3, Interesting)
I found (and measured) 10.3 faster than 10.2 on my then-computer, and 10.4 faster than 10.3 (once indexing was complete). Numbers long since lost, though, sorry.
Re: (Score:2)
I can't speak to emacs, but these says vi is generally vim, which is much much heavier than classic vi. It also does vastly more.
Re:Of Course (Score:5, Funny)
I can't speak to emacs...
RTFM.
C-x M-c M-speak
Re: (Score:3, Insightful)
Re:Of Course (Score:4, Interesting)
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.
Re:Of Course (Score:5, Insightful)
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: (Score:2, Interesting)
The law isn't linear, it's more sawtooth-style.
All data looks notchy if you sample it at high resolution and don't apply smoothing.
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.
RAM is cheap these days. Storage devices are still slow and the most interesting ones have a finite (Though still large) number of writes.
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
In fact you will often see today that a job that could be handled by a 555 and a couple of caps has been replaced with an internally-clocked microcontroller simply because it's a known platform and development is easy. When you have is a vertical mill, everything looks like a machining pro
Adding RAM to an existing device (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 [wikipedia.org] came with a RAM expansion card.
Re: (Score:2)
In fact you will often see today that a job that could be handled by a 555 and a couple of caps has been replaced with an internally-clocked microcontroller simply because it's a known platform and development is easy.
One microcontroller beats one special-function chip plus caps on part count, board space, power consumption, and probably cost. And it can take care of other odd jobs around the circuit as well.
Re: (Score:3, Insightful)
It wins big in more than one category.
Re: (Score:3, Insightful)
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.
RAM is cheap these days.
I thought we were talking about performance? Adding more memory for a slow app does not necessarily make it faster when we're involved with parallel architectures. Maybe that ought to be a law of its own. See http://lwn.net/Articles/250967/ [lwn.net]
All memory is not created equal. As CPU speeds have risen, it is becoming increasingly expensive to access main memory - you need to keep things in the CPU cache(s). As NUMA architectures increase in importance, that will become even more true. Today's supercomputer
Re: (Score:3, Informative)
This attitude is actually the root cause of the problem, I've never heard this called "Page's Law" but in the industry it's known as "Code Bloat".
No, it's called making a design decision. If the RAM is cheaper than doing it with less RAM, then you buy more RAM. If it isn't, you spend more time on design. The only bad part about it is when it leads to excessive power consumption. Which is, you know, all the time. But that's really the only thing strictly WRONG with spending more cycles, or more transistors.
Re: (Score:2)
But... All software I installed on my computers, was free (as in everything) for me. So I care for not buying another piece of RAM.
Oh, and you can also can have less memory consumption by doing less. Which is called "feature bloat". (Not the good one, like in KDE, but the bad one, like in MS Office.)
Re: (Score:3, Insightful)
If you don't want bloat, fine. Don't use any windower (they all have feature creep lately), use lynx, use pine, use the lightest install you can find.
But you would be in a tiny, infinitesimal almost, minority. Actually not, since you admit that KDE's bloat is fine. One person's bloat is another's essential feature. Looking into the OSS world, Vim and Emacs are the definition of bloat. Why use a simple editor, when you can have your own mini-OS?
In apps like Office, and Photoshop, there are, suprisingly,
Re: (Score:3, Funny)
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.
That sounds like bad software design that isn't specific to OO programming. People are perfectly capable of wasting memory space and CPU cycles in any programming style.
For example, I worked with "senior" (~15 years on the job) C programmers who thought it was a good idea to use fixed-size global static arrays for everything. They also couldn't grasp why their O(N^2) algorithm--which was SO fast on a small test data set--ran so slowly when used on real-world data with thousands of items.
Re: (Score:2, Interesting)
Re: (Score:3, Funny)
That must be why there were dozens of threads updating and reading from these massive global arrays without using any kind of synchronization mechanism.
Shows what you know, they were just using classic Mongolian Actorfuck Model :)
Re: (Score:3, Informative)
Almost any modern system, to the CPU, a 32-bit aligned access is atomic. If they were just reading the global array, there is no need to use a lock, in fact this is a placebo lock, that adds unnecessary burden on the memory or reservation system. It is common for realtime that the global data is only modified at certain times when readers are not running.
Re: (Score:3, Informative)
This wasn't a realtime system, and they weren't just doing atomic updates to a single array. There were transactions that involved changes to multiple data structures, and there was no synchronization of any kind. There were several long-standing bugs caused by reader threads getting their data while another thread was halfway through an update.
Sorry for not including all this detail in my original post.
Re:Of Course (Score:4, Interesting)
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.
Re:Of Course (Score:4, Interesting)
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.
Re: (Score:3, Informative)
Have you read his follow-on comment?
http://slashdot.org/comments.pl?sid=1252121&cid=28173153 [slashdot.org]
Here's the money quote:
There were several long-standing bugs caused by reader threads getting their data while another thread was halfway through an update.
That behaviour can't be intentional. :)
Re:Of Course (Score:4, Insightful)
Thanks for trying, ion.simon.c. I didn't know it was this big of a sin to accidentally offend realtime developers on Slashdot.
Re: (Score:2)
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.
Surely this is a problem begging a solution in the form of smarter compilers?
Re:Of Course (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...
Re: (Score:3, Informative)
I think there are a lot of copy constructors called when using STL that a lot of people do not expect. The algorithms themselves tend to be well implemented though. None of that really has much to do about OO though, templates with structs with no member functions and lots of casting of void * could have been used instead.
Re: (Score:3, Interesting)
Emacs - proof you can write an entire operating system without a single line of OO code :)
Re: (Score:3, Insightful)
Since C structs are effectively C++ objects, would you be against using structs for the same reasons too?
Re:Of Course (Score:5, Interesting)
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.
Re:Of Course (Score:4, Interesting)
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.
KDE4 is ~30% faster than KDE3 (Score:3, Informative)
Re: (Score:3, Insightful)
If it get's broken, it's not a law.
What's the obsession these days with calling observations "laws"?
Moore's law is simply an observation, as is this. Actually software will be as slow as hardware of the period allows, rarely faster. Can we call this Bill's Law? Note the relationship between Moore's and Page's is obvious when you consider Bill's law.
Hmph, it's all just observations that happen to hold true for a short period. If that period happens to be 20 years, us short-lived humans extrapolate it to
The 'easy' way (Score:3, Interesting)
Make developers target a slow and memory constrained platform. Then you get stellar performance when it runs on the big machines.
Nope (Score:5, Funny)
You just get an app which uses 100k of RAM and 32gb of filesystem buffer.
Re:The 'easy' way (Score:5, Insightful)
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.
Benefits of being able to render over 100 fps (Score:4, Informative)
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:
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 (Score:4, Insightful)
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.
Re:Benefits of being able to render over 100 fps (Score:4, Informative)
Re: (Score:3, Insightful)
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.
There's constrained, and then there's constrained. (Score:2)
Make developers target a slow and memory constrained platform.
I hope you're not talking about something like the NES. There are some things that just won't fit into 256 KB of ROM and 10 KB of RAM, like a word processing document or the state of the town in a sim game like SimCity or Animal Crossing.
Then you get stellar performance when it runs on the big machines.
Only if the big machines use the same CPU and I/O architecture as the small machines. Otherwise, you need to use an emulator that brings a roughly 10:1 CPU penalty (e.g. PocketNES), or more
Re: (Score:3, Funny)
Ah ha, the business model behind Android finally reveals itself :)
Re: (Score:2)
Designed to run on a netbook? Less bloat? Reduced cost to the consumer? Win-win.
I use third party media players and don't care about Aero Glass. If it supports DX10, we have a new Windows gaming platform.
Re:The 'easy' way (Score:5, Informative)
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.
"cache" (Score:3, Insightful)
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
Re: (Score:2)
Make developers target a slow and memory constrained platform. Then you get stellar performance when it runs on the big machines.
Non-sequitur.
Most bang for the buck. (Score:5, Insightful)
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: (Score:2)
Moore's law (Score:2)
Unlike workstations where(as you say) the value of going from "workstation adequately responsive, 60% load" to "workstation adequately responsive, 30% load" is pretty much zero
Not always. A notebook computer running at 60% load draws more current than one running at 30% load. But LCD backlights eat a lot of power too, and the licensing policy that Microsoft announced for Windows 7 Starter Edition (CPU less than 15 watts) might encourage CPU engineers to move more logic to the GPU and the chipset.
If you have thousands of instances, gains of even a few percent mean substantial reductions in the number of servers you need to run.
Moore's law predicts that transistor density on commodity integrated circuits doubles every 18 months. This means more cores can fit on the same size chip. If your applications are inhere
Re: (Score:2)
you can just throw more new hardware at the problem
You forgot that this also costs money.
It costs money to replace hardware that wears out, such as hard drives and fans. Eventually, it costs more especially in labor to keep fixing a server than to replace the server with a newer, faster server.
Replace worn-out boxes with new boxes (Score:2)
Constant , not most, bang for the buck (Score:2)
Actually, if you're doing test-directed development, you should have a test that tells you if you've met your performance needs or not. Your management wants to know they have a certain amount of bang/$, to meet their performance budget.
For user-interface stuff, that could be as simple as "3 seconds on average, no more than 5% over 20 seconds", for some number of simulated users on your development machine.
So build a test framework and measure the first part of the program you write. For example, that
Re:Most bang for the buck. (Score:5, Interesting)
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
Re: (Score:2)
Over the entire company, what might be a minor waste of time for one person can become significant very quickly, which is one of the reasons why updating computers and adding a second monitor can be such a profitable move for a company. Tweaks like that do cost money in the short term, but frequently pay off in the long term.
The only t
Re: (Score:2)
And just to hammer the point home, this is one of the areas where FOSS is inherently superior; nobody can tell that developer to stop optimizing that loop and go write a new feature. (Unfortunately, nobody can tell them to stop writing new features and fix bugs, either; no plan is perfect.)
Re: (Score:2)
Try running any latest version of KDE on hardware that's several years older than it.
AFAIK there's mobile versions of QT, dunno about KDE but there's definitely a mobile GNOME-equivalent (GPE). Angstrom Linux is a distribution based around it, built on OpenEmbedded. I'm working (off and on) to get Angstrom to run on my DT Research WebDT360 (Geode LX 800-based) and have run it on my iPaq H2215 with mixed results.
coming from google (Score:2, Insightful)
who are trying to make software be available only via a browser and clunky javascript
makes this rather ironic
Re: (Score:3)
No it is their justification to run Office in a Web browser which I did back in 2001, with Think Free Office. Think Free guys used to rely on Java but it changed as technology progresses, now they use mixture of Java, Ajax and HTML technologies. I think some Flash will be involved too.
Of course, same people laughing at me while using a Office written in Java now talks about what kind of a modern idea Google invented (!) after 8 years.
Of course, native vs. interpreted application? I purchased Apple iWork, fu
Re: (Score:2, Insightful)
Google Native Client (Score:4, Insightful)
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 [googlecode.com]. 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.)
2 reasons why software gets bigger. (Score:2)
2) The perception of value. More megabytes implies more features implies more value. You can charge more. Also, you can charge people again for what is basically the same product (there are companies that depend on this!)
Re: (Score:2)
wow moderators today dont have a sense of humour (yes that a U in there :D )
Re: (Score:2)
Obama is a computer?!
No, but Jamie Foxx and T-Pain are robots [youtube.com].
I don't think that holds up (Score:3, Insightful)
Re:I don't think that holds up (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.
Speaking of hardware power to waste (Score:2)
I wasn't talking about it for a while as I am tired of Google fanatics but, what is the point of running a software with Administrator(win)/Super User(Mac) privileges every 2 hours that will... check for updates?
I speak about the Google Updater and I don't really CARE if it is open source or not.
Not just that, you are giving a very bad example to industry to use as reference. They already started talking about ''but Google does it''.
Is that part of the excuse? Because hardware guys beat the badly designed s
They probably will. (Score:5, Insightful)
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.
Incentive to run on existing deployed hardware (Score:2)
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.
Then why are games for PlayStation 2 still coming out years after the launch of the PLAYSTATION 3 console? If the incentive to run on existing deployed hardware were so small, major video game publishers would make their games PS3-exclusive even if the game's design didn't require it.
Re: (Score:2)
Since consoles move in large, discreet steps, the particular indirect pressure noted above is extremely significant. In the case of the playstation, the PS2 was released ~2000 and the PS3 ~2007. Nothing in between, one or the other and the PS2 has a vastly greater installed base. Because specs are fixed, requirements don't get to drift upward. They either stay still, or jump.
PCs aren't wholly different, any publisher of "casual games", fo
emulation layers (Score:2)
When I was a little kid, I saw a new computing device: a Pacman cabinet at the local pinball parlour.
Since then, I've seen dozens of implementations of it, and they fall into two camps: a knockoff that can hardly be called a Pacman-clone, or a full-up 100% authentic duplicate of the original. Of course the latter is done with emulation. Every important detail of the old hardware can be emulated so a true ROM copy can be run with the same timing and everything behaves properly. If you know the proper sec
Page's Law. (Score:3, Insightful)
Sounds like someone is trying to cement their legacy in history by stamping their name on common knowledge. :-)
Re:Page's Law. (Score:5, Insightful)
Do you remember Moore because of his law or because he co-founded Intel?
Re: (Score:2)
There is a difference here. Software development isn't something new. It's always been known that the more lines of code, generally the slower the execution of the application envolved. Moore pioneered much of the world of CPUs, and Moore's law was named after him, because he was the first to make the observation. A bunch of guys guzzling beer in the back room making a joke, didn't make Larry first. Hell, the world has been screaming about Microsoft's bloatware well before Larry even had the idea to cr
Code Bloat? Think twice. (Score:2)
We could also consider the possibility that a twice-as-fast computer on a twice-as-fast network pipe produces twice-as-much data which, in order to keep the same perceived speed, must be processed twice-as-quickly by another computer.
Re: (Score:2)
We could also consider the possibility that a twice-as-fast computer on a twice-as-fast network pipe produces twice-as-much data
But why is it producing twice-as-much data? Is it receiving twice-as-many requests? If so, from whom? Twice-as-many users? Or a single user doing twice-as-many things?
Bloat wastes energy. (Score:2, Insightful)
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
Meanwhile Looser's Law *is* broken... (Score:2)
From the transcript of the speech:
"you never loose a dream"
Yes! (Score:2)
It's simple, just don't use Java
In a more serious note, my personal opinion is have the developers use and test the programs in slower machines.
Yes, they can profile the app, etc, but the problem is that it really doesn't create the 'sense of urgency' working in a slow machine does. (Note I'm not saying developers should use slow machines to DEVELOP, but there should be a testing phase in slow machines)
Also, slower machines produce more obvious profile timings.
Grosch's (other) Law (Score:4, Informative)
Herb Grosch said it in the 1960's: Anything the hardware boys come up with, the software boys will piss away.
Larger user base (Score:3, Interesting)
Ask Apple how they do it. (Score:3, Interesting)
10.0, 10.1, 10.2, 10.3, and maybe 10.4 was a series of releases where performance improved with each update. I don't run 10.5 so can't comment if the trend continues.
Re: (Score:2)
Re: (Score:3, Insightful)
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.
We don't want it to be broken, really (Score:2)
Hardware has advanced to the point that we don't care about performance all that much.
What is more of a concern is how easy it is to write software, and how easy it is to maintain that software, and how easy it is to port that software to other architectures. Efficiency of code generally means efficient use of a single architecture. That's fine, but for code that has to last a long time (i.e., anything besides games), you want it to be written in a nice, easy-to-change way that can be moved around to diffe
Moar users! Moar battery life! (Score:2)
Hardware has advanced to the point that we don't care about performance all that much.
That might be true of software intended to run on desktop PCs. But for servers, you want efficiency so you can handle more requests from more users. And for software intended to be run on small, cheap, battery-powered devices, you want efficiency so you can underclock the CPU and run longer on a charge. You mentioned games, but a lot of applications for handheld and subnotebook computers aren't games.
Theoretically, yes. Practically, not often (Score:3, Interesting)
Business managers don't want to pay for great when good will do. Have you gotten the beta to compile yet? Good, we're shipping. I don't care if it was a tech demo, I don't care if you said your plan was to figure out how to do it first, then go back through and do it right. We have a deadline, get your ass in gear.
Then the next release cycle comes around and they want more features, cram them in, or fuck it we'll just outsource it to India. We don't know how to write a decent design spec and so even if the Indians are good programmers, the language barrier and cluelessness will lead to disaster.
And here's the real kicker -- why bother to write better when people buy new computers every three years? We'll just throw hardware at the problem. == this is the factor that's likely to change the game.
If you look at consoles, games typically get better the longer it's on the market because programmers become more familiar with the platform and what it can do. You're not throwing more hardware at the problem, not until the new console ships. That could be years and years away, just for the shipping, and even more years until there's decent market penetration. No, you have to do something wonderful and new and it has to be done on the current hardware. You're forced to get creative.
With the push towards netbooks and relatively low-power systems (low-power by today's standards!), programmers won't be able to count on power outstripping bloat. They'll have to concentrate on efficiency or else they won't have a product.
There's also the question of how much the effort is worth. $5000 in damage to my current car totals it, even if it could be be repaired. I can go out and buy a new car. In Cuba, there's no such thing as a new car, there's only so many on the market. (are they able to import any these days?) Anyway, that explains why the 1950's disposable rustbuckets are still up and running. When no new cars are available for love or money, the effort in keeping an old one running pays for itself.
Excellence has to be a priority coming down from the top in a company. If cut-rate expediency is the order of the day, crap will be the result.
Page's Law is really May's Law! (Score:3, Informative)
"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) [wikipedia.org]
and page 20 of:
http://www.cs.bris.ac.uk/~dave/iee.pdf [bris.ac.uk]
10 years experience on this (Score:3, Interesting)
I have realized that I will have been working as a dev for ten years now in four days. I've worked at a few places and I think that the reason for this is pretty straight forward, poor benchmarks used poorly.
We have all heard the mantra about optimizing early is evil but there are two issues to contend with. You get to a crunch time towards the end and then there is no time to address performance issues in every project. By that time so much code is written that you cannot address the performance issues in the most effective way, thinking about what algorithm to use in the dataset that ends-up being the common case. So instead some profiling work gets done and the code goes out the door.
So for success you need to have some performance measurements even early on. The problem is that in that case you end-up with some benchmarks that don't measure the right thing (that is what you discover near the end) or you have worthless benchmarks that suffer too much from not being reproducible, taking too long to run, or not giving the dev any idea of where the performance problem really is.
So what ends-up happening is that only after the code base has been around for a while and you get to rev n + 1 is there any real handle on any of this performance stuff. But often what ends-up happening is that project management values feature additions so as long as no single benchmark decreases by more than 2-5% and the overall performance does not decrease by more than 15% compared to the pre feature build, it gets the okay. Then a milestone arrives and there is no time again for systematic performance work and it ships as is.
The right approach would be at that stage to not allow a new feature unless the overall benchmark does not improve by 2% and to also benchmark your competitors as well but that just does not happen except in the very rare good groups sadly.
The really important comparison (Score:3, Insightful)
... 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.
Re: (Score:2)
Or as I like to say, "Half Fast."