[graphite] Use params for the size of loop blocking tiles

Grigori Fursin grigori.fursin@inria.fr
Tue Feb 24 01:34:00 GMT 2009


Thanks for the info, Albert.
Actually, new ICI for GCC 4.4 supports parameter tuning 
on function level (we should release it in 2 weeks - 
we are a bit busy now synchronizing it with the GCC plugin branch)
so we will definitely include it into our iterative compilation
framework to find good blocking value - actually it can also
test the tiling transformation for correctness. I will provide
more info after we manage to do some new experiments ...
Cheers,
Grigori


> -----Original Message-----
> From: Albert Cohen [mailto:Albert.Cohen@inria.fr]
> Sent: Sunday, February 22, 2009 5:15 PM
> To: Sebastian Pop
> Cc: Richard Guenther; GCC Patches; Grigori Fursin; Zbigniew Chamski
> Subject: Re: [graphite] Use params for the size of loop blocking tiles
> 
> Sebastian Pop wrote:
> > On Sat, Feb 21, 2009 at 04:25, Richard Guenther <rguenther@suse.de> wrote:
> >> -  /* TODO: - Calculate the stride size automatically.  */
> >> -  int stride_size = 64;
> >> +  int stride_size = PARAM_VALUE (PARAM_LOOP_BLOCK_TILE_SIZE);
> >>
> >> So - why is it now 51 and it was 64?
> >
> > 51 is more magic than 64.
> > 51 is better to avoid cache padding problems and it avoids
> > to fill up the cache.  Would a simpler patch like the one
> > attached be ok for trunk?
> >
> >>  And why is the TODO removed?
> >
> > It shouldn't have been removed.
> >
> >> I think stride size should be computed based on CPU cache
> >> parameters and the number of streams.
> >
> > Agreed.
> >
> >> Thus, I don't think a user-controllable param makes much sense here.
> >
> > Ok.  So we don't want programmers to play with this.
> 
> Indeed. Instead of a parameter, and before an integrated default cache
> model is provided, it would be interesting to instrument the decision
> through the ICI. I CC Grigori and Zbigniew so they can start playing
> with it in feedback-directed optimization.
> 
> > At least we do want to play with it a little bit, so in the graphite
> > branch it makes sense to have this parameter.  I committed a similar
> > patch to the branch.
> 
> In the short term, such a parameter can indeed help a bit to show that
> Graphite can improve performance!
> 
> In the long term, the tile size will result from a much more complex
> computation that depends on the degree of thread-level data parallelism
> exposed among threads, the cache hierarchy, the vectorizer... and some
> features from the SCoP. There is no good solution to this, but many
> people can start working on it now.
> 
> Albert




More information about the Gcc-patches mailing list