Citeren "Kaveh R. GHAZI" <[EMAIL PROTECTED]>:
On Mon, 23 Apr 2007, Mark Mitchell wrote:
I'm certainly not trying to suggest that we run SPEC on every
architecture, and then make -O2 be the set of optimization options that
happens to do best there, however bizarre.
Why not? Is your objection because SPEC doesn't reflect real-world apps
or because the option set might be "bizarre"?
The bizarreness of the resulting flag set should not be a consideration
IMHO. Humans are bad at predicting how complex systems like this behave.
The fact that the "best" flags may be non-intuitive is not surprising. I
find the case of picking compiler options for optimizing code very much
like choosing which part of your code to hand optimize programmatically.
People often guess wrongly where their code spends its time, that's why we
have profilers.
So I feel we should choose our per-target flags using a tool like Acovea
to find what the "best" options are on a per-target basis. Then we could
insert those flags into -O2 or "-Om" in each backend. Whether we use SPEC
or the testcases included in Acovea or maybe GCC itself as the app to tune
for could be argued. And some care would be necessary to ensure that the
resulting flags don't completely hose other large classes of apps. But
IMHO once you decide to do per-target flags, something like this seems
like the natural conclusion.
http://www.coyotegulch.com/products/acovea/
I totally agree with you, Acovea would a good tool for helping with this.
But, in my opinion, it has one big downside: it doesn't allow a
tradeoff between for example compilation time and execution time.
My work tries to tackle this: I'm using an evolutionary approach (like
Acovea) which is multi-objective (unlike Acovea), meaning it optimizes
a Pareto curve for comp. time, execution time and code size. I'm also
trying to speed up things over the way Acovea handles things, which I
won't describe any further for now.
I'm currently only using the SPEC CPU2000 benchmarks (and I believe
Acovea does too), but this shouldn't be a drawback: the methodology is
completely independent of the benchmarks used. I'm also trying to make
sure everything is parameterizable (size of population, number of
generations, crossover/mutation/migration rates, ...).
Unfortunately, I'm having quite a lot of problems with weird
combinations of flags (which generate bugs, as was mentioned in this
thread), which is slowing things down. Instead of trying to fix these
bugs, I'm just ignoring combinations of flags which generate them for
now (although I'l try to report each bug I run into in Bugzilla).
Hopefully, this work will produce nice results by June, and I'll make
sure to report on it on this mailinglist once it's done.
greetings,
Kenneth
--
Statistics are like a bikini. What they reveal is suggestive, but what
they conceal is vital (Aaron Levenstein)
Kenneth Hoste
ELIS - Ghent University
[EMAIL PROTECTED]
http://www.elis.ugent.be/~kehoste
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
