On Tue, 2007-07-03 at 13:07 +0200, Richard Guenther wrote: > On 7/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote: > > > Daniel Berlin wrote: > > > > I'm curious if it was the pre/fre changes. can you try -fno-tree-pre > > > > and -fno-tree-fre and see if it slows down again? > > > Adding -fno-tree-pre slows aermod back to 33.942s. Nice optimization. ;) > > Thanks. > > (You really should thank richard guenther and steven bosscher, who > > continually beat me up till i finished it :P) > > > > Unfortunately, this "improvement" is a miscompare: > > > Value= 2190.9357900 Target= 2191.1145000 Tolerance=0.10000000000E-02 > FAIL <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > Value= 34310.421880 Target= 34310.421880 Tolerance=0.30000000000E-01 > > Value= 4260.5888700 Target= 4260.9716800 Tolerance=0.50000000000E-01 > FAIL <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > Value= 37093.921880 Target= 37094.375000 Tolerance=0.20000000000E-01 > FAIL <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > Value= 7924.6811500 Target= 7924.8842800 Tolerance=0.30000000000E-01 > FAIL <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > Value= 37093.921880 Target= 37094.375000 Tolerance= 1.0000000000 > > aermod FAILED 4 fails and 2 passes Having been down this path so many times -- any time a benchmark shows a big improvement, my first reaction is that something has been mis- compiled. If not, then I worry that it's just some ugly secondary cache effect from variables moving around on the stack or something similar. Only once I can convince myself that neither of those is the case do I get excited about the improvement.
Perhaps I've become somewhat jaded through the years :-) Jeff > > Richard.
