Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!pasteur!ucbvax!BU-CS.BU.EDU!harvard!ulowell!infinet!rhorn
From: harvard!ulowell!infinet!rhorn@BU-CS.BU.EDU (Rob Horn)
Newsgroups: comp.society.futures
Subject: Mainframes and Macs
Message-ID: <8803082313.AA01918@infinet.uucp>
Date: 8 Mar 88 23:13:08 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 63


Re: Mainframes  (They aren't general purpose any more)

I think Barry and others are overestimating the importance of MIPS.
The real market for mainframes today is transaction processing and
processors are rated together with software in terms of transactions
per second.  Transactions require MIPs, but they also require fast I/O
that is organized specifically for transactions.  Transactions are
everywhere: each bank deposit, check, airline ticket, seat assignment,
credit card check, etc. is a transaction.  I heard the estimate that
Wall Street firms process about one billion transactions per day.

I have also heard otherwise intelligent people argue that UNIX cannot
handle transactions.  This is often true in the sense that current
vendor offerings are not optimal for transactions.  In terms of
transactions per second against a single database, IBM mainframes are
cheaper than Sun's.  But this is more due to a lack of effort and
interest on the part of UNIX developers.  A transaction takes a few
dozen bytes of input, does a few file I/O's (maybe), a bit of
processing, and ships out a few hundred bytes of result.  Boring.  A
transaction is only a glorified keystroke in emacs.

But look at how they are structured on mainframes.  The terminals (yes
those awful 3270's) handle the input processing and send the message
as a single unit.  IBM's archaic interupt structure makes this
particularly important, but compare the processor demand of 50
interupts on your favorite modern architecture with the total
processing needed by the transaction.  Often the interupt service
would take more CPU than the transaction.  Similarly, the structure of
the process scheduler becomes important.  In a transaction
environment, it is probably better to wait for a natural break point
like a file I/O or transaction complete, rather than interrupt a
transaction.  The mainframe makers are doing this kind of analysis and
offer the software that is tuned for transactions.  The academics and
engineering researchers mostly ignore this market.

If the new machines are tuned to meet the needs of transactions they
will probably beat mainframes with ease.  But they may also start to
look a lot like mainframes themselves.

Re: Mac's

Don't count these out so quickly.  I am writing this on a Mac that is
networked to a Sun server.  Not because I like little bitty screens,
but because of cost and software.  I need some drawing packages
(MacDraft, Design, ...) and access to multiple machines on the network
(NCSA Telnet).  I could get the same capabilities on Sun's, but the
cost for the drawing package alone on the Sun exceeded the total costs
for hardware and software for four people using Mac's.  For some
purposes the only decent software available is on Mac's.

Mac's lack multi-processing, virtual memory, and all manner of useful
capabilities, by virtue of which their lowly 68000 matches the 68020
for such things as dragging, mouse tracking, etc.  I wonder whether
they will do as well when they are also burdened by all the demands
imposed on a workstation.  This will certainly affect the future of
Mac operating systems.  I would prefer to have an environment which
was Unix plus the Mac interface, but price is definitely a factor.

				Rob  Horn
	UUCP:	...harvard!adelie!infinet!rhorn
	Snail:	Infinet,  40 High St., North Andover, MA
	(Note: harvard!infinet path is in maps but not working)