Re: Smallest Optimizer

SAND_DUANE@tandem.com writes:


>Optimizers could be fast either by doing as little as possible
>(maybe giving a small optimizer) or by having a clever and complex
>implementation of its methods (maybe giving a larger optimizer).


I always liked optimizers that were thorough and asymptotically fast
(or at least not asymptotically slow!). In recent articles, people
have claimed that certain optimizations don't pay off enough to be
worth implementing, or perhaps implementing well. Maybe so. Vicky
Markstein, when she was part of the compiler crew at IBM Yorktown,
suggested including an optimization only if the net effect was to
speed up the compiler (when compiled with itself).


For example, imagine we had a C compiler written in C. We compile it
in itself, then time it over some chunk of code (say the C components
of SPEC). Then we add our optimization to the compiler source,
recompile giving a more effective (but slower) optimizer, and
recompile again, giving a more effective and (perhaps) faster
optimizer. Now time the resulting compiler over the same test suite.
If it's just as fast, or faster, then we're getting the optimization
for free, more or less.


This isn't ideal, but it's an interesting metric. The problems I see
go like this:


if you're going to optimize at all, you probably take
significant speed hit just for being able to optimize.


optimizations interact, so testing particular optimizations in
isolation won't give best results.


you end up with an optimizer that is effective on compilers,
but perhaps not your application code (e.g.,, optimizers
don't benefit from vectorization, but many scientific
applications will).


Preston Briggs
--

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