Path: utzoo!attcan!uunet!brunix!doorknob!twl From: twl@cs.brown.edu (Ted "Theodore" W. Leung) Newsgroups: comp.arch Subject: Re: Teradata Message-ID: Date: 26 Oct 90 14:17:00 GMT References: <1990Oct7.131537.23798@mdbs.uucp> <54426@brunix.UUCP> Sender: news@brunix.UUCP Organization: Department of Computer Science, Brown University Lines: 89 In-reply-to: cgy@cs.brown.edu's message of 26 Oct 90 00:18:06 GMT >>>>> On 26 Oct 90 00:18:06 GMT, cgy@cs.brown.edu (Curtis Yarvin) said: cgy> In article <1990Oct7.131537.23798@mdbs.uucp> zed@mdbs.uucp (Bill Smith) writes: zed> This reply pushed one of my buttons. I'll try hard to be civil. cgy> And yours pushed one of mine. But I'll try too. Perhaps some gentle discussion is in order then..... zed> Why don't sponsors of large projects demand, in the requirements, that the zed> project be developed in a fashion that will port to advances in architecture zed> technology that might be reasonably expected in the next 10 (or even 5) zed>years? This is hardly a reasonable thing to do. If one looks at a recent 10 year window of advances in sequential processor architecture, one sees that there has been a notable shift away from CISC architectures toward RISC architectures. The people that invented the RISC concept gave CISC architecture a real heart attack with their results. I don't recall what large projects you were referring to, but since you are talking about parallel architecture, I'll assume that these are research projects. Part of research involves throwing something away when you've undertood that you've done it wrong. Sometimes you don't understand that you've done it wrong until you actually build one. I think that compatability assurances should be made by vendors not research teams. zed>It's taken for granted that we don't write software that depends on whether zed>the processor was implemented in CMOS, TTL, E2L or I2L. Why can't this zed>principle be extended to the next, IMHO, obvious level? The reason that current software doesn't care about semiconductor device technology is that different variations in technology all support the same abstract machine model (architectural description). The problem with moving that up to the obvious level right now is that there is no standard abstract model for parallel computers. There are a large number of people out there who will argue for a particular model, but no single one has been proven to be better than another. In fact, everyone's criteria of better seems to be different. If a common model can be settled upon, then that will be the time to create new abstractions (or eliminate non conforming architectures), right now, most people are still trying to find a general purpose abstract parallel machine -- and some people believe it can't be done. cgy> Abstraction costs. It costs in speed and it costs in memory. And not all cgy> abstractions cost the same - thus your analogy is entirely bogus. Cross- cgy> architectural abstractions can be especially expensive. And who cares if cgy> you can write a program which will work on both a Butterfly and a Connection cgy> Machine, if you can do the same job just as fast on a 386? I'm not arguing cgy> that it can't be done, and done well. But certainly nobody has done it yet. It is true that abstraction costs, but just because this is true does not mean that his analogy is bogus. Just as sequential architects experimented with a variety of concepts and have discarded a large number of them, parallel architects will probably do the same. Again, it's a matter of not understanding the problem well enough to know what to throw away. Just because nobody has done it yet, doesn't mean it can't be done. In this case, it just means that things are a lot harder than people originally thought. zed> Well, then find a better way to get 1000 nodes to cooperate! There are a number of people working on just this problem. Some of them are even building their machines, so we may have some numbers and experience to benefit from fairly shortly. zed> Again, find a better way! If you get too much contention on frequently zed> used data, design algorithms that don't have any frequently used data. zed> If cache coherence protocols are incredibly complex and impact zed> performance, design an architecture that doesn't need multiple caches zed> on a single piece of physical memory. cgy> "WAAAAAHHHHH! I waaaaanntt it faaasster! MOMMY!" Actually, zed's complaint here is somewhat reasonable. There is the emerging area of concurrent data structures, which allow high degrees of concurrent access to the structure. See Bill Dally's PhD thesis out of Caltech for more details.... The problem with all this of course, is that cooperating programs need a medium for cooperation. Most people consider that to be shared memory of one kind or another, so some of the problems of shared memory will be with us for some time. cgy> If wishes were horses, beggars would ride. cgy> And if illusions were free, we'd all be using Smalltalk. If people understood what made illusions expensive, then maybe we would all be using Smalltalk. See Dave Ungar's work on SOAR and Self for good examples. Pooh poohing abstraction because it's expensive won't work forever. Software systems are getting too expensive and complicated to keep on doing it. Ted -- -------------------------------------------------------------------- Internet/CSnet: twl@cs.brown.edu | Ted "Theodore" Leung BITNET: twl@BROWNCS.BITNET | Box 1910, Brown University UUCP: uunet!brunix!twl | Providence, RI 02912