Maybe MBAs Should Design Computers After All
Not that long ago, I was under the impression that the basic problem of computer architecture had been solved. After all, computers got faster every year, and gradually whole new application domains emerged. There was constantly more memory available, and software hungrily consumed it. Each new computer had a bigger power supply, and more airflow to extract the increasing heat from the processor.
Now, clock speeds aren't rising quite as quickly, and the progress that is made doesn't seem to help our computers start up or run any faster. The traditions of the computing industry, some going as far back as the first digital computers built by John von Neumann in the 1950s, are starting to grow obsolete. The slower computers seem to get faster, and the more deeply I understand the way things actually work, the more these problems become apparent to me. They really come to light when you think about a computer as a business.
Imagine if your company or organization had one fellow [the CPU] who sat in an isolated office, and refused to talk with anyone except his two most trusted deputies [the Northbridge and Southbridge], through which all the actual work the company does must be funneled. Because this one man — let's call him Bob — is so overloaded doing all the work of the entire company, he has several assistants [memory controllers] who remember everything for him. They do this through a complex system [virtual memory] of file cabinets of various sizes [physical memories], the organization over which they have strictly limited autonomy.
Because it is faster to find things in the smaller cabinets [RAM], where there is less to sift through, Bob asks them to put the most commonly used information there. But since he is constantly switching between different tasks, the assistants must swap in and out the files in the smaller cabinets with those in the larger ones whenever Bob works on something different ["thrashing"]. The largest file cabinet is humongous, and rotates slowly in front of a narrow slit [magnetic storage]. The assistant in charge of it must simply wait for the right folder to appear in front of him before passing it along [disk latency].
Any communication with customers must be handled through a team of receptionists [I/O controllers] who don't take the initiative to relay requests to one of Bob's deputies. When Bob needs customer input to continue on a difficult problem, he drops what he is doing to chase after his deputy to chase after a receptionist to chase down the customer, thus preventing work for other customers to be done in that time.
This model is clearly horrendous for numerous reasons. If any staff member goes out to lunch, the whole operation is likely to grind to a halt. Tasks that ought to be quite simple turn out to take a lot of time, since Bob must re-acquaint himself with the issues in question. If a spy gains Bob's trust, all is lost. The only way to make the model any better without giving up and starting over is to hire people who just do their work faster and spend more hours in the office. And yet, this is the way almost every computer in the world operates today.
It is much more sane to hire a large pool of individuals, and, depending on slow-changing customer needs, organize them into business units and assign them to customer accounts. Each person keeps track of his own small workload, and everyone can work on a separate task simultaneously. If the company suddenly acquires new customers, it can recruit more staff instead of forcing Bob to work overtime. If a certain customer demands more attention than was foreseen, more people can be devoted to the effort. And perhaps most importantly, collaboration with other businesses becomes far more meaningful than the highly coded, formal game of telephone that Bob must play with Frank, who works in a similar position at another corporation [a server]. Essentially, this is a business model problem as much as a computer science one.
These complaints only scratch the surface of the design flaws of today's computers. On an extremely low level, with voltages, charge, and transistors, energy is handled recklessly, causing tremendous heat, which would melt the parts in a matter of seconds were it not for the noisy cooling systems we find in most computers. And on a high level, software engineers have constructed a city of competing abstractions based on the fundamentally flawed "CPU" idea.
So I have changed my mind. I used to believe that computers were on the right track, but now I think the right thing to do is to move forward from our 1950s models to a ground-up, fundamentally distributed computing architecture. I started to use computers at 17 months of age and started programming them at 5, so I took the model for granted. But the present stagnation of perceptual computer performance, and the counter-intuitiveness of programming languages, led me to question what I was born into and wonder if there's a better way. Now I'm eager to help make it happen. When discontent changes your mind, that's innovation.
