chased@rbbb.Eng.Sun.COM (David Chase) (11/10/90)
pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >The problem, bfore considering market demand, can also be expressed >thus: should David Chase and Jim Giles and Preston Briggs and Hank Dietz >(just to mention some frequent contributors to this sort of discussion) >spend their time devising ever more ingenious and complicated and hairy >code generator level hacks, or would their research and development >efforts be better spent on clever compilation of higher level languages >and source level programmer's assistants? I *was* working on (not yet clever) compilation of a slightly higher level language at Olivetti, but we all got laid off in February and had to find new jobs. It's very nice being employed, paid, and appreciated. Without a job, one tends to consider market demand, especially with a baby on the way and no national health insurance. There's no lack of higher level alternatives that would probably be more reliable than C, C++, and Fortran, optimized or not, and many of my colleagues, advisors, and advisors' advisors have tried hard to sell/give/push them to the rest of the world. So far, they've had little luck. I'll bide my time; there's many interesting aggressive optimizations that can also be applied to high level languages too, when they finally catch on. To quote Rovner (PARC CSL-84-7): "Time spent by programmers to solve storage management problems has decreased from an estimated 40% in Mesa to an estimated 5% in Cedar (...). Automatic storage deallocation can improve programmer productivity dramatically without affecting performance adversely." That's the big picture that you're looking at, and the one that I'd like to look at, but so far the programming public in general is not interested. We've tried very hard to get them interested, but not much luck yet. (I.e., at least in this case you are preaching to the choir). Now, once you've opted for C/C++/Fortran, and the ultimate importance of efficiency, one might as well deliver it as reliably and portably as one can. Optimizing compilers fill that (very large) niche; they tend to be less buggy at optimizing C/C++/Fortran than your average programmer, and tend to do a good job. Compilers can be regression-tested, and their known bugs can be catalogued, and hopefully repaired -- neither of these things holds for humans. Those people on the C/C++ bandwagon who *are* interested in garbage collection are discovering that optimizations (not even terribly aggressive ones) *correctly* applied to C/C++ can prevent the correct functioning of many garbage collectors, unless "volatile" is applied liberally to the code (this is massive overkill, but it makes the collectors work). Daniel Edelson's C++ collector is *probably* robust in a single-threaded process, especially if a small number of "volatile" declarations are used, and may be robust in a multi-threaded process (the possible non-robustness appears only if a compiler is very aggressive about tracking of aliases and reordering of loads and stores for scheduling or other purposes -- clearly, this is permitted -- else why would the language have "volatile" in it?) If I were king of the world, things would be different. But I'm not. David Chase Sun Microsystems
mjs@hpfcso.HP.COM (Marc Sabatella) (11/15/90)
>> Jim, you've made a blanket assertion that arrays are as efficient as >> pointers. I've proven you wrong. Give up. > >You have not even posted _one_ counter-example. Perhaps not, but *I* have. You just chose to brush it off by saying, "oh well nobody writes code like that anyhow, or at least they shouldn't". For those with short memories: if you compute "pointer = base + offset" in one procedure, and pass the pointer to another procedure, then there is only one addition in the two procedures. With arrays, unless you have interprocedural flow information (especially hard between source files, even more so if one routine is in a library), you'll have to perform the addition twice - once in each procedure. Extend this to several procedures, and pointers win by a wider margin (still only one addition required). Or you could pass the array element by reference, but this requires relaxing of type rules if you want to actually access other members of the array in the called procedure. It seems to me this relaxation, if allowed by the language, would tend to weaken non-aliasing assumptions as well, or would at least place heavier burdens on the programmer to avoid aliasing. I find this argument kind of pointless though; I rarely care about one integer addition. In fact, on some processors, indirect addressing is just as fast with or without an index. I use pointers because the abstraction they provide is indeed useful to me. I use arrays relatively rarely, as that abstraction is not normally as useful to me. As you may have guessed, I do mainly systems programming, not mathematical. I will indeed grant that I wish the compiler would recognize that my application of dynamic relocation records cannot affect the relocation records themselves. But don't take away my pointers; just give me the means to specify either type of declaration. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me
jlg@lanl.gov (Jim Giles) (11/16/90)
From article <8960024@hpfcso.HP.COM>, by mjs@hpfcso.HP.COM (Marc Sabatella): > [...] > For those with short memories: if you compute "pointer = base + offset" in > one procedure, and pass the pointer to another procedure, then there is only > one addition in the two procedures. [...] > [...] > Or you could pass the array element by reference, but this requires relaxing of > type rules if you want to actually access other members of the array in the > called procedure. [...] No, actually it doesn't. Not if the language has a "whole array" syntax. In such a language, you pass the _specific_ section of the array that the next procedure needs. This section is completely type checked. So, here are the two procedures: Procedure sub1(whatever) integer :: x(50), offset, end ... offset = 10 end = 20 ... sub2(x(offset:end)) !this adds offset to base ... end sub1 Procedure sub2(integer :: a(:)) ... !in here, the add of offset to base never occurs end sub2 > [...] It seems to me this relaxation, if allowed by the language, > would tend to weaken non-aliasing assumptions as well, or would at least place > heavier burdens on the programmer to avoid aliasing. But, not by as much as pointers do! And, not at all, if the loader propagates information about aliasing through the call chain. In this case, the programmer is only burdened by aliasing when an unexpected case of it actually occurs - the loader will warn him and he can take the appropriate steps. The rest of the time, the programmer doesn't even have to think about it. J. Giles
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/16/90)
In article <6054@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > No, actually it doesn't. Not if the language has a "whole array" syntax. > In such a language, you pass the _specific_ section of the array that > the next procedure needs. Are you implying that Ada, which has this feature (under the somewhat misleading name of ``slicing''---it's a type of slicing, but a very restricted type), suffices for array shifts? How do you take an array x indexed from 0 to 10 and pass it to a procedure indexed from -5 to 5 (presumably with a pointer to the 0th)? I don't see a way to do this. If it's there, my apologies; this is what I get for not spending a lot of time with a language before talking about it. In that case the word ``Ada'' should be deleted from my postings on arrays versus pointers. But I just don't see how it's done. ---Dan
jlg@lanl.gov (Jim Giles) (11/16/90)
From article <7226:Nov1521:52:4690@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein): > In article <6054@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >> No, actually it doesn't. Not if the language has a "whole array" syntax. >> In such a language, you pass the _specific_ section of the array that >> the next procedure needs. > > Are you implying that Ada, which has this feature (under the somewhat > misleading name of ``slicing''---it's a type of slicing, but a very > restricted type), suffices for array shifts? No. I was responding to a specific example (the context of which you have deleted). I try to reflect the context of what _you_ say as accurately as possible. This tends to make you all the more angry. Take the case where you strongly attacked arrays (as opposed to pointers) and in the _same_ article stated that high-level structures should be preprocessed to pointers. This prompted me to make the assumption (correct according to context) that arrays were among the things you wished to preprocess out. You _now_ claim not to have meant that. But, I was _trying_ to respond to the whole gist of your statement _including_ context. Now, the _specific_ example I was responding to here did not refer to the concept of array shifts but merely to the concept of precomputing an array base + offset and using that as the _base_ of an array in a different routine. Period. I was not implying that ADA could answer the problem referred to in the specific example given. I was implying nothing more (not about ADA anyway - which I didn't mention by name, or any other extant language for that matter). In actual fact, Fortran Extended was the model for the "whole array" syntax that I referrred to. > [...] > How do you take an array x indexed from 0 to 10 and pass it to a > procedure indexed from -5 to 5 (presumably with a pointer to the 0th)? > I don't see a way to do this. Again, the Fortran Extended mechanism can do this. > [...] > If it's there, my apologies; this is what I get for not spending a lot > of time with a language before talking about it. In that case the word > ``Ada'' should be deleted from my postings on arrays versus pointers. > But I just don't see how it's done. That's because there is only _one_ person on the net who refuses to look at anything but _extant_ languages. In _your_ thread, I'm willing to conform to that rediculous constraint on the nature of the discussion, but not here. J. Giles
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/16/90)
In article <6074@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > Take the case where you strongly attacked arrays (as opposed > to pointers) and in the _same_ article stated that high-level > structures should be preprocessed to pointers. This prompted me to > make the assumption (correct according to context) that arrays were > among the things you wished to preprocess out. Okay, I know which you're referring to. Apparently my failure to disclaim a position suffices for people to assume that I hold such a position. My apologies for failing to communicate well enough. Once and for all, I think it's stupid to eliminate arrays from a language (unless, of course, there's no higher-level replacement to do the job). When I ``attacked arrays,'' I was only attacking Jim's position that arrays (as in current languages) could be made as efficient as pointers (as in C or machine language) by a sufficiently smart compiler. [ question about Ada shifting an array[0..10] to array[-5..5] ] > Again, the Fortran Extended mechanism can do this. In that case I'm willing to believe that arrays can be made as efficient as pointers in the new Fortran---though not in any widely used language. > That's because there is only _one_ person on the net who refuses to > look at anything but _extant_ languages. Be serious. I'm perfectly willing to look at language features outside of current languages. What I'm not willing to do is abuse current terminology. See, when you say something like ``arrays are _always_ as efficient as pointers,'' I assume that you're talking about arrays as in real languages and pointers as in real languages. If we don't have a common terminology, how can we talk rationally? ---Dan