mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: libm
Date: Mon, 23 Jan 2012 17:41:52 +0100	[thread overview]
Message-ID: <20120123164152.GZ31975@port70.net> (raw)

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


             reply	other threads:[~2012-01-23 16:41 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-23 16:41 Szabolcs Nagy [this message]
2012-01-23 17:07 ` libm Rich Felker
2012-01-23 19:12   ` libm Szabolcs Nagy
2012-01-27 16:02     ` libm Szabolcs Nagy
2012-01-27 19:01       ` libm Pascal Cuoq
2012-01-27 19:34         ` libm Rich Felker
2012-01-29 16:34           ` libm Szabolcs Nagy
2012-02-27 21:02   ` libm Szabolcs Nagy
2012-02-27 22:24     ` libm Rich Felker
2012-03-03 22:57       ` libm Szabolcs Nagy
2012-03-04  6:53         ` libm Rich Felker
2012-03-04 14:50           ` libm Szabolcs Nagy
2012-03-04 18:43             ` libm Rich Felker
2012-03-05  8:51               ` libm Szabolcs Nagy
2012-03-05 14:04                 ` libm Rich Felker
2012-03-05 15:17                   ` libm Szabolcs Nagy
2012-03-05 15:25                     ` libm Rich Felker
2012-03-09 10:22                     ` libm Rich Felker
2012-03-09 10:57                       ` libm Szabolcs Nagy
2012-03-09 16:01                         ` libm Rich Felker
2012-03-09 11:09                       ` libm Szabolcs Nagy
2012-03-09 15:56                         ` libm Rich Felker
2012-03-09 17:02                           ` libm Rich Felker
2012-03-10  3:28                             ` libm Rich Felker
2012-03-10 12:45                               ` libm Szabolcs Nagy
2012-03-10 13:12                                 ` libm Rich Felker
2012-03-10 16:38                                   ` libm Szabolcs Nagy
2012-03-05 11:08             ` libm Szabolcs Nagy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120123164152.GZ31975@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).