This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Improve prefetch heuristics
- From: Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>
- To: "Fang, Changpeng" <Changpeng dot Fang at amd dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "rguenther at suse dot de" <rguenther at suse dot de>, "sebpop at gmail dot com" <sebpop at gmail dot com>
- Date: Mon, 3 May 2010 23:29:38 +0200
- Subject: Re: [patch] Improve prefetch heuristics
- References: <20100430010543.GA30055@kam.mff.cuni.cz> <1C13CD442679CE45A2E80AE9251D7EF921803A2A@SAUSEXMBP01.amd.com>
Hi,
> >> Patch5: 0005-Also-apply-the-insn-to-prefetch-ratio-heuristic-to-l.patch
> >> This patch applies the instruction to prefetch ratio heuristic also to loops with
> >> known loop trip count. It improves 416.gamess by 3~4% and 445.gobmk by 3%.
>
> >I think it would be better to find out why the prefetching for the loops in
> >these examples is currently performed (or why it causes the degradation). If
> >the instruction count is too small, AHEAD should be big enough to prevent the
> >prefetching. Currently we just test whether est_niter <= ahead, which is
> >rather aggressive. We should only emit the prefetches if # of iterations is
> >significantly bigger than ahead, so that could be the place that needs to be
> >fixed. Which ...
>
>
> The reason is that there are too many prefetches. Here is an example:
> Ahead 5, unroll factor 1, trip count 216, insn count 49, mem ref count 15, prefetch count 15
>
> Here we inserted one prefetch for each memory reference. I just feel uncomfortable that
> we inserted so many prefetches in this loop. I think prefetches will compete with loads/stores
> for memory ports and bandwidth, and thus cause performance degradation in this case.
SIMULTANEOUS_PREFETCHES parameter is used to avoid that. Perhaps it is set too high for your
architecture?
Zdenek