Re: Parallelizing (WAS: Death by pointers.)

Martin.Jourdan@inria.fr (Martin Jourdan)


>> Off the top of my head, I can think of (my two favorites) Modula-3 and
>> Scheme (both available for free), Eiffel, Python, Sather, other Lisps, ML,
>> and Java. If enough people used one of these languages, you'd also get
>> pipeline optimization, but you wouldn't have to suffer for it.
>
> Note that, if you use an implementation of such a language in which the
> compiler generates C code, you automatically benefit from low-level
> optimizations performed by the C "back-end", incl. pipeline optimization
> (scheduling). For instance, the Bigloo and Camloo compilers for Scheme and
> Caml (ML), developed at INRIA, concentrate on "real issues" and let the C
> back-end deal with low-level details.
>
> A side benefit is that the C code produced by such compilers is generally
> free from hard-to-analyze features (e.g. aliases) that hinders low-level
> optimizations, so that, altogether, the executable you obtain from a
> Scheme or ML source is quite competitive with the one you get from
> hand-written C code (and of course much easier to write).


There are several problems with the above statement:


1. As Mathias notes: the absence of aliasing in the code is not something
that most C compilers can exploit. I suspect that by eliminating local
aliasing it simplifies the generation of optimized code by the C compiler,
but many C compilers can probably recognize and deal with such aliasing
given the appropriate optimization switch, so that the net effect on code
quality is minor. It is global aliasing that they cannot deal with and
clean code generation does not help there.


2. Most modern languages promote a style of programming, e.g., small
routines, that is not at all typical of hand coded C. Rightly or wrongly,
hand coded C typically recognizes the overhead of function calls and avoids
such short routines. It is difficult to avoid such small routines in the
generated C code for modern languages. I am under the possibly mistaken
impression that C function calls have more overhead than that of some other
languages, e.g., Forth.


3. Most modern languages use some form of polymorphism that is extremely
difficult to implement without using runtime type determination, e.g.,
boxing variables. The overhead of this can be large, and would not be
typical of hand generated C code, which would avoid polymorphism wherever
possible. As noted recently in comp.lang.functional, in principle much of
the control flow can be statically determined, by the writer of the code,
but not by the compiler.


4. As noted recently in comp.lang.functional, most modern languages
emphasize lists (and other general forms) over special cases such as arrays
and vectors, although those special cases are precisely the forms that are
most easilly optimized, and are commonly associated with difficult
problems.


5. As also noted in comp.lang.functional, there is a tendency towards
featuritis in modern programming languages that can distract effort from
the details of optimization. There is a tendency to implement something
new correctly, rather than something old optimally.


6. Hand coded C often has a large number of macros, ifdef's, ..., that
compensate for variations in systems and C compilers. I suspect that most
compilers to C do not attempt to fine tune code to the same extent.


C has a reputation as a usefull intermediate language, not because it is
highly efficient, but because relatively efficient compilers are available
for free. Ada or Fortran, because of the no alias semantics of the
arguments of their procedures, would make better target languages, at least
for functional languages, than C. Unfortunately, the only commonly
available free compilers for those languages have the gcc back end, which,
I believe, does not presently implement the specialized optimizations that
could take advantage of Ada's or Fortran's semantics. Although in
principle GNAT and g77 can be made faster than gcc, currently they have no
such advantage. The next best alternative is probably C++ which, with its
stronger type information, and myriads of features for optimization
purposes, e.g., virtual functions, inline, etc., should yield more
efficient code than C. Forth might also be usefull if it does indeed have
a small function call overhead.




  William B. Clodius Phone (505) 665-9370
  Los Alamos Natl. Lab. NIS-1 FAX (505) 665-7395
  PO Box 1663, MS-D466 Group Office (505) 667-2701
  Los Alamos, NM 87545 email wclodius@lanl.gov


  NIS-1: Nonproliferation and International Security Div./
                Space and Atmospheric Physics Group


--

Return to the comp.compilers page.
Search the comp.compilers archives again.