[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120123164152.GZ31975@port70.net>
Date: Mon, 23 Jan 2012 17:41:52 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: libm
i've looked into libm implementations
to figure out what's best for musl
some resources:
http://nsz.repo.hu/libm.txt
there are various issues:
* reproducible semantics:
linux uses double extended precision by default on i386
which does not give the same results as standard 64bit
ieee754 (sse2, x86_64, arm)
bsd uses plain double precision by default on i386
(so at least when bsd functions are ported the precision
claims should be reevaluated)
most of the recent advances in efficient and correct
function evaluation assume strict ieee754 64bit arithmetics
(so they can do formal proofs etc, some algorithms assume
fma instruction which is not available on musl's targets)
portable semantics are not easy to guarantee (extended
precision, rounding modes, compiler optimizations)
(especially if efficiency is important as well)
* tradeoffs:
modern libms (libmcr, libultim, crlibm) try to guarantee
correctness but arg reduction and faithful (or even
correct) rounding is hard to do and hard to verify
some libms prefer simple implementation (eg the go math
package sincos is from cephes and starts to get inaccurate
when |x| > 2^30, but the implementation is much simpler
than the arg reduction in fdlibm)
in theory one should prefer correctness instead of size
and speed, but there are significant differences in code
size and implementation effort
the speed of a correct implementation can be good in
average case, but not in worstcase
* libms in practice:
many functions are the same in glibc and the various
bsd libcs (they are mostly based on fdlibm, but glibc
64bit double precision functions are from the gpl
licensed libultim)
the extended precision algorithms are reused across
different libcs as well, but there are 80bit vs 128bit
differences. the correctness of extended precision
algorithms are much less studied (eg there are no
correctly rounded versions or worstcases for 2pi arg
reductions)
most of the complex functions are simple once elementary
functions are there (bsd libcs has bsd licensed
implementations of these)
conclusion:
the simplest approach for musl at this point is to
reuse the already available math functions
(+run the available tests on them)
this can be done by diffing the various bsd and glibc
functions and choosing the best one (usually they are
the same except code organization and bit manipulation
details)
most of the task is understanding floating point
semantics well (not the mathematics of the algorithms)
and doing code cleanups
code and ideas from crlibm might be possible to use
but that would take much more effort and knowledge
(assuming we want small code size)
designing new algorithms for elementary functions seems
to require a huge effort and the best tradoffs are not
even clear
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
