[google] Increase hotness count fraction

[google] Increase hotness count fraction

[Mark Heffernan]

This patch bumps up the parameter 'hot-bb-count-fraction' from 10000
to 40000.  This results in about a 0.5% geomean performance
improvement across internal benchmarks for x86-64 LIPO.  The parameter
change effectively increases the number of functions/callsites which
are considered hot.  The performance improvement is likely due to
increased inlining (more callsites are considered hot and available
for inlining).

Bootstrapped and reg-tested on x86-64.  OK for google/gcc-4_6?

Mark


2011-08-24  Mark Heffernan  <meheff@google.com>

	* params.def (hot-bb-count-fraction): Change default value.



Index: params.def
===================================================================
--- params.def  (revision 177964)
+++ params.def  (working copy)
@@ -382,7 +382,7 @@ DEFPARAM(PARAM_SMS_LOOP_AVERAGE_COUNT_TH
 DEFPARAM(HOT_BB_COUNT_FRACTION,
         "hot-bb-count-fraction",
         "Select fraction of the maximal count of repetitions of basic
block in program given basic block needs to have to be considered
hot",
-        10000, 0, 0)
+        40000, 0, 0)
 DEFPARAM(HOT_BB_FREQUENCY_FRACTION,
         "hot-bb-frequency-fraction",
         "Select fraction of the maximal frequency of executions of
basic block in function given basic block needs to have to be
considered hot",

Re: [google] Increase hotness count fraction

[Xinliang David Li]

Good for google branches.

Need to measure the performance and size impact on SPEC2k/06 with this
patch and the previous hotcaller patch for trunk.

thanks,

David

On Wed, Aug 24, 2011 at 2:43 PM, Mark Heffernan <meheff@google.com> wrote:
> This patch bumps up the parameter 'hot-bb-count-fraction' from 10000
> to 40000.  This results in about a 0.5% geomean performance
> improvement across internal benchmarks for x86-64 LIPO.  The parameter
> change effectively increases the number of functions/callsites which
> are considered hot.  The performance improvement is likely due to
> increased inlining (more callsites are considered hot and available
> for inlining).
>
> Bootstrapped and reg-tested on x86-64.  OK for google/gcc-4_6?
>
> Mark
>
>
> 2011-08-24  Mark Heffernan  <meheff@google.com>
>
>        * params.def (hot-bb-count-fraction): Change default value.
>
>
>
> Index: params.def
> ===================================================================
> --- params.def  (revision 177964)
> +++ params.def  (working copy)
> @@ -382,7 +382,7 @@ DEFPARAM(PARAM_SMS_LOOP_AVERAGE_COUNT_TH
>  DEFPARAM(HOT_BB_COUNT_FRACTION,
>         "hot-bb-count-fraction",
>         "Select fraction of the maximal count of repetitions of basic
> block in program given basic block needs to have to be considered
> hot",
> -        10000, 0, 0)
> +        40000, 0, 0)
>  DEFPARAM(HOT_BB_FREQUENCY_FRACTION,
>         "hot-bb-frequency-fraction",
>         "Select fraction of the maximal frequency of executions of
> basic block in function given basic block needs to have to be
> considered hot",
>

Re: [google] Increase hotness count fraction

[Ramana Radhakrishnan]

On 24 August 2011 22:43, Mark Heffernan <meheff@google.com> wrote:
> This patch bumps up the parameter 'hot-bb-count-fraction' from 10000
> to 40000.  This results in about a 0.5% geomean performance
> improvement across internal benchmarks for x86-64 LIPO.  The parameter
> change effectively increases the number of functions/callsites which
> are considered hot.  The performance improvement is likely due to
> increased inlining (more callsites are considered hot and available
> for inlining).
>
> Bootstrapped and reg-tested on x86-64.  OK for google/gcc-4_6?

I know this is intended for the google branches but shouldn't such a
change be in the x86_64 backend rather than such a general change to
params.def .

My 2 cents.

cheers
Ramana

Re: [google] Increase hotness count fraction

[Mark Heffernan]

On Thu, Aug 25, 2011 at 6:49 AM, Ramana Radhakrishnan
<ramana.radhakrishnan@linaro.org> wrote:
> I know this is intended for the google branches but shouldn't such a
> change be in the x86_64 backend rather than such a general change to
> params.def .

I wouldn't consider this a backend-specific change.  The parameter
generally affects performance-space tradeoff with FDO.  A higher value
means more code will be optimized for performance rather than size
(perhaps most significantly in the inliner).  The value is too
conservative (too much optimizing for size) and leaves performance on
the table, at least for our benchmarks.  Though I've only tested
x86-64, I'd imagine other arches would benefit especially those with
relatively large I-caches where a larger code footprint can be
tolerated.  Of course YMMV...

Mark

>
> My 2 cents.
>
> cheers
> Ramana
>