[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 3 Jan 2022 21:29:05 -0500
From: Rich Felker <dalias@...c.org>
To: Paul Zimmermann <Paul.Zimmermann@...ia.fr>
Cc: musl@...ts.openwall.com, sibid@...c.ca,
christoph.lauter@...istoph-lauter.org,
Jean-Michel.Muller@...-LYON.FR
Subject: Re: correctly rounded mathematical functions
On Mon, Jan 03, 2022 at 02:07:59PM +0100, Paul Zimmermann wrote:
> Dear Musl developers,
>
> the current C working draft [1, p392] has reserved names for correctly
> rounded functions (cr_exp, cr_log, cr_sin, ...).
>
> We propose to provide such correctly rounded implementations
> for the three IEEE formats (binary32, binary64, binary128) and the
> "extended double" format (long double on x86_64).
>
> These implementations will be correctly rounded for all rounding modes,
> for example one could do the following to emulate interval arithmetic:
>
> fesetround (FE_DOWNWARD);
> y_lo = cr_exp (x_lo);
> fesetround (FE_UPWARD);
> y_hi = cr_exp (x_hi);
>
> Users who want a fast implementation will call the exp/log/sin/... functions,
> users who want a correctly rounded function and thus reproducible results
> (whatever the hardware, compiler or operating system) will use the
> cr_exp/cr_log/cr_sin/... functions. Our goal is nevertheless to get the
> best performance possible.
>
> Our objective is to provide open-source implementations that can be integrated
> in the major mathematical libraries (GNU libc, Intel Math Library, AMD Libm,
> Redhat Newlib, OpenLibm, Musl, llvm-libc, CUDA, ROCm).
>
> Are developers of Musl interested by such functions?
> If so, we could discuss what would be the requirements for integration in
> Musl in terms of license, table size, allowed operations.
License: should be licensed under something permissive and
MIT-compatible, preferably explicitly MIT if you'll be
dual-/multi-licensing anyway.
Table size: main consideration is that tables need to be pure
shareable rodata, so no runtime generation of contents or pointers in
contents. Failure to follow this would produce significant cost in
*all processes* even ones that don't use the cr_* functions. I would
hope they'd also fit in a few tens of kB of rodata, but I don't know
how realistic that is.
Allowed operations: I'm not sure what the scope of this question is.
Are you asking if things like changing rounding mode would be okay? Or
something else. musl implements C11 and hopefully future versions of
the language library, but is implemented in C99 (+ very minimal set of
common/"GNU C" extensions), so code to be included in musl shouldn't
depend on new language features or compiler extensions not already
used (at least without checking on them first). We also have
softfloat-only targets and targets with excess precision, so code
should be compatible with those (which means not depending on changing
fenv; see commit 4f3d346bffdf9ed2b1803653643dc31242490944 for an
example of where this came up).
> We have started to work on two functions (cbrt and acos), for which we
> provide presumably correctly rounded implementations (up to the knowledge
> of hard-to-round cases) [2].
>
> Christoph Lauter
> Jean-Michel Muller
> Alexei Sibidanov
> Paul Zimmermann
>
> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
> [2] https://homepages.loria.fr/PZimmermann/CORE-MATH/
Is there a standalone version of the code where it can be read in full
not as a patch to glibc? Is the code being developed in such a way
that it's not potentially a derivative work of the glibc versions?
Rich
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.
