Re: [PATCH v2 3/5] math: Improve fmod

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 16/03/23 13:13, Wilco Dijkstra wrote:
> Hi,
> 
> It's these cases where x87 is still faster than the generic version:
> 
>> E5-2640          | close-exponents | 39.298   | 22.2742
>>
>> i7-4510U         | close-exponents | 29.463   | 22.8572
> 
> Are these mostly x < y or cases where the exponent difference is just over 11 and
> thus we do not use the fast path?

In fact the fast path will be used on ~83% of the cases (849 from 1024 entries).
Profiling shows that the initial checks might be the culprit, since generic 
compat wrapper uses compiler builtins that might map to fp instructions. But even
trying to mimic did not improve much.  It seems that for some CPU the integer
operations to create the final floating number is what is costly.

> 
>> I am also checking a algorithm change to use simple loop for the normal inputs,
>> where integer modulo operation is used instead of inverse multiplication. 
> 
> Adding another fast path for a wider range of exponent difference could be faster
> than the generic modulo loop. This could do 2 modulo steps and maybe handle
> tail zeroes (which I think is what HJ's testcase will benefit from).
> 
> For really large exponent differences, the generic modulo code could process 30
> or 60 bits per iteration instead of just 11. It's more complex (so would be a separate
> patch) but it should help CPUs with relatively high latency multipliers.

Yes, it might be an improvement indeed.