Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!umnd-cs!umn-cs!herndon From: herndon@umn-cs.UUCP Newsgroups: comp.arch Subject: Re: chewing up mips with graphics [parallel computing] Message-ID: <1716@umn-cs.UUCP> Date: Tue, 7-Jul-87 19:42:31 EDT Article-I.D.: umn-cs.1716 Posted: Tue Jul 7 19:42:31 1987 Date-Received: Fri, 10-Jul-87 04:11:52 EDT References: <8270@amdahl.amdahl.com> <359@rocky2.UUCP> <338@astroatc.UUCP> <350@astroatc.UUCP> Organization: University of Minnesota, Minneapolis Lines: 70 Keywords: parrallel computing; performance; vector computing Summary: You missed the point! In article <350@astroatc.UUCP>, johnw@astroatc.UUCP (John F. Wardale) writes: > In article <1683@umn-cs.UUCP> herndon@umn-cs.UUCP (Robert Herndon) writes: > > Parallelize that, no. Parallelize the same problem, which presumably > >is "tell me how projectile X under conditions Y will fall", is > >entirely a different question, and may be parallelizable, > >depending on the differential equation involved. Just as > ...example of... [deleted for brevity] >Your garden variety scanner is serial, but > a fancy-new algorithm called "a Mealy Machine" is much better. Point #1. > > If you mean "ALL" problems, then I'd have to agree with you. > >There certainly are problems that seem to require a serial > >solution strategy. BUT: you must differentiate between > >"a problem" and "code to solve a problem". They are NOT identical, > >and an algorithm change makes it a whole new ball game. > > New methods are great for new codes, but given the amount of code > in the world, and the number of new machines comming out, how much > effort do you REALLY think goes into each conversion ??? Point #2. > ... > I think you intentionally chose the "scanner" example so you could > claim that its in the code distributed with the system, and will > therefore be in all the vendor-supplied (system) programs, but > scanning constitues a very *SMALL* fraction of the total CPU time, > so these sort of algorithmic improvements must be applied in a > wholesale manner to all the sub-parts of each program. That will > (99.9% likely) be VERY expensive!! Point #3. Point #1. "The Mealy Machine" is a standard creature from automata theory. It has nothing to do with parallelism. I simply described an algorithm outlined in Hillis's and Steele's article in the Dec. '86 CACM that can be used to simulate a Mealy machine in parallel. Point #2. Conversion efforts vary with the amount of work required to convert something, and the benefits to be accrued to the conversion. Many heavy duty numerical simulations (e.g., airflow simulations, weather modeling, seismic analysis, ...) require large amounts (e.g., weeks) of time on Cray class computers, and are still economies. If the time could be cut down even one or two orders of magnitude by recoding these for parallel hardware, using entirely different algorithms, many firms would find it profitable to do so. Most programs do not require these kinds of efforts. So be it. Future programs, written by future programmers familiar with parallel algorithms and hardware are likely to write programs that use parallelism. Just because there is a cost to parallelism, and the cost is high, doesn't mean that there are no algorithms that will benefit from it now. There will be a learning curve, like the learning curve for high level languages. Twenty years ago, the cost of compilers was very high, and many shops refused to use them, coding everything in assembler. The transition to HLLs has been less than painless, and less than economical for the average shop in the beginning, but I don't see too many people arguing that HLLs are a mistake. Point #3. I chose the example because I knew it, it is of concern to me (being a languages & OS person), and it is something that is always presented alongside serial algorithms. Scanners and such can be automatically generated, and many programs use them. So they do drain only a small amount of CPU time in most systems. Any one algorithm you care to choose does. The power of the algorithm scheme (no pun intended) outlined is that it can be applied to many tasks to yield performance gains. -- Robert Herndon Dept. of Computer Science, ...!ihnp4!umn-cs!herndon Univ. of Minnesota, herndon@umn-cs.ARPA 136 Lind Hall, 207 Church St. SE herndon.umn-cs@csnet-relay.ARPA Minneapolis, MN 55455