Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!tektronix!reed!omssw2!ogcvax!pase From: pase@ogcvax.UUCP Newsgroups: comp.arch Subject: Re: shared memory multiproc. question Message-ID: <1205@ogcvax.UUCP> Date: Tue, 17-Feb-87 19:01:17 EST Article-I.D.: ogcvax.1205 Posted: Tue Feb 17 19:01:17 1987 Date-Received: Fri, 20-Feb-87 03:29:50 EST References: <76700001@uiucdcsp> Reply-To: pase@ogcvax.UUCP (Douglas M. Pase) Organization: Oregon Graduate Center, Beaverton, OR Lines: 34 In article crowl@rochester.UUCP (Lawrence Crowl) writes: >In article <76700001@uiucdcsp> johnson@uiucdcsp.UUCP writes: >>There are a number of shared memory multiprocessors on the market today that >>consist of a number of high-end microprocessors on a single bus. > >Single bus multiprocessors tend to not scale much past 32 processors. Other >interconnection topologies scale better. The Intel Hypercube and the BBN >Butterfly scale with O(n log n) interconnection costs. Meshes and rings >scale with O(n) interconnection costs. This statement is quite misleading. For one thing, the Intel Hypercube is NOT a shared memory machine. Thus comparing scalability, cost-per-connection and soforth is much like comparing apples and oranges. For example, a certain popular shared memory machine would cost in excess of $500,000 for a 32-node configuration. Another quite popular machine with distributed memory (ie NOT shared) costs subtantially less than $200,000 for a similar 32-node configuation. IBM's RP3 is proving two points about scaling up shared-memory machines: 1) It can be done (at least to 512 processors) 2) It is very expensive The two types of machines do not compare well, as they are best used for different problems. If you want many users running independent tasks, sharing common resources with near constant response, shared memory machines are more appropriate. If you want a lower cost-per-node and you have a problem that can be partitioned into a reasonable number of communicating tasks, a distributed machine may be more appropriate. If you want to compare them, decide what you want to compare them for. In their own domains, each one out performs the other. And don't forget to include cost as part of the comparison. -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@Oregon-Grad