<div dir="ltr"><div>My personal opinion is that a general-purpose libc should aim for accuracy over speed on functions such as this, because accuracy is far more generally useful.</div><div><br></div><div>It's reasonably trivial to pick a point on the speed/accuracy balance that's accurate enough for nearly all programs, just by choosing the most accurate implementation that's not abysmally slow.  This includes working for what is by far the most common case, which is "I have no idea what accuracy I need here so long as the overall program gets the right answer, and I don't want to try to figure it out."  That's also a kindness for users; errors from loss of floating-point precision in transcendental functions are fiercely painful to debug.</div><div><br></div><div>On the speed side, most uses of math.h functions aren't in hot paths where getting the highest possible speed matters, and most of the uses that are in those paths probably shouldn't be.  Even aside from things like vectorization, most algorithms can trade off some amount of accuracy (whether in precision or in range of inputs), but what they can trade off is very algorithm-dependent.  In those performance-critical spots, what's needed is inherently going to be a specialized function, not a general-purpose one from a standard library.  So, again, when a general-purpose function is actually appropriate, pushing the balance almost all the way to the "accuracy" side is still an acceptable choice.</div><div><br></div><div>The tricky bit comes with that "almost" in "almost all the way to the 'accuracy' side"; at some point, the cost/benefit tradeoff becomes very steep.  I don't know whether a 5x cost to the hypot(double,double) algorithm is worth it, given that glibc is already very accurate.  However, both "hypot" and "double" are used specifically in cases where accuracy matters, so IMO the answer is probably yes.</div><div><br></div><div>- Brooks</div><div><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">On Mon, Jun 22, 2020 at 12:09 PM Sameed A. Pervaiz via libc-dev <<a href="mailto:libc-dev@lists.llvm.org">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"><div dir="ltr"><div style="font-size:small">Hi all,<br></div><div class="gmail_quote">
<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>
<br>
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...<br>
<br>
If anyone could shed some insight into this question, as vague or<br>
trivial as it might be, I would be most grateful.<br>
<br>
Cheers,<br>
Sameed<br>
_______________________________________________<br>
libc-dev mailing list<br>
<a href="mailto:libc-dev@lists.llvm.org" target="_blank">libc-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libc-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/libc-dev</a><br>
</div></div>
</blockquote></div></div>