chased@rbbb.Eng.Sun.COM (David Chase) (12/04/90)
mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes: >> wgh@ubbpc.UUCP (William G. Hutchison) said: >> I see at least two solutions: >> (1) Stop doing numerical work [ :-) ] >> (2) Find or develop a language suitable for this sort of work. >... >My interests right now are leaning more toward Modula-3, because of >its support for classes/objects. Unfortunately, Modula-3 fails in the same way that C does with respect to (pulling out a quote that you didn't quote): >> (2) C programmers mostly work on micros, workstations, or minicomputers, >> so they are not acquainted with pipelining, vectorizing, parallel >> processing, etc., so they do not know what they are missing by using C. These optimizations apply about equally well (poorly) to C and Modula-3. The reason, barring whole-program optimization (interesting in a land of pointers-to-procedures, too) is that Fortran has its weird little parameters-are-not-aliased rule, and C and Modula-3 do not. It's a little easier to mandate not-aliased in a language without recursive data structures (i.e., pointers) like Fortran; in C/Modula-3/others, such a rule seems oddly stunted and special-case. For example, consider "f(LIST p, LIST q), p notalias q". Speaking Fortran, that means that the heads of the lists are not aliased, but who knows about the rest? One might, perhaps, say something along the lines of either p(.cdr)* notalias q(.cdr)* (default is aliased) or p(.cdr)* mayalias q(.cdr)* (default is not-aliased) to specify that the heads and the spines of the lists are not / may be aliased. (and what do I mean by not aliased? For each run-time call, taking the instersection of the two sets p(.cdr)* and q(.cdr)* should yield the empty set, and mangle what I said to turn it into sets of pointers to things.) Anyhow, perhaps this explains why these rules have not been adopted in other languages (yet). All the solutions I come up with in a couple of minutes appear weird, ad hoc, and non-general. Non-aliasing mandates have good effect on remote implementations of things (RPC), too, which is another reason to like them even if you hate heavy-duty optimizations. I'd have to go read more about this stuff to get a handle on what is good, bad, and ugly -- unless the FX-87 people want to get into a discussion about their work (much of which remains unread by me, unfortunately). It helps to keep the constraints of checking and inference in mind, also -- closure properties of regular languages are very useful, for instance. David
strom@arnor.uucp (12/06/90)
In article <3859@exodus.Eng.Sun.COM>, chased@rbbb.Eng.Sun.COM (David Chase) writes: |> mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes: |> >> wgh@ubbpc.UUCP (William G. Hutchison) said: |> >> I see at least two solutions: |> >> (1) Stop doing numerical work [ :-) ] |> >> (2) Find or develop a language suitable for this sort of work. |> >... |> >My interests right now are leaning more toward Modula-3, because of |> >its support for classes/objects. |> |> Unfortunately, Modula-3 fails in the same way that C does with respect |> to (pulling out a quote that you didn't quote): |> |> >> (2) C programmers mostly work on micros, workstations, or minicomputers, |> >> so they are not acquainted with pipelining, vectorizing, parallel |> >> processing, etc., so they do not know what they are missing by using C. |> |> These optimizations apply about equally well (poorly) to C and |> Modula-3. The reason, barring whole-program optimization (interesting |> in a land of pointers-to-procedures, too) is that Fortran has its |> weird little parameters-are-not-aliased rule, and C and Modula-3 do |> not. It's a little easier to mandate not-aliased in a language |> without recursive data structures (i.e., pointers) like Fortran; in |> C/Modula-3/others, such a rule seems oddly stunted and special-case. |> |> [example of passing two lists] I agree with your observation that Modula-3 can yield the same aliasing problems as C, and with your additional point that it is not enough to declare that the top level objects are not aliased. However, I disagree with the implication that having recursive data structures implies having pointers. Hermes has recursive data structures but does not have pointers. Variable sized collections of things can be declared as "table of <type>" or as "ordered table of <type>". Additionally, a type (typically a table or a variant) may contain components of the same type. (For example type "S-expression" may contain a variant case type "pair" whose components are of type "S-expression".) From the programmer's point of view, every variable holds a separate copy of the data and there is no aliasing. However, the compiler and runtime environment are free to optimize the performance of operations which copy or compare "large" objects by letting equal data objects share storage. So there may be aliasing going on "under the covers" which the user doesn't see. However, in these cases the compiler also takes the responsibility to ensure that a true copy is made before any attempt is made to modify a shared copy. This is the language-level analogue of "copy-on-write". The "optimization" is beneficial only if the savings in copying/comparing outweigh the costs of any run-time checks for aliasing. |> Anyhow, perhaps this explains why these rules have not been adopted in |> other languages (yet). All the solutions I come up with in a couple |> of minutes appear weird, ad hoc, and non-general. Non-aliasing |> mandates have good effect on remote implementations of things (RPC), |> too, which is another reason to like them even if you hate heavy-duty |> optimizations. |> I agree that if pointers are explicit, the problem is harder because the programmer is generating the aliasing, but the compiler has to detect it (or provide a way for the programmer to indicate potential aliasing). This is harder then either the case where the programmer is responsible for both generation and detection or the case where the compiler is responsible for both. |> I'd have to go read more about this stuff to get a handle on what is |> good, bad, and ugly -- unless the FX-87 people want to get into a |> discussion about their work (much of which remains unread by me, |> unfortunately). It helps to keep the constraints of checking and |> inference in mind, also -- closure properties of regular languages |> are very useful, for instance. |> |> David -- Rob Strom, strom@ibm.com, (914) 784-7641 IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY 10958