Richi, I noticed the following graph: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=8.170.0 I noticed that the speed drop back on the trunk happened since r278281. Would you be interested in what loop optimization made the difference?
On Tue, 19 Nov 2019, marxin at gcc dot gnu.org wrote: > I noticed that the speed drop back on the trunk happened since r278281. > Would you be interested in what loop optimization made the difference? Well, the revs probably caused changes in (early) unrolling with the better performance seen with less unrolling. We know that even more unrolling will increase performance though. Not sure what you are asking?
(In reply to rguenther@suse.de from comment #1) > On Tue, 19 Nov 2019, marxin at gcc dot gnu.org wrote: > > > I noticed that the speed drop back on the trunk happened since r278281. > > Would you be interested in what loop optimization made the difference? > > Well, the revs probably caused changes in (early) unrolling with the > better performance seen with less unrolling. We know that even more > unrolling will increase performance though. Ok, so the benchmark likes unrolling :) > > Not sure what you are asking? My question is simple: Can we somehow tweak our defaults so that we can speed up calculix. Note that the speed up is 2x.
On Wed, 20 Nov 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92584 > > --- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> --- > (In reply to rguenther@suse.de from comment #1) > > On Tue, 19 Nov 2019, marxin at gcc dot gnu.org wrote: > > > > > I noticed that the speed drop back on the trunk happened since r278281. > > > Would you be interested in what loop optimization made the difference? > > > > Well, the revs probably caused changes in (early) unrolling with the > > better performance seen with less unrolling. We know that even more > > unrolling will increase performance though. > > Ok, so the benchmark likes unrolling :) > > > > > Not sure what you are asking? > > My question is simple: Can we somehow tweak our defaults so that we can speed > up calculix. Note that the speed up is 2x. I've tried multiple times to no avail ... :/ But yeah. I'll have another look ;) It's gfortran.dg/reassoc_4.f btw. IIRC. See also the --param adjustment therein ... Honza lowered the param at some point, regressing things.
> > I've tried multiple times to no avail ... :/ But yeah. I'll have another > look ;) It's gfortran.dg/reassoc_4.f btw. IIRC. See also the > --param adjustment therein ... Honza lowered the param at some point, > regressing things. Hehe, that's good that we have it isolated as a test-case.
(In reply to Martin Liška from comment #4) > > > > I've tried multiple times to no avail ... :/ But yeah. I'll have another > > look ;) It's gfortran.dg/reassoc_4.f btw. IIRC. See also the > > --param adjustment therein ... Honza lowered the param at some point, > > regressing things. > > Hehe, that's good that we have it isolated as a test-case. Ah, FDO. Well, the train run is completely different from the ref one so FDO performance is notoriously bad for calculix.
*** Bug 92632 has been marked as a duplicate of this bug. ***