|Re: 'Superoptimizers' email@example.com (1995-11-09)|
|Re: 'Superoptimizers' firstname.lastname@example.org (1995-11-14)|
|Re: 'Superoptimizers' email@example.com (1995-11-15)|
|Re: 'Superoptimizers' firstname.lastname@example.org (1995-11-17)|
|Re: 'Superoptimizers' email@example.com (1995-11-20)|
|Re: 'Superoptimizers' firstname.lastname@example.org (1995-11-21)|
|Re: 'Superoptimizers' email@example.com (1995-11-22)|
|Re: 'Superoptimizers' firstname.lastname@example.org (1995-11-23)|
|Re: 'Superoptimizers' email@example.com (1995-11-27)|
|Re: 'Superoptimizers' firstname.lastname@example.org (1995-11-28)|
|From:||email@example.com (Henry Baker)|
|References:||<firstname.lastname@example.org> 95-11-080 95-11-153|
|Date:||Tue, 21 Nov 1995 15:40:46 GMT|
email@example.com (Jason Taylor) rote:
>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.)
The program you are looking for is an essentially trivial shell script,
which simply runs the benchmark repeatedly with different switch settings,
or even better, commands a group of machines to each run the benchmark with
different settings. Since factories need programs to test machines anyway
during 'burn-in', a factory is an ideal setting to run such a program.
If the switch settings have any kind of tunable parameters, then you might
have an enormous space to search, in which case the usual kinds of optimization
techniques -- hill-climbing, simulated annealing, etc. -- would be useful.
I seem to recall that someone has actually obtained a US patent on a similar
sort of scheme.
Return to the
Search the comp.compilers archives again.