Re: optimizing compiler against iaverage assembly programmer.

WStreett@shell.monmouth.com (Wilbur Streett) writes:


>I doubt that you can optimize LISP as much as you can C or Assembler..


and our esteemed moderator adds:


>Re optimizing Lisp, you might be surprised.


I can't really speak for lisp, since I'm not a lisp user, but when I'm
writing Mercury programs, a knowledge of how the compiler translates
programs enables me to tweak the source code and significant speed
improvements (there was one instance where the compiler was saving
structure members on the stack, where it should have just saved the a
pointer to the structure on the stack - the resulting stack-frame
bloat made something like a 15% difference in execution time (15% is
from memory - it might have been more)).


Even so, it may be true that higher level languages are good because
they allow "safer" and quicker experementation with different data
structures and algorithms, than because they always allow you to
generate the absolute tightest code. Another anecdote may help to
illustrate.


In our compiler (the Mercury compiler), we store the nonlocal
variables of a code fragment as an annotation on that fragment. At
various times we need to recompute these sets of variables, and the
algorithm for doing so is comprised mostly of set union, intersection
and difference operations. (We acutally use sets in quite a number of
places in the compiler.) There was one piece of code (effectively a
big switch with 128 arms) for which the compiler was spending
something like 90% of the time doing set differences recomputing the
nonlocal variables. Because Mercury is high level, I was able to
experiment with several different implementations of the abstract set
module in a short space of time (about a day - and 3 different
implementations), and found one which was more algorithmically stable
than the original one, but also had reasonable constant factors.


(FWIW, we were using sets represented as unsorted lists possibly
containing duplicates, we now use sorted lists with duplicates
removed. We tried balanced trees, bounded-balanced-binary trees, and
some others too).


Conclusion: C is good because it lets you have fine grained control
(most of the time), but this is by no means excludes other languages,
which may also share this property. High level languages are good
because they generally make it cheaper to experement with alternative
data structures and algorithms.


ObCompilerStuff: Is it common or uncommon for it to be fairly simple to
predict what code will be generated from your source?


Thomas
--
Thomas Conway conway@cs.mu.oz.au
[Lisp compilers as a matter of course do things like in-line expansion and
tail recursion elimination that are considered pretty advanced in compilers
for Fortran-like languages. -John]
--

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