Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!vrdxhq!verdix!ogcvax!pase From: pase@ogcvax.UUCP Newsgroups: comp.arch Subject: Re: shared memory multiproc. question Message-ID: <1210@ogcvax.UUCP> Date: Mon, 23-Feb-87 12:36:06 EST Article-I.D.: ogcvax.1210 Posted: Mon Feb 23 12:36:06 1987 Date-Received: Fri, 27-Feb-87 01:06:14 EST References: <1205@ogcvax.UUCP> <5699@amdahl.UUCP> Reply-To: pase@ogcvax.UUCP (Douglas M. Pase) Organization: Oregon Graduate Center, Beaverton, OR Lines: 40 In article ian@loral.UUCP (Ian Kaplan) writes: >In article <5699@amdahl.UUCP> chuck@amdahl.UUCP (Charles Simmons) writes: >>Seeing how two different people suggested that distributed memory is >>inappropriate for multiple users running independent tasks, maybe someone >>could tell me why. I find it hard to imagine a problem which is more >>partitionable. > > Someone else in this news group has already suggested that one problem > that must be solved before a distributed memory parallel processor can > be used to support multiple users is access to I/O resources. I agree > with this, but meeting this requirement is not sufficient. Assuming > that the objective is to do the sort of work that is done on the average > UN*X system, a distributed memory parallel processors is a poor choice > for supporting multiple users. > [...] Distributed memory networks have been used for multi-user systems for several years now - cf. Apollo networks. Some, at least, would argue they have been used successfully. However, machines like the iPSC were designed to do heavy computing, and NOT a lot of resource sharing. The cube manager is too much of a bottleneck to be used as a resource server to the tower. At FPS we used a 10-node Apollo network. 5 nodes had disks, but performance was still poor. Our best guess was that the network more than anything else was the limiting factor. Processors were idle while they waited for the data to come back over the net. The Apollo network used a ring, which is slow, but the point is that half of the nodes had local disks, all nodes had 2 Mbyte of memory, and performance was often bad. The iPSC has 512 Kbyte, a better network topology, and a bottleneck called the cube manager. The I/O throughput is such that it might successfully support 4 to 8 processors as task servers, but the cube manager would be absolutely swamped with much more than that. As poor as the Apollo performed, the iPSC would do worse. (To be perfectly fair to Apollo, our load was heavier than their system was really designed for.) The hypercube is set up to do number crunching, with lots of operations per byte of I/O. If your application is heavily biased towards I/O, or sharing a particular resource, the iPSC will not perform as well. What it does, it does well. Supporting lots of users just isn't one of the things it does. -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@Oregon-Grad