This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: collaborative tuning of GCC optimization heuristic


On Sat, Mar 5, 2016 at 9:13 AM, Grigori Fursin <grigori@dividiti.com> wrote:
> Dear colleagues,
>
> If it's of interest, we have released a new version of our open-source
> framework to share compiler optimization knowledge across diverse workloads
> and hardware. We would like to thank all the volunteers who ran this
> framework and shared some results for GCC 4.9 .. 6.0 in the public
> repository here: http://cTuning.org/crowdtuning-results-gcc
>
> Here is a brief note how this framework for crowdtuning compiler
> optimization heuristics works (for more details, please see
> https://github.com/ctuning/ck/wiki/Crowdsource_Experiments): you just
> install a small Android app
> (https://play.google.com/store/apps/details?id=openscience.crowdsource.experiments)
> or python-based Collective Knowledge framework
> (http://github.com/ctuning/ck). This program sends system properties to a
> public server. The server compiles a random shared workload using some flag
> combinations that have been found to work well on similar machines, as well
> as some new random ones. The client executes the compiled workload several
> times to account for variability etc, and sends the results back to the
> server.
>
> If a combination of compiler flags is found that improves performance over
> the combinations found so far, it gets reduced (by removing flags that do
> now affect the performance) and uploaded to a public repository.
> Importantly, if a combination significantly degrades performance for a
> particular workload, it gets recorded as well. This potentially points to a
> problem with optimization heuristics for a particular target, which may be
> worth investigating and improving.
>
> At the moment, only global GCC compiler flags are exposed for collaborative
> optimization. Longer term, it can be useful to cover finer-grain
> transformation decisions (vectorization, unrolling, etc) via plugin
> interface. Please, note that this is a prototype framework and much more can
> be done! Please get in touch if you are interested to know more or
> contribute!

Thanks for creating and sharing this interesting framework.

I think a central issue is the "random shared workload" because the
optimal optimizations and optimization pipeline are
application-dependent.  The proposed changes to the heuristics may
benefit for the particular set of workloads that the framework tests
but why are those workloads and particular implementations of the
workloads representative for applications of interest to end users of
GCC?   GCC is turned for an arbitrary set of workloads, but why are
the workloads from cTuning any better?

Thanks, David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]