Volunteering/Consulting for libm Development in glibc

[Wilco Dijkstra]

Hi Ayan,

My advice would be to start with a few really simple patches and build things up
from there. The math library still contains large amounts of ancient fdlibm code
that is slow and hard to maintain. Rewriting basic operations like frexp, modf etc
using modern idioms and using math_config.h for reporting errors explicitly using
calls to __math_oflow() should be relatively easy and worthwhile as an initial project.

Collecting traces of math calls from real applications would be useful to improve
our benchmarks. I've submitted various traces as these are hugely useful to ensure
math functions are actually fast on real inputs (it's a common mistake to repeat the
same input or using fully random inputs...).

Removing all remaining slow errno/exception veneers would be useful, however this
is very specific to GLIBC and not trivial to get right.

A harder project may be to look at rewriting some of the math functions that have
bad accuracy (as shown in [1]) and improve their performance. Most double precision
functions (besides exp, pow, log) are still old, slow and unnecessarily complex. One
that springs to mind are double precision sin, cos, tan and their absolutely insanely
bad range reduction (the single precision sinf/cosf shows how it should be done).

Another option is improving accuracy of existing optimized functions and see if there
are better tradeoffs between polynomial size, table size and performance on modern
wide cores with many FMA units.

Cheers,
Wilco



[1] https://members.loria.fr/PZimmermann/papers/accuracy.pdf