Open japaric opened 6 years ago
PR #141 implements this
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)
@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.
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:
math::musl
module and make sure we continue compiling it.tests/newlib.rs
and removing the function name fromtests/musl.rs
.