Path: 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 In article <798@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes: >brooks@maddog.llnl.gov (Eugene Brooks) writes: 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