Re: Question: Specific vs. Generic Compilers

A few weeks ago I posted a question concerning Specific vs. Generic
Compilers. Since many of the responders were interested in a summary
of the answers, I structured the comments according to the topics of
my post. To allow an easy identification of the originatior, I attatch
the number to each paragraph.


Thanks to the following people responding to my request:


(1) preston@dawn.cs.rice.edu (Preston Briggs)
(2) henry@zoo.toronto.edu (Henty Spencer)
(3) pardo@cs.washington.edu
(4) anton@mips.complang.tuwien.ac.at (Anton Ertl)
(5) ressler@cs.cornell.edu


CR


> * [Of a machine-specific vs. machine-generic compilers, which one is
> better in the aspects of code size, execution time and effective
> use of resources and possibilities like delay slots and
> processor caches?


(1) It's terribly difficult to compare compilers fairly. Some are designed
for fast compilation, easy portability, small compile-time requirements,
fast object code, debuggable object code, etc. Different tradeoffs exist,
and each compiler writer must decide what performance points to emphasize.


Generally though, I'd expect the machine-specific compiler to generate
faster code, though gcc is remarkably good at embarrassing various
manufacturers.


You'll probably have to do actual comparisons on the hardware rather than
rely on generic answers.


(2) This is like asking "how high is up?". Bear in mind that Sun's compiler
is almost certainly generic too, since until very recently Sun supported
two or three different architectures. The only way to answer this question
is to look at specific compilers and specific notions of "better". The
answer is much more a function of the effort invested in the compiler and
the competence of the people involved than of whether it was done by a
computer manufacturer or someone else. (For example, on the 68k-based
Sun 3 series, the GNU compiler is typically better than Sun's.) The only
advantages the manufacturer has are earlier information about new systems
and perhaps better knowledge about the effects of possible optimizations.
This can often be counterbalanced by the bureaucratic ineptitude of such
large organizations.


(3) In theory, a machine-specific compiler can be better. In practice, a
retargetable compiler can be made to work quickly and thus more time
can be spent on ``minor twiddles'' to improve the code generation.
Thus, in practice, they tend to be similar. No doubt the vendors of
e.g., the Sun C compiler will point out that it generates better code,
but I believe the typical performance win/code shrinkage is on the
order of 5%; for most applications this can be considered marginal.


(4) Many optimizations and back-end tasks are target independent or can be
made easily retargetable via machine descriptions (e.g. code selection and
instruction scheduling).


However, every processor has its idiosyncracies (e.g. the explicitely
advanced pipelines of the i860). It usually does not pay off to exploit
them in a retargetable compiler, but it has been done: The Marion code
generation system can handle the pipeline of the i860. To achieve this
they had to extend their machine description language and the code
generator generator.


The quality of the generated code and the speed of the compiler generally
depends on how well-crafted the compiler is. What a single-target compiler
can win in target-specific optimizations, can usually be made up with
better target-independent optimizations in retargetable compilers.


(5) It's safe to say that it's easier to write a very good compiler
directed at one architecture than to write an equally good compiler that
can handle many. This (and the price) is what makes gcc so popular --- it
manages to do the latter.


> * Is it possible to answer this question globally or is it necessary to
> check each compiler on each machine?


(3) Probably globally, but there will always be exceptions.


(4) It's necessary to check each compiler. It would be good to check
retargetable compilers on the machine you are interested in, as the
processor may fit the compiler badly and the quality of the machine
description may vary.


(5) As John points out, there are very few generalizations possible, even
within the same version of the same compiler! They are about as
comparable as people.


> * Do statistics exist and where can I get them from?


(1) I don't think so, though sometimes you see limited comparisons published.


(3) Many published compiler papers for retargetable compilers compare the
code performance to the code from GCC. It's possible that you can find or
generate e.g., SPEC numbers using the vendor's compiler and e.g., GCC.
Note, though, that some vendors use retargetable compilers (e.g.,
Greenhills).


(4) You might check the SPEC results. Don't ask me where to get them.


(5) Statistics on commercial compilers are closely guarded by the
propietors, and research literature tends to focus on only certain aspects
in any given work. If there is a broad source of information on compiler
performance, I would like to see it too!


> * How far are (hard) real-time considerations taken into account? (I
> think of aspects like precalculation of execution time or at least
> haveing always the same execution time for the same code.)


(1) In general, determining execution time (even termination) is
undecidable, so few compilers attempt such predictions. Even estimating
cycle-counts for particular instructions is difficult, due to pipeline
interlocks, cache misses, et cetera. However, some compilers will produce
expected cycle counts for basic blocks as part of the assembly listing.


(2) This ranges from difficult to impossible on most modern computer
systems. RISC machines did restore considerable predictability to the
instruction stream itself, but superscalar implementations and such are
about to take it away again. And caching of various kinds has made memory
performance nearly impossible to predict. The best a compiler could do
would be to give a (best case, worst case) pair, and the spread would be
pretty wide.


(3) Very little. The empahsis is on improving the expected case rather
than limiting the worst case.


(4) There are compilers that compute the worst case execution time.
Obviously they have restrictions on language use.


(5) For modern general computing architectures, two different executions
of the sam e code will very likely provide different timings, as they are
dependent on the s tates of the bus, caches, VM, interrupting devices,
etc. Hence instruction timing guides compiler design in only general
ways.


In embedded controllers where hard time constraints are relevant, the only
approach I have seen is to build the system with whatever compiler and
then use analysis tools to ensure that critical paths in code are short
enough to meet timing constraints. When the compiler can't hack it, code
is written in assembly by hand. I am not aware of compilers tha t account
for real time constraints at all. However, this is not an area where I am
experienced.


> [It varies by compiler and even by version. For example, in GCC which is
> quite machine independent the 1.xx versions do not handle delay slots very
> well, while the forthcoming 2.x versions handle them pretty well. -John]


(4) gcc-1.xx does not do any instruction scheduling, the prerelease of
gcc-2.xx that I have seen is not as good as might be expected (wrt
instruction scheduling), but that will probably change.
--

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