Re: Language Efficiency

[dewar@cs.nyu.edu (Robert Dewar)]

matt says:

"If the compiler can see the whole program at once! And you have to
write two compilers. :-O

I find this difference rather odd:

        * It's dogma that the choice of theoretical processor
          architecture {hardware language}
          makes a big difference in the eventual speed
          of its implementation.  Note, not the "maximum possible given
          any technology imaginable" but the realistic "likely given
          economic constraints."  Proven by empirical example."

Yes indeed (see the whole program at once, and you have to write two
compilers). To argue that language features make it easier or more
difficult to achieve X is one thing, to argue that these differences
are fundamental is another.

one should always be hesitatnt to accept "dogma", and one should be
especially hesitant to accept the allegation that something is "dogma"
as a substitute for effective technical argument. Things that are
"obvious" and which "everyone knows" are not always what they seem
(the G&S song from Pinafore is applicable to a wide range of environments :-)

"Proven by empirical example"

Hm? Sure most compilers do little out of the ordinary, and normal expected
behavior is much as one might expect, but there are plenty of examples
which point in the opposite direction from "dogma".

I will give just one: Jim Boyle has for many years worked on the
transformational compilation of high level LISP programs. He starts with
a high level abstract statement of the numerical algorithm written in
nice high level idiomatic Lisp. Out of the end of a (complex!) set of
compilation processes comes efficient generated fortran code that runs
at comparable speed to hand generated fortran for the same problem.