port newlib's sinf

[japaric]

Source 1: https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libm/math/sf_sin.c;hb=HEAD

Source 2: https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libm/mathfp/sf_sine.c;hb=HEAD

(Unsure which one we want)

Rationale: the current implementation makes use of f64 and it has bad performance on architectures that have no hardware support for double precision floats.

What needs to be done:

• Move the existing MUSL port into a private math::musl module and make sure we continue compiling it.
• Port the newlib version into src/math/$fun.rs
• Update the test suite by uncommenting the function name in tests/newlib.rs and removing the function name from tests/musl.rs.

[japaric]

PR #141 implements this

[burrbull]

Interesting speed results (x86_64 GNU/Linux):

For x = 0.61587854

test tests::b_sin_libm    ... bench:           5 ns/iter (+/- 0)
test tests::b_sin_sleef   ... bench:          22 ns/iter (+/- 1)
test tests::b_sinf_fp     ... bench:          18 ns/iter (+/- 0)
test tests::b_sinf_libm   ... bench:           6 ns/iter (+/- 0)
test tests::b_sinf_newlib ... bench:           6 ns/iter (+/- 0)
test tests::b_sinf_sleef  ... bench:          15 ns/iter (+/- 0)

For x = 0.61587854*100000.

test tests::b_sin_libm    ... bench:          23 ns/iter (+/- 0)
test tests::b_sin_sleef   ... bench:          32 ns/iter (+/- 0)
test tests::b_sinf_fp     ... bench:          18 ns/iter (+/- 2)
test tests::b_sinf_libm   ... bench:          12 ns/iter (+/- 1)
test tests::b_sinf_newlib ... bench:         452 ns/iter (+/- 65)
test tests::b_sinf_sleef  ... bench:          98 ns/iter (+/- 6)

[gnzlbg]

@burrbull how are you compiling the sleef benchmarks (and are those the 0.5 ULP accuracy functions) ?

Test-wise, it shouldn't matter whether we check results against musl, newlib, the systems libm, or all of those. We should be comparing results for either 0.5 or 1 ULP accuracy, depending on what we deem ok.

[tgross35]

I am closing all newlib issues; please see #133 (comment) for context.