Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!fpst From: anand@top.cis.syr.edu (R. Anand | School of Computer and Information Science) Newsgroups: comp.parallel Subject: Re: New i860 parallel machine Message-ID: <1991Apr22.123011.2109@hubcap.clemson.edu> Date: 21 Apr 91 01:03:13 GMT Sender: fpst@hubcap.clemson.edu (Steve Stevenson) Organization: Clemson University Lines: 63 Approved: parallel@hubcap.clemson.edu To: fpst@hubcap.clemson.edu Here at Syracuse University, I am surrounded by parallel computers of all sorts ranging from a Connection Machine to an Encore Multimax. Even as I type this, I am running a parallel neural-net backpropagation training program but it not on one of these machines. Instead, it is running quite happily on 8 SPARCstation 1+s. I get a speedup of about 7 with 8 workstations and the resulting throughput is quite acceptable. I have seen a number of other postings in the past few months that indicates that this simple approach has been used successfully by a number of other people. I am now coming to the conclusion that just like the LISP machines were made obsolete by the rapid increases in speeds of general-purpose microprocessors, the parallel computer as we know it today is going to face some sever challenges by networked workstations. My program uses ISIS for communication and XDR routines to ensure data compatibility between different machines. Since broadcasting is the only kind of communuication available in ISIS, it is fortunate that thats all I need. There is one master processor which broadcasts data to the compute servers and gets back results. With a conventional parallel computer, you are locked into using whatever type of processor the machine was designed for. In my case, I face no such problems. I will be shortly taking advantage of a set of RS6000s that have become available here and soon thereafter a set of HP snakes. In addition, I do not have to use a crummy program development environment of the sort that usually comes with most parallel computers. Instead, I use standard g++ (my programs are written in C++) and gdb which I find to be more than adequate. Load balancing is trivial with my setup. At the end of each iteration, the compute servers report the time taken per unit of work to the ovserseeing processor. Then for the next iteration, this overseer then apportions out the work in inverse proportion to the time taken. If someone logs into one of my compute servers, the load balancing simply shifts work elsewhere. If a machine crashes, ISIS can handle this situation quite well. My program simply regroups and continues with fewer compute servers. Ok, so now you tell me: It may be fine for you but my program is not so coarse-grained. My answer is: Go back and take a second look at your problem. It may well be possible to formulate a coarser version that what you are using now. Here is a tip: Many of the programs used on the Connection Machine are based on broadcasting. It is very likely that you may be able to adapt something you find there. R. Anand | School of Computer and Information Science anand@top.cis.syr.edu | Syracuse University. -- =========================== MODERATOR ============================== Steve Stevenson {steve,fpst}@hubcap.clemson.edu Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell