Re: [PATCH 4/4] math: Improve fmodf

[Matt Turner <mattst88@gmail.com>]

On Fri, Mar 10, 2023 at 1:01 PM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> This uses a new algorithm similar to already proposed earlier [1].
> With x = mx * 2^ex and y = my * 2^ey (mx, my, ex, ey being integers),
> the simplest implementation is:
>
>    mx * 2^ex == 2 * mx * 2^(ex - 1)
>
>    while (ex > ey)
>      {
>        mx *= 2;
>        --ex;
>        mx %= my;
>      }
>
> With mx/my being mantissa of double floating pointer, on each step the
> argument reduction can be improved 8 (which is sizeof of uint32_t minus
> MANTISSA_WIDTH plus the signal bit):
>
>    while (ex > ey)
>      {
>        mx << 8;
>        ex -= 8;
>        mx %= my;
>      }  */
>
> The implementation uses builtin clz and ctz, along with shifts to
> convert hx/hy back to doubles.  Different than the original patch,
> this path assume modulo/divide operation is slow, so use multiplication
> with invert values.
>
> I see the following performance improvements using fmod benchtests
> (result only show the 'mean' result):
>
>   Architecture     | Input           | master   | patch
>   -----------------|-----------------|----------|--------
>   x86_64 (Ryzen 9) | subnormals      | 17.2549  | 12.3214
>   x86_64 (Ryzen 9) | normal          | 85.4096  | 52.6625
>   x86_64 (Ryzen 9) | close-exponents | 19.1072  | 17.4622
>   aarch64 (N1)     | subnormal       | 10.2182  | 6.81778
>   aarch64 (N1)     | normal          | 60.0616  | 158.339

Is this line correct? 60 -> 158?