Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ncrlnk!ncr-mpd!Chuck.Phillips From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) Newsgroups: comp.arch Subject: Re: Teradata Message-ID: Date: 29 Oct 90 11:39:00 GMT References: <1990Oct7.131537.23798@mdbs.uucp> Sender: uucp@ncr-mpd.FtCollins Organization: NCR Microelectronics, Ft. Collins, CO Lines: 79 In-reply-to: zed@mdbs.uucp's message of 7 Oct 90 13:15:37 GMT >>>>> On 7 Oct 90 13:15:37 GMT, zed@mdbs.uucp (Bill Smith) said: Bill> What ever happened to software engineering? If "most parallel Bill> software was written under the shared memory model", it is, by Bill> definition, not portable. Considering multi-processor architectures account for a small portion (<1%, I'd guess) of _existing_ computers, _anything_ depending on parallelism is, by definition, non-portable. If your objective is maximum portability, parallelism doesn't make it out of the starting gate. Also, the prevalence of software for the shared memory model is no accident; most new development of <=20K$ multi-processor systems involves loosely coupled shared memory architectures. This may change, but it certainly appears to be the current trend. Bill> If it is not portable then, in the long term, the software will cost Bill> more to keep than to toss it today and start over with a better Bill> software model. Not necessarily. I, for one, would guess it costs less to rewrite as needed (and _if_ needed) than to attempt to anticipate the lowest common denominator of every "reasonable" architecture that may be invented over the next 5 years. Quantitative oriented (a.k.a. RISC) engineering is pushing single processor design throughput ever nearer to the physical limits of switching speed. In the pursuit of ever higher throughput, I _expect_ the emergence of a plethora of new parallel designs and the re-emergence of old parallelism ideas no longer impractical due to subsequent technology advances. Further, I _expect_ all this in just the next 5 years. The best a software engineer can do, IMHO, is to use a language that allows the programmer the option of abstracting parallelism (e.g. Concurrent C/C++, etc.) and leave it to compiler designers and hardware designers, in tandem, to implement concurrent HLL's as efficiently as possible (and then, for compiler designers to find and exploit high level parallelization even when concurrancy is _not_ explicitly marked by the programmer). >While sharing at the page level across a network works, increasing >the number of workstations to say, 1000, will seriously impede >performance. Bill> Well, then find a better way to get 1000 nodes to cooperate! >I disagree. Shared memory automatically creates contention at >for frequently used data. ... Bill> Again, find a better way! If you get too much contention on Bill> frequently used data, design algorithms that don't have any ^^^ Bill> frequently used data. This isn't _always_ possible! (Some OLTP DBMS applications immediately come to mind.) That said, one approach is to encapsulate the data a la Object Oriented Design and use a client-server model to reduce network traffic. That is, the remote client only performs the most abstract of manipulations (hopefully reducing network overhead) while the server does all the heavy I/O, low level manipulations and provides enforcement of data integrity. X Windows is an example. Display PostScript, in its various forms, is even more so. This is _not_ a panacea, but it often works. Bill> The whole point of a software engineering environment is to hide as Bill> many details of the underlying physical reality as was possible to Bill> hide at the time the environment was developed. Consider demand Bill> paged memory, NFS, Internet, pre-emptive process scheduling, standard Bill> device driver interfaces, etc. The performance issues are not only Bill> denigrated, but the whole point is that if the computer does more Bill> work, the humans won't have to. The essence of Computer Science is Bill> illusions for programmers and users. Well put. Hmmm. Perhaps we're in agreement after all. :-) I'd add the caveat, "Adopt no illusion before its time". (e.g. using Lisp for OLTP:-) #include -- Chuck Phillips MS440 NCR Microelectronics chuck.phillips%ftcollins.ncr.com 2001 Danfield Ct. Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckp