Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!think!ames!sdcsvax!celerity!ps
From: ps@celerity.UUCP (Pat Shanahan)
Newsgroups: comp.arch
Subject: Re: Social Issues in Benchmarking Bake-offs
Message-ID: <214@celerity.UUCP>
Date: Wed, 10-Jun-87 18:21:27 EDT
Article-I.D.: celerity.214
Posted: Wed Jun 10 18:21:27 1987
Date-Received: Sat, 20-Jun-87 08:54:09 EDT
References: <4667@fritz.UUCP> <3810039@nucsrl.UUCP>
Reply-To: ps@celerity.UUCP (Pat Shanahan)
Organization: Celerity Computing, San Diego, Ca.
Lines: 40

In article <3810039@nucsrl.UUCP> ram@nucsrl.UUCP (Renu Raman) writes:
>
>    Martin hit it on the nail here about designing with compatibility in
>    mind.  Take the case of the IBM 360s/VAXens/Intel.  The 360
>    was definitely a workhorse of the 60-70s (with an excellent architecture
>    for its time) but got plagued by compatability features. 
>    The other end of the spectrum like AMD, MIPS (certainly not small)
>    where compatibility is not the issue, the designs have been bold and 
>    innovative.  Would they also degenerate into mediocrity with market
>    build-up?
>
>...

I think these things go in fairly long cycles. There are relatively short
periods when major architectural ideas become real machines, separated by a
decade or so of gradual improvement. Those periods of consolidation do not
necessarily represent "mediocrity". 

When the 360 was designed much larger volumes of code were written in
assembly language, resulting in very tight lock-in. The cost of
incompatibility reduces as more code is written in standard languages. There
is still a long way to go before source programs can automatically be moved
to new architectures without any trouble. (I wish they could, and I wish we
did not have to implement a load of FORTRAN language extensions, just
because DEC did in VMS-FORTRAN, and too many programs depend on them).

I think the trade-off between the value of a performance gain and the cost
of incompatibility is one that users have to make for themselves when
selecting a system. It is in any case useful to measure performance, even
though it will rarely be the only issue.





-- 
	ps
	(Pat Shanahan)
	uucp : {decvax!ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ps
	arpa : sdcsvax!celerity!ps@nosc