Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!ptsfa!pacbell!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.misc Subject: Re: First Languages (yet again) Message-ID: <3896@ihlpf.ATT.COM> Date: 4 Mar 88 03:05:16 GMT References: <4022@ames.arpa> <170500013@uiucdcsb> <2848@omepd> <15973@beta.UUCP> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 42 In article <15973@beta.UUCP> dph@LANL.GOV (David P Huelsbeck) writes: . .Crays at least do *NOT* have virtual memory. . .I once tried to argue that this was a real shortcoming .with some of the hardcore coders around here. (see organization line) .Of course being that most of my experience and information .came from my udergraduate CS studies and their experience .and information came from *real* experience, I lost. Think about *why* Crays don't have virtual memory (at least the ones doing lots of number crunching; I don't know about the ones running Unix). In order to implement this, an indirect reference (to a page table) must be made on each memory reference. This is a non-significant overhead for a machine that is designed to run as fast as possible. Also, if a page is not in memory it would sit around doing nothing waiting for the OS to put the page in memory (and possible swap one out). And it is a lot efficient to swap in exactly over some code which no longer needs to be used (ie, use of overlays), than to page as memory is needed. .So when real perfomance is a must there will .be no substitute for do it yourself, preprogrammed management like .overlays. (yes, people here use overlays often for a variety of reasons) I hope you are not implying that whenever you need performance, use overlays! This simply isn't true. It is just one of the techniques used for efficient programming. .In the past I've seen people suggest that ease of expression and understanding .should always take precidence over trying to write efficient code and .faster hardware will solve the inefficiency problem. Well we've got .a lot of pretty fast hardware and nobody seems satisfied that it runs .fast enough that programming efficiency can be ignored. That is only stressed in school. In the 'real world', people want both efficient AND readable code. Basically, use slightly harder to understand code if it will change the performance dramatically (of course this statement is situation-dependent). -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_