Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!caen!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin From: hrubin@pop.stat.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: massive parallelism, was CDC 6600 and TI ASC Message-ID: <7491@mentor.cc.purdue.edu> Date: 8 Mar 91 13:47:05 GMT References: <45252@ut-emx.uucp> <1991Mar7.215545.430@zoo.toronto.edu> Sender: news@mentor.cc.purdue.edu Lines: 35 In article , lamson@el1.crd.ge.com (scott h lamson) writes: ...................... > Given this line of reasoning, how do you look at massive parallel ala > the connection machine? Should you think of the CM as a slow scalar > machine with a super fast very long vector processor? If so, will it > fail for the same reasons you give? One difference is vector units > take only 1 clock cycle for each additional operation, whereas CM's > take no extra clock cycles for each additional operation (until you > run out of processors). but this has nothing to do with the scalar > speed argument anyway. > > or is this maybe the wrong way to look at the machine to start with. This is the wrong way to look at it, and there are huge problems with massively parallel processors handling long vectors. Here is a simple example which will be relatively poor on SIMD machines: there is a function to be computed on all arguments of a vector. There are different efficient algorithms to be used in different parts of the domain, but there is no common even moderately efficient algorithm. Now vector machines perform differently on this problem. The CRAY 1 has a considerable amount of initial overhead, which the X-MP can reduce, and then each algorithm can be used only on the relevant arguments, and a merge then carried out, with overhead slightly worse. The IBM 3090 reduces the overhead somewhat, and the CYBER 205 has this overhead quite small. If extremely fast moves of data between units could be achieved by additional instructions, SIMD machines could achieve this also, but these would not be SIMD type instructions; the data blocks would have to be individualized. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)