Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!dog.ee.lbl.gov!ucbvax!agate!usenet.ins.cwru.edu!peregrine!csduts1!xxremak
From: xxremak@csduts1.lerc.nasa.gov (David A. Remaklus)
Newsgroups: comp.arch
Subject: Re: Computers for users not programmers
Message-ID: <1991Feb14.153747.26911@eagle.lerc.nasa.gov>
Date: 14 Feb 91 15:37:47 GMT
References: <4772@mindlink.UUCP> <1991Feb13.180108.13480@eagle.lerc.nasa.gov> <2933@charon.cwi.nl>
Sender: news@eagle.lerc.nasa.gov
Reply-To: xxremak@csduts1.UUCP (David A. Remaklus)
Organization: NASA/Lewis Research Center, Cleveland
Lines: 55

In article <2933@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>In article <1991Feb13.180108.13480@eagle.lerc.nasa.gov> xxremak@csduts1.UUCP (David A. Remaklus) writes:
> > >xxremak@csduts1.lerc.nasa.gov (David A. Remaklus) writes:
(stuff deleted)
> > Your missing the point.  I wholly agree that it is ludicrous to use
> > a CRAY for 'text' processing, but compiles, editing, link editing,
> > grep'ing, etc. are fall under my heading of 'text' processing.  Regardless
> > of the appropriateness, CRAYs perform these functions.
> > 
>And they perform these functions well (and fast).  Just tried one of my
>packages.  (Linecounts approximate:)
>	Fortran source:		117 files,	6000 lines
>	C source:		  8 files,	1900 lines
>	Asembler source:	  1 file,	2000 lines
>(of the 117 files Fortran source, 23 are include files used in many of the
>other files).  The C source files go through 'sed' before going through the
>compiler.  The other sources go through 'sed', 'cpp', 'sed' again before
>going through the compiler/assembler.  Result with fully optimized compilation:
>	real    0m47.94s
>	user    0m22.17s
>	sys     0m6.58s
>I think this is reasonably fast.  (I noticed some compile times for individual
>files; they ranged from 1.3 seconds for a 600 line source file (without
>comments) down to 0.039 seconds.)
>

Without a doubt, CRAY's are fast.  The original intent of this thread was
a question regarding instructions missing from an architecture that if
present would enable UN*X to run faster.  I offered CRAY as an example
of an architecture that was missing byte oriented operations that if present,
might make UN*X (kernel and utilities) run faster.

However, the thrust of RISC, as I understand it, is to simplify the
architecture thus enabling development of very fast fundemental elements.
While the CRAY is hardly RISC, I will concede that introduction of
byte addressing and byte instruction might very well have an inverse
effect on the overall speed of the processor.  Since people who have CRAYs
are interested in speed, the trade-off may not be worth it.

Now an architecture question.  It seems kind of silly to run certain
utilities on a CRAY.  Even though it can execute a compile or grep or
edit or etc. very fast, the vector unit sits idle for the time the
processor spends performing these functions.  Probably worst of all is
the interupt rate generated by some of these functions.  Especially since
the CRAY has one of the worst process context switch times in the industry.
Is this a necessary evil in order to get effective use of a CRAY or
wouldn't offloading this work to more 'appropriate' (the definition is
left to the reader) platforms within that ellusive seamless environment
be better?

--
David A. Remaklus		   Currently at: NASA Lewis Research Center
Amdahl Corporation				 MS 142-4
(216) 642-1044					 Cleveland, Ohio  44135
(216) 433-5119					 xxremak@csduts1.lerc.nasa.gov