Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: Teradata Message-ID: Date: 30 Oct 90 19:41:00 GMT References: <1990Oct7.131537.23798@mdbs.uucp> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 84 Nntp-Posting-Host: teachk In-reply-to: zed@mdbs.uucp's message of 7 Oct 90 13:15:37 GMT Mike Bolotski (misha@ai.mit.edu) wrote: misha> The abstract shared memory model pretends that there is a large misha> number of communication paths to a single point. This simply misha> isn't true, and additional hardware is required to provide this misha> illusion to the programmer. This hardware costs time and dollars. misha> Parallel programs designed to reflect the underlying physical misha> reality will operate faster than those that work in a virtual misha> model. I suppose an IMHO is in order here. IMNHO too, by Jove! The reader will note that the "designed to reflect the underlying physical reality" does not mean "designed at the level of the underlying physical reality". On 7 Oct 90 13:15:37 GMT, zed@mdbs.uucp (Bill Smith) said: zed> This reply pushed one of my buttons. I'll try hard to be civil. I'll try hard too! zed> At first, I thought these two paragraphs said valid points, but zed> after rereading them, I realized that they deny the entire history zed> of operating system research. The whole point of a software zed> engineering environment is to hide as many details of the zed> underlying physical reality as was possible to hide at the time the zed> environment was developed. Here we disagree (euphemism). This is IMNHO a facetious view of the object of software engineering, which is to deliver cost effective solutions. If not, we would all be programming Turing machines :-). The whole point of a software engineering environment is to make it possible to use currently available technology in an abstract way, which is quite different from making currently available technology irrelevant in program design (or else we would all be functional programmers). Indeed a lot of current OS research is still dealing with the basic and regrettable fact that there are still several orders of magnitude in speed between central memory and mass storage. Indeed a lot of research in compilers and languages is based on the regrettable fact that there are huge differences in bandwidth between registers, cache, and central memory. These regrettable facts may be ignored, if you are willing to run your codes several times slower than codes with hardware dependent design choices. Some of us, e.g. Herman Rubin, spend a lot of money in CPU time each year, and even a 10% difference may mean big bucks. zed> Consider demand paged memory, NFS, Internet, pre-emptive process zed> scheduling, standard device driver interfaces, etc. The zed> performance issues are not only denigrated, but the whole point is zed> that if the computer does more work, the humans won't have to. The zed> essence of Computer Science is illusions for programmers and users. And here you shoot yourself in the foot. The fact that a lot of people think like you, mistakenly, has given us wonders like zillions of programs with poor locality of reference, zillions of poorly tuned NFS networks, etc... If you have the illusion of infinite avaiable memory this does not mean that you have infinite available memory; you still have to be very careful about memory access patterns if you want to make use of your hardware in a cost effective way, or else you can join the GNU project :-). If you have the illusion of having local disks, you still must be careful about not overloading the shared network you are using, if you want to be cost effective, or else you can join my department's support group :-). Compilers generate good assembler code for you, but you still must write well thought out and efficient programs. Aggressive optimizers may give you the illusion that you can write bad code and it will be turned magically into good code, but that means that they are becoming program generators. Abstraction is there to make your work easier and more portable, not to make hard thinking irrelevant. Pragmatics are damn important, not just semantics ("works well" is more important that "it works"...). Architecture design is the difficult task of combining pragmatics with semantics, like architecture of buildings; to make things that are both elegant and cost effective, usable within the constraints of current technology, working around or even exploiting them. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk