Re: Parallelizing (WAS: Death by pointers.)

>>> 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.


>Martin.Jourdan@inria.fr (Martin Jourdan)
>> 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.


Except that, if you use a conservative garbage collector, you must at
least be wary of what the optimizer might do to you. In addition, if
the language of interest has exception-handling in it, the "portable"
way to do this is to use setjmp and longjmp. This is generally not
helpful to the C optimizer.


>> 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).


Only if the lack of aliasing is evident to the C compiler. The C
generator could make use of restricted pointers, if they were in the
language.


In article 95-11-015,
William B. Clodius <wclodius@lanl.gov> wrote:
>There are several problems with the above statement:


>2. Most modern languages promote a style of programming, e.g., small
>routines, that is not at all typical of hand coded C. ...
>I am under the possibly mistaken
>impression that C function calls have more overhead than that of some other
>languages, e.g., Forth.


I think your impression is mistaken.


>3. Most modern languages use some form of polymorphism that is extremely
>difficult to implement without using runtime type determination, e.g.,
>boxing variables.


Be careful of boxing for uniform representation, versus boxing for runtime
typing. ML conventionally boxes for uniform representation, but does not
need runtime type information (or so I infer from the assertion that ML
garbage collection does not need it). There are also alternatives in the
list at the top of the message where not all data needs to be tagged with
a runtime type. Modula-3 is one such example. In addition, the tag can
be bundled with the memory allocator overhead (basically, memory
allocation looks like memory allocation, so you at least get a feel
for the expense).


>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.


Once again, Modula-3 serves as an example of a language where this is
not the case. The array support is not quite up there with the most
amazing Fortran-90 has to offer, but it's better than what you get
from C and C++.


>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.


Again, consider Modula-3, Scheme, and ML. In all three cases the
reference manuals are small and well-written, and all three languages
(to my knowledge) were explicitly designed with a goal of getting the
most possible from the least number of essential features.


>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 compilers are getting better, and hand-tuning is not that hard.
Most of the hand-tuning done five years ago is obsolete on the latest
machines, anyway. (Remember when a SparcStation 2 was hot stuff?)


> ... 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.


I'm not sure I could adequately express my disgust at the idea of
using C++ as an intermediate language without resorting to
unpardonable language and imagery. It tends to yield less efficient
code than C, too, except that the exception-handling code is sometimes
more efficient. A major problem is figuring out just what code to
generate, and what it will mean -- host compilers tend to vary on
which version of the draft standard they were intended to accept, and
the degree to which they actually get it right.


>Forth might also be usefull if it does indeed have
>a small function call overhead.


There's more to life than function-call overhead. If the resulting
code doesn't use registers for most of its "variables" and work, it's
probably not interesting.


speaking for myself,


David Chase
--

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