[libc-dev] Question About <math.h> Speed/Accuracy Goals with llvm-libc

[Siva Chandra via libc-dev]

On Mon, Jun 22, 2020 at 11:16 AM Sameed A. Pervaiz via libc-dev <
libc-dev at lists.llvm.org> wrote:

> Hi all,
>
> I was just wondering about what balance between speed/accuracy the
> project is aiming to hit in functions such as `hypot(double, double)'.
>

I am not sure we can have a generalized answer here. As a personal first
opinion, I will lean on the side of accuracy. After all, I would expect
that functions like these give me the correct (as in, as accurate as
possible) results. Brooks put it perfectly, " have no idea what accuracy I
need here so long as the overall program gets the right answer." I would
just trust that the libc is giving me correct results and will debug "my"
code when something goes wrong. So, I want the libc to not betray that
trust.

Now, there could be applications where a high precision result is not of
importance, but the speed with which imperfect results are computed
matters. Should a libc cater to such use cases? Personally, I don't think
so. But, if 90% of the use cases don't need that accuracy which is being
achieved at the cost of speed which is being a burden, then we might/should
reprioritize.

In particular, I was looking at a recent algorithm published at
> https://arxiv.org/abs/1904.09481 which offers an accuracy/rounding
> improvement over glibc's `__ieee754_hypot(double, double)' at the sake
> of around a 5x performance penalty...

If anyone could shed some insight into this question, as vague or
> trivial as it might be, I would be most grateful.


In general, data should help us answer this. Take the case of the current
memcpy implementation for example. It is optimized for sizes less than 128
bytes because it was found that in practice, 96% percent of the calls to
memcpy are for sizes <= 128 bytes:
https://github.com/llvm/llvm-project/blob/master/libc/benchmarks/README.md
For math functions, we should start with as accurate as
possible implementations, and adjust according to the data presented.

Thanks,
Siva Chandra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libc-dev/attachments/20200622/1f149690/attachment.html>