Re: [AArch64][Spec2017]Question about mlow-precision-div optimization.

Re: [AArch64][Spec2017]Question about mlow-precision-div optimization.

[Wilco Dijkstra]

Hi,

> I found that the mlow-precision-div option have a fix number of newton iterations, 
> which is 2 for float type and 3 for double type.
>
> I noticed that if I alter the numbers of newton iterations as following, it could leads
> to faster performance in SPEC2017 fpspeed test  on AArch64, with less but
> acceptable precision.
 
Which CPU did you try this on? Those results look suspicious - lbm hardly does any
divisions for example, so either the computation has gone wrong due to the lower
accuracy or your CPU has a really slow divide...

On modern cores it is faster to do a division than to use the division approximation
instructions. Eg. on Neoverse N1 a float division takes at most 10 cycles while the
reduced approximation takes 13 cycles (and needs 3 extra instructions which take up
decode and issue slots).

Cheers,
Wilco

Re: [AArch64][Spec2017]Question about mlow-precision-div optimization.

[=?gb18030?B?QnUgTGU=?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain;	charset="gb18030", Size: 2805 bytes --]

Hi,

Thanks for the reply.

These data I presented is acquired from a cortex-a57 CPU.    

Since spec2017 does result check and will give a test report which indicates miscomputed cases, I suppose the performance improvement is valid.

The point that you mentioned in some modern CPU, fdiv is faster than the reciprocal approximation is a new aspect I haven¡¯t come cross.

Nevertheless, in a CPU that reciprocal approximation make a profit, like my case, may I ask why the number of newton iteration is fixed to 2 and 3?

And do you think it worth us providing a parameter to alter the iteration so that the accuracy can be a trade-off of speed.

By the way, the original data is as following. 


Test case           |       Improvement
603.bwaves_s           7.92%
607.cactuBSSN_s      Output miscompare
619.lbm_s                32.34%
621.wrf_s                 Output miscompare
627.cam4_s              Output miscompare
628.pop2_s               Output miscompare
638.imagick_s           -0.97%
644.nab_s                 9.09%
649.fotonik3d_s         Output miscompare
654.roms_s               -3.45%


------------------ Original ------------------
From:&nbsp;"Wilco Dijkstra"<Wilco.Dijkstra@arm.com&gt;;
Date:&nbsp;Mon, Feb 24, 2020 08:59 PM
To:&nbsp;"gcc-help@gcc.gnu.org"<gcc-help@gcc.gnu.org&gt;;"Bu Le"<cityubule@qq.com&gt;;

Subject:&nbsp;Re: [AArch64][Spec2017]Question about mlow-precision-div optimization.



Hi,

&gt; I found that the mlow-precision-div option have a fix number of newton iterations, 
&gt; which is 2 for float type and 3 for double type.
&gt;
&gt; I noticed that if I alter the numbers of newton iterations as following, it could leads
&gt; to faster performance in SPEC2017 fpspeed test &amp;nbsp;on AArch64, with less but
&gt; acceptable precision.
&nbsp;
Which CPU did you try this on? Those results look suspicious - lbm hardly does any
divisions for example, so either the computation has gone wrong due to the lower
accuracy or your CPU has a really slow divide...

On modern cores it is faster to do a division than to use the division approximation
instructions. Eg. on Neoverse N1 a float division takes at most 10 cycles while the
reduced approximation takes 13 cycles (and needs 3 extra instructions which take up
decode and issue slots).

Cheers,
Wilco

Re: [AArch64][Spec2017]Question about mlow-precision-div optimization.

[Wilco Dijkstra]

Hi,

> These data I presented is acquired from a cortex-a57 CPU.

>The point that you mentioned in some modern CPU, fdiv is faster than the reciprocal 
> approximation is a new aspect I haven’t come cross.

Well on Cortex-A57 division is also faster, eg. lbm_r is ~3% slower using reciprocal divide.

> And do you think it worth us providing a parameter to alter the iteration so that the
> accuracy can be a trade-off of speed.

What do you mean? We already have -mlow-precision-div (and -sqrt/-recip-sqrt).

> Since spec2017 does result check and will give a test report which indicates miscomputed cases, 
> I suppose the performance improvement is valid.

Try perf stat to show instruction counts, and if they are not increasing due to the extra reciprocal
operations, the benchmark is running incorrectly even if it passes basic checks.

Cheers,
Wilco

Re: [AArch64][Spec2017]Question about mlow-precision-div optimization.

[Richard Sandiford]

Wilco Dijkstra <Wilco.Dijkstra@arm.com> writes:
>> And do you think it worth us providing a parameter to alter the iteration so that the
>> accuracy can be a trade-off of speed.
>
> What do you mean? We already have -mlow-precision-div (and -sqrt/-recip-sqrt).

The suggestion was to have a parameter to control the number of steps,
rather than always use the values that are currently hard-coded into
aarch64.c.

That sounds OK in principle.  It would fix one of the downsides of the
current code, in which users can force reciprocal approximation to be
used at low precision, but can't force it to be used at the precisions
normally chosen by -mtune.

It's probably not worth promoting to a full -m option that in theory
would be supported for evermore.  But now that targets can define their
own --params, it might make sense to use --params here.

Thanks,
Richard

Re: [AArch64][Spec2017]Question about mlow-precision-div optimization.

[Wilco Dijkstra]

Hi Richard,

> The suggestion was to have a parameter to control the number of steps,
> rather than always use the values that are currently hard-coded into
> aarch64.c.
>
> That sounds OK in principle.  It would fix one of the downsides of the
> current code, in which users can force reciprocal approximation to be
> used at low precision, but can't force it to be used at the precisions
> normally chosen by -mtune.

Well there are only 2 possible settings, so I don't see how a param would be
reasonable... However given there is no performance improvement for the low
precision versions, what is the point of adding new options for the even slower,
higher precision variant?!?

Cheers,
Wilco

Re: 回复： [AArch64][Spec2017]Question about mlow-precision-div optimization.

[Richard Sandiford]

Hi,

Sorry for the slow reply, the last few days have been a bit hectic.

"Bu Le" <cityubule@qq.com> writes:
>>It's probably not worth promoting to a full -m option that in theory
>>would be supported for evermore.  But now that targets can define their
>>own --params, it might make sense to use --params here.
> Thanks for the reply.
> I tried the patch in the attachment, it works as we expected. Do you mean like
> this?
>
> A simple example :
> Double foo(double a, double b) { return a /b;}
>
> -O2 -ffast-math -mlow-precision-div foo.c will give:
>   Foo:
>  frecpe d2, d1
>  frecps d3, d2, d1
>  fmul d2, d2, d3
>  frecps d3, d2, d1
>  fmul d2, d2, d0
>  fmul d0, d2, d3
>  ret
> -O2 -ffast-math -mlow-precision-div --param=aarch64-double-recp-precision=2
> foo.c result in one less step
>  Foo:
>  frecpe d2, d1
>  frecps d3, d2, d1
>  fmul d2, d2, d0
>  fmul d0, d2, d3
>  ret

Yeah, this is the kind of thing I had in mind.  However, rather than
calculating the value here:

> diff -Nurp a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> --- a/gcc/config/aarch64/aarch64.c	2020-02-11 11:51:04.000000000 +0800
> +++ b/gcc/config/aarch64/aarch64.c	2020-03-04 23:01:16.600403598 +0800
> @@ -12851,8 +12851,8 @@ aarch64_emit_approx_div (rtx quo, rtx nu
>    rtx xrcp = gen_reg_rtx (mode);
>    emit_insn (gen_aarch64_frecpe (mode, xrcp, den));
>  
> -  /* Iterate over the series twice for SF and thrice for DF.  */
> -  int iterations = (GET_MODE_INNER (mode) == DFmode) ? 3 : 2;
> +  /* Iterate over the series twice for SF and thrice for DF by default.  */
> +  int iterations = (GET_MODE_INNER (mode) == DFmode) ? aarch64_double_recp_precision : aarch64_float_recp_precision;

and then decrementing it here:

>    /* Optionally iterate over the series once less for faster performance,
>       while sacrificing the accuracy.  */
>    if ((recp && flag_mrecip_low_precision_sqrt)
>        || (!recp && flag_mlow_precision_sqrt))
>      iterations--;

it might better to keep the original 3 : 2 calculation above and
then override it with the param values:

    if ((recp && flag_mrecip_low_precision_sqrt)
        || (!recp && flag_mlow_precision_sqrt))
      iterations = ...param values...;

That way, the --param value reflects the actual number of steps.

Minor formatting point, but GCC code uses a maximum line length
of 80 characters, so the conventional way of formatting the
calculation above would be:

  int iterations = (GET_MODE_INNER (mode) == DFmode
		    ? aarch64_double_recp_precision
		    : aarch64_float_recp_precision);

> diff -Nurp a/gcc/config/aarch64/aarch64.opt b/gcc/config/aarch64/aarch64.opt
> --- a/gcc/config/aarch64/aarch64.opt	2020-02-04 09:23:30.000000000 +0800
> +++ b/gcc/config/aarch64/aarch64.opt	2020-03-04 23:01:18.173777158 +0800
> @@ -262,3 +262,12 @@ Generate local calls to out-of-line atom
>  -param=aarch64-sve-compare-costs=
>  Target Joined UInteger Var(aarch64_sve_compare_costs) Init(1) IntegerRange(0, 1) Param
>  When vectorizing for SVE, consider using unpacked vectors for smaller elements and use the cost model to pick the cheapest approach.  Also use the cost model to choose between SVE and Advanced SIMD vectorization.
> +
> +-param=aarch64-float-recp-precision=
> +Target Joined UInteger Var(aarch64_float_recp_precision) Init(2) IntegerRange(1, 5) Param
> +The number of Newton-iteration for calculating the reciprocal for float type. The precision of division is propotional to this param when division approximation is enabled. The default value is 2.
> +
> +-param=aarch64-double-recp-precision=
> +Target Joined UInteger Var(aarch64_double_recp_precision) Init(3) IntegerRange(1, 5) Param
> +The number of Newton-iteration for calculating the reciprocal for double type. The precision of division is propotional to this param when division approximation is enabled. The default value is 3.
> +

typo: s/propotional/proportional/.  Also, maybe
s/Newton-iteration/Newton iterations/

Looks good otherwise.  However, the patch is unfortunately big enough to
need a copyright assignment to the FSF.  Do you already have one on file
(either a personal or a corporate one, depending on your circumstances)?
If not, would you be willing to sign one?  I can send you the forms
off-list if so.

Thanks,
Richard