Killer Micro Question vs. mainframes

[Bob Devine]

John R. Levine writes:
> An interesting paper from IBM that I saw a few years ago pointed out that for
> most data base applications, you're better off with a smaller number of
> faster processors than a larger number of slower ones even though the
> aggregate MIPS is the same.  The reason is contention -- the slower any
> single processor is, the longer it will hold its locks and the more likely
> that other processors will have to wait for it to get out of the way.
> 
> When United airlines went to a multi-CPU system a few years
> back, they cut the entire data base in two so each of two back end CPUs has
> its dedicated disk farms, and the front end (or maybe two front ends) routes
> the requests to the appropriate back end.

It's not necessarily true that mainframe databases can't use a large
number of processors.  The UAL story you closed with gives the
evidence that when a database is sufficiently partitioned into pieces
that do not cause contention (called "shared nothing" in db lingo),
a big increase in performance can be achieved.  Now, knowing the
amount of partitioning that gives the best price/performance is tough.

Sidenote: For an excursion into the dark ages of computing when all
programs were written in assembly by Real (TM) programmers and each
program knows about the machine and storage architectures, go to an
airline DP center.  I visited UAL in Denver and was amazed at the huge disk
farm and number of processors they have.  Places like that and the
credit card/banking folks will be using mainframes forever.

Bob Devine