🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #3528

Re: Killer Micros and vectorized code

#3528
From: Hugh LaMaster
Date: Mon, 19 Mar 1990 22:38
93 lines
5181 bytes
In article <798@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes:
>brooks@maddog.llnl.gov (Eugene Brooks) writes:

<Various arguments deleted.>

Eugene Brooks first argument in this thread, many months ago, was that
commodity micros are going to become the basic building blocks of *most*
systems; he supplied some rather humorous descriptions of how microprocessor
based systems are now as fast, or faster, than some of the fastest systems
based on specially designed CPUs: e.g. Cray.

Then, he added a correction stating that he was *not* arguing that desktop
*systems* were going to replace all other systems.

Various polemics followed :-)

****************************************************

The question: what is a more optimal *system*: a network of personal
workstations or fewer more centralized servers giving individual users
X terminals?

Answer: (Mine, of course): *it depends*.  On the same campus, some
people are better served by one model of computing, some by another.  In
my experience, it depends on a number of factors:

1) Availability on the existing staff of *experienced system administrators*.
If you already have someone, you have more choices.  If you don't, usually
a more centralized system will serve you better, because someone else will
do all the system care and feeding.  Someone who is an expert may be able
to take care of the job with only a little overhead; a novice may get 
consumed by it.

2) Whether or not *time critical* work is done.  Most people believe, and
rightly so, in my experience, that time critical data acquisition and
analysis *cannot* be done reliably on shared resources.  It just doesn't
cut it to say that you are losing $10,000 an hour on an expensive test
because the shared compute resource is saturated.

3) The nature of the job, and what kind of *networking* resources it
demands.  "MIPS", whatever they are, are almost free these days for most
general purpose computing.  But, *systems* are not free.  Systems require
memory, access to data, and may require moving data across various low
bandwidth and expensive channels, like networks.  The cost of the 
processors is a relatively low part of the overall system cost these
days for many systems.  You have to look at entire picture.  It may 
be cheaper to keep many processors idle most of the time if it means
better *network utilization*, because networks are a more costly resource
than "MIPS" in today's typical computing environment.

4) The cost of coordinating work.  People time costs money, and the more
distant someone is in an organization, the harder it is to share common
resources.  This isn't "wasteful"; *time is money*.  Anyone's job is to
get results.  The cost of coordinating with a lot of people to use
hardware "efficiently" may be *much* greater than the cost of the "wasted"
hardware.  This is particulary true if computing resources are on the
critical path in any project.  Project management of large projects is
tough.  Why let computer utilization become an issue:  the goal is to
do the most with the least, and overall cost and efficiency are much
more important than the utilization of any one resource, including office
space, computers, etc.   That being said, it usually isn't the issue for 
most numerical simulations, where the speed of the hardware determines 
what is possible, and efficient utilization of scarce resources, like
Cray memory and memory and I/O bandwidth is a day to day task.

********************************************************


So, I don't think there is one answer for what is most cost effective.
It all depends on the job at hand.  That is why you need engineers, to
figure out how to get something done as cheaply as possible.  You don't
need a "policy" to decide that desktop systems, file servers, or
supercomputers are best: you need to study the job at hand and figure out
how to do it best.  Whoops: back to work :-)


********************************************************
********************************************************


Speaking of architectural issues, how is the BBN TC 2000 working out?
It should be a perfect example of Killer Micros in action.  But,
I was rather surprised that the TC 2000 Butterfly switch is only 8 bits (!)
wide and only supports a maximum memory bandwidth of 2.4 GBytes/sec
for a 63 processor system.  A Cray Y-MP has about 40 GBytes/sec of total
memory bandwidth, for reference.

 

  Hugh LaMaster, M/S 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)604-6117       
Technical Details
Message-ID: <45408@ames.arc.nasa.gov>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!uwm.edu!bionet!ames!ames.arc.nasa.gov!lamaster
References: <51771@lll-winken.LLNL.GOV> <100598@convex.convex.com> <52661@lll-winken.LLNL.GOV> <798@dgis.dtic.dla.mil>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!uwm.edu!bionet!ames!ames.arc.nasa.gov!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: Killer Micros and vectorized code
Message-ID: <45408@ames.arc.nasa.gov>
Date: 19 Mar 90 22:38:29 GMT
References: <51771@lll-winken.LLNL.GOV> <100598@convex.convex.com> <52661@lll-winken.LLNL.GOV> <798@dgis.dtic.dla.mil>
Sender: usenet@ames.arc.nasa.gov
Organization: NASA - Ames Research Center
Lines: 93