Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!ames!cit-vax!news From: news@cit-vax.UUCP Newsgroups: comp.arch Subject: Re: Hypercubes and second note: (Parallel processing biblio) Message-ID: <1824@cit-vax.Caltech.Edu> Date: Thu, 19-Feb-87 17:21:38 EST Article-I.D.: cit-vax.1824 Posted: Thu Feb 19 17:21:38 1987 Date-Received: Fri, 20-Feb-87 21:15:11 EST References: <76700001@uiucdcsp> <1206@ogcvax.UUCP> <347@ames.UUCP> Reply-To: jon@oddhack.UUCP (Jon Leech) Organization: California Institute of Technology Lines: 28 Organization : California Institute of Technology Keywords: From: jon@oddhack.Caltech.Edu (Jon Leech) Path: oddhack!jon In article <347@ames.UUCP> eugene@pioneer.UUCP (Eugene Miya N.) writes: >Doug Pase writes: >>Hypercubes are hard to use only if you don't know anything about them, or >>about what they're good for. > >I won't mince words: Hypercubes are difficult to program. I've not seen >a parallel machine which is not difficult to program in some way. I I believe that conventional FBAPP languages and even LISP are not appropriate paradigms for programming such machines, which is partly why they're so horrible right now (putting junk like the 80286 inside doesn't help either). It's a pity that so much effort is going into producing hardware instead of software to use it effectively. One of the potential problems I see in better programming paradigms, however, is that there are often several ways to decompose a problem - in image rendering, for example, you can decompose in frame space, image space, object space, or combinations thereof - and a language designed to abstract away parallelism may also restrict which decompositions can be easily implemented. -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/