<div dir="ltr"><div dir="ltr">On Mon, Jun 22, 2020 at 11:16 AM Sameed A. Pervaiz via libc-dev <<a href="mailto:libc-dev@lists.llvm.org" target="_blank">libc-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
I was just wondering about what balance between speed/accuracy the<br>
project is aiming to hit in functions such as `hypot(double, double)'.<br></blockquote><div><br></div><div>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.</div><div> </div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In particular, I was looking at a recent algorithm published at<br>
<a href="https://arxiv.org/abs/1904.09481" rel="noreferrer" target="_blank">https://arxiv.org/abs/1904.09481</a> which offers an accuracy/rounding<br>
improvement over glibc's `__ieee754_hypot(double, double)' at the sake<br>
of around a 5x performance penalty...</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If anyone could shed some insight into this question, as vague or<br>
trivial as it might be, I would be most grateful.</blockquote><div><br></div><div>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: <a href="https://github.com/llvm/llvm-project/blob/master/libc/benchmarks/README.md" target="_blank">https://github.com/llvm/llvm-project/blob/master/libc/benchmarks/README.md</a></div><div>For math functions, we should start with as accurate as possible implementations, and adjust according to the data presented.</div><div><br></div><div>Thanks,</div><div>Siva Chandra</div></div></div>