Re: 'Superoptimizers'

Andy Glew (glew@ichips.intel.com) wrote:
: (b) Used "compilation time" as a command line parameter. I.e. I wish
: I could say "take as long as 30 minutes to optimize, but not much
: longer" - and have the compiler quickly produce a quick and dirty
: code, and then refine it a few times by applying more and more
: optimizations.


: Rather than me, myself, figuring out by hand what compiler
: switches to turn on and off in order to properly balance compilation
: time and execution speed.


theoblit@wam.umd.edu (Jason Taylor) writes:
> I couldn't agree more. Compilers should have a special mode where it
> systematically determines what switches are best for a program.


> And
> compile time should not be an issue at all if you use the, say, "-O4"
> switch in stead of just "-O". Spec92 is the cause of a zillion
> switches that no real scientist has time to care about. (I think that
> only the equiv. of "-O" should have been allowed in spec95 for this
> very reason, so that I don't pull out hairs wondering what I should do
> to shave some time off a 3 hour run.)


I'm trying to think of a polite way to say this, but I think that you
guys are both stuck in a slightly different (hardware marketing and
supercomputing, perhaps?) universe. (Seriously, I've recently begun
to suspect that both of these "fields" have had a disproportionate
and weird influence on both programming languages and compilers,
because of their vocal emphasis on speed, speed, speed.)


A compilation option that multiplies the time spent on optimization by,
say, a factor of 100, is essentially untestable, because it would take
too long to run the tests. For how many customers is such an option
useful? "Your compilation will take a really long time, and the result
will run 5% faster, but we haven't been able to test the compiler in
this mode as well as we've tested any other part of it. In fact, we've
tested it 100 times less than any other mode." It would make much more
sense to implement profiling feedback, I think -- the compilation would
take less time, and it could be tested (it could be interestingly
tested, actually, by generating random profiling weights and feeding
them to the compiler, over and over again), and I suspect you'd get more
bang out of it.


In addition, thinking that "-O flag only" as a SPEC rule will save you
seriously underestimates the "cleverness" ("sneakiness" is the
derogatory term) of compiler writers and the pressure to deliver good
numbers. The obvious (?) solution to your "-O" mandate is to pattern
match for certain (SPEC) inputs and internally crank up all the
optimizations whenever a special input is recognized, despite the "-O"
instructions on the compile line. This has the additional advantage of
not going wrong (see Chris Glaeser's posting on eqntott) when fed a
close-but-not-quite input -- in that case, the compilation will just
take longer than usual for a program of that size. Certainly, all the
branch-prediction heuristics in a compiler can be tuned to do the best
possible job on SPEC benchmarks.


The addition of a "generate good code, then refine it" option also
makes a few assumptions that I think are dicey. First of all, there's
the assumption that the compiler can do a good job of estimating the
hot spots and the runtime of the code it is compiling (yes, people are
working on this). Second, there's the assumption that optimized code
is "refinable" -- my understanding of most optimizers is that the only
way to do this is to save the input, and reoptimize it again using a
different strategy, to see if the final result is better. Decisions
made early in the game ("do I interchange these loops, or not?") are
too difficult to modify in the generated code.


Sorry to be so skeptical, but I've become very tired of
benchmark-driven compiler-writing. I realize that it IS where the
money is, but it adds little of real value to most people's use of
computers. If it helps, a former employer (Sun) promoted the use of a
"-fast" flag that was supposed to provide generally provide code that
was close enough to the fastest available form those compilers that you
ought not feel a need to spend time fiddling with flags. Theory and
practice diverge, of course (when using those compilers, I typically
say "-fast -xO4" to go "even faster", and now they have a "-xO5" in
their latest and greatest) but by promoting the use of a single flag
for "go real fast" they can test it heavily and (to the extent that
users actually pay attention and use the flag) reduce the incidence of
compiler bugs in the field.


speaking for myself,


David Chase
--

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