On 01/02/2018 04:57 AM, Martin Liška wrote: > On 12/24/2017 07:58 PM, Jeff Law wrote: >> On 12/24/2017 05:03 AM, Segher Boessenkool wrote: >>> On Sun, Dec 24, 2017 at 09:12:56AM +0000, Richard Sandiford wrote: >>>> Segher Boessenkool <seg...@kernel.crashing.org> writes: >>>>> On Fri, Dec 22, 2017 at 04:53:47PM -0600, David Esparza wrote: >>>>>> With a value of 85 GCC has a CPU performance degradation of 11%, >>>>>> reverting PRED_LOOP_EXIT to 92 this degradation disappear. >>>>>> Those values where measured by running c-ray ray-tracer that is a >>>>>> floating point benchmark that runs out of L1 cache. >>>>> >>>>> Why is this single benchmark more important than everything else? >>>>> >>>>> https://patchwork.ozlabs.org/patch/637073/ >>>> >>>> "Everything" else? :-) It sounds from Andrew's reply like it wasn't >>>> a win on other benchmarks too. >>> >>> Yeah... But at least Martin tested spec2006, instead of one single >>> tiny non-representative program. >>> >>>> Neither covering message has really explained why the previous value was >>>> too low/high, but maybe that's just the way it goes with these tuning >>>> parameters... >>> >>> It would be nice if they explained how they tested things. >> Agreed. I can't see any way for this patch to go forward without some >> explanation of why it helps this particular c-ray implementation and >> some data showing it's not hurtful on a wider suite of benchmarks. >> >> >> Jeff >> > > Hello. > > Sorry for late answer. I've been currently working on returning of predictors > according to SPEC2006 and SPE2017. I've got prepared patches and currently > testing > it's impact on speed of SPEC benchmarks. > > From what I've measured, suggested adjustment for this particular predictor > would be > increase to 89. > > Note that this predictor has quite high coverage on SPEC: 5.3% (of all > branching). Understood. I think using SPEC to guide here makes much more sense.
Jeff
