mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Re: integration of CORE-MATH routines into Musl?
       [not found] <mwv8q6ccj9.fsf@tomate.loria.fr>
@ 2022-09-02 12:17 ` Rich Felker
  2022-09-02 19:28   ` enh
  2022-09-05  9:09   ` Paul Zimmermann
  0 siblings, 2 replies; 8+ messages in thread
From: Rich Felker @ 2022-09-02 12:17 UTC (permalink / raw)
  To: Paul Zimmermann; +Cc: musl

On Fri, Sep 02, 2022 at 12:10:18PM +0200, Paul Zimmermann wrote:
>        Dear Rich,
> 
> we now distribute the CORE-MATH routines under the MIT license,
> to ease integration into Musl (among other libraries).
> 
> Please can you point out to a Musl developer who might be
> interested to integrate some CORE-MATH routines?
> 
> We will try to answer potential issues that might arise
> during this integration.
> 
> Best regards,
> Paul
> 
> PS: see https://hal.inria.fr/hal-03721525 for more details about
> the CORE-MATH project.

Could you summaraize briefly what you have in mind, and what tradeoffs
might be? Are these intended to be drop-in replacements for the
existing standard functions, or implementations for the "cr" versions
thereof? I have not followed closely the "mandatory requirement of
correct rounding for mathematical functions in the next revision of
the IEEE-754 standard" topic and how it relates to the future of C,
but my vague recollection was that the direction folks were leaning
was towards a separate set of cr*() functions or something. But if
it's possible to do correct rounding in a way that's all-wins
(performance, size, quality of results) or nearly all wins (maybe
slightly larger?), at least for select functions, that seems very
interesting.

Rich

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] Re: integration of CORE-MATH routines into Musl?
  2022-09-02 12:17 ` [musl] Re: integration of CORE-MATH routines into Musl? Rich Felker
@ 2022-09-02 19:28   ` enh
  2022-09-02 20:40     ` enh
  2022-09-05  9:09   ` Paul Zimmermann
  1 sibling, 1 reply; 8+ messages in thread
From: enh @ 2022-09-02 19:28 UTC (permalink / raw)
  To: musl; +Cc: Paul Zimmermann

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

On Fri, Sep 2, 2022 at 5:18 AM Rich Felker <dalias@libc.org> wrote:

> On Fri, Sep 02, 2022 at 12:10:18PM +0200, Paul Zimmermann wrote:
> >        Dear Rich,
> >
> > we now distribute the CORE-MATH routines under the MIT license,
> > to ease integration into Musl (among other libraries).
> >
> > Please can you point out to a Musl developer who might be
> > interested to integrate some CORE-MATH routines?
> >
> > We will try to answer potential issues that might arise
> > during this integration.
> >
> > Best regards,
> > Paul
> >
> > PS: see https://hal.inria.fr/hal-03721525 for more details about
> > the CORE-MATH project.
>
> Could you summaraize briefly what you have in mind, and what tradeoffs
> might be? Are these intended to be drop-in replacements for the
> existing standard functions, or implementations for the "cr" versions
> thereof? I have not followed closely the "mandatory requirement of
> correct rounding for mathematical functions in the next revision of
> the IEEE-754 standard" topic and how it relates to the future of C,
> but my vague recollection was that the direction folks were leaning
> was towards a separate set of cr*() functions or something. But if
> it's possible to do correct rounding in a way that's all-wins
> (performance, size, quality of results) or nearly all wins (maybe
> slightly larger?), at least for select functions, that seems very
> interesting.
>

"what he said" (including the "i haven't been following the details").

assuming you have good answers to those questions then -- if you haven't
already done so -- you should probably also bring this up with
freebsd-numerics (https://wiki.freebsd.org/Numerics and the mailing list
mentioned on that page). that's the source of the vast majority of the libm
code used by Android/iOS/macOS. (the exceptions for Android are mostly
binary128 stuff from netbsd and arm32/arm64 optimized code from
https://github.com/ARM-software/optimized-routines.)

on the opposite end of the spectrum, llvm-libc isn't widely used at all,
but that work is at such an early stage (although it seems like they have
had a heavy libm focus) that they probably don't have existing
implementations for a lot of stuff.

it seems -- having admittedly not read past the abstract of the paper that
you linked to -- that you're only addressing binary32 so far? not even
binary64? (i'm used to binary128 not getting much love!)

(oh, and thanks for picking a license that makes it much more likely that
all the libcs can use your work!)


> Rich
>

[-- Attachment #2: Type: text/html, Size: 3511 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] Re: integration of CORE-MATH routines into Musl?
  2022-09-02 19:28   ` enh
@ 2022-09-02 20:40     ` enh
  0 siblings, 0 replies; 8+ messages in thread
From: enh @ 2022-09-02 20:40 UTC (permalink / raw)
  To: musl; +Cc: Paul Zimmermann

[-- Attachment #1: Type: text/plain, Size: 3002 bytes --]

(having now had time to skim the whole paper, i see you are already
comparing against llvm-libc [if not actually talking to them], and that you
have done some binary64 work [but no binary128 yet]. if you are trying to
find someone to talk to about llvm-libc and struggling with that, let me
know and i can try to find someone...)

On Fri, Sep 2, 2022 at 12:28 PM enh <enh@google.com> wrote:

>
>
> On Fri, Sep 2, 2022 at 5:18 AM Rich Felker <dalias@libc.org> wrote:
>
>> On Fri, Sep 02, 2022 at 12:10:18PM +0200, Paul Zimmermann wrote:
>> >        Dear Rich,
>> >
>> > we now distribute the CORE-MATH routines under the MIT license,
>> > to ease integration into Musl (among other libraries).
>> >
>> > Please can you point out to a Musl developer who might be
>> > interested to integrate some CORE-MATH routines?
>> >
>> > We will try to answer potential issues that might arise
>> > during this integration.
>> >
>> > Best regards,
>> > Paul
>> >
>> > PS: see https://hal.inria.fr/hal-03721525 for more details about
>> > the CORE-MATH project.
>>
>> Could you summaraize briefly what you have in mind, and what tradeoffs
>> might be? Are these intended to be drop-in replacements for the
>> existing standard functions, or implementations for the "cr" versions
>> thereof? I have not followed closely the "mandatory requirement of
>> correct rounding for mathematical functions in the next revision of
>> the IEEE-754 standard" topic and how it relates to the future of C,
>> but my vague recollection was that the direction folks were leaning
>> was towards a separate set of cr*() functions or something. But if
>> it's possible to do correct rounding in a way that's all-wins
>> (performance, size, quality of results) or nearly all wins (maybe
>> slightly larger?), at least for select functions, that seems very
>> interesting.
>>
>
> "what he said" (including the "i haven't been following the details").
>
> assuming you have good answers to those questions then -- if you haven't
> already done so -- you should probably also bring this up with
> freebsd-numerics (https://wiki.freebsd.org/Numerics and the mailing list
> mentioned on that page). that's the source of the vast majority of the libm
> code used by Android/iOS/macOS. (the exceptions for Android are mostly
> binary128 stuff from netbsd and arm32/arm64 optimized code from
> https://github.com/ARM-software/optimized-routines.)
>
> on the opposite end of the spectrum, llvm-libc isn't widely used at all,
> but that work is at such an early stage (although it seems like they have
> had a heavy libm focus) that they probably don't have existing
> implementations for a lot of stuff.
>
> it seems -- having admittedly not read past the abstract of the paper that
> you linked to -- that you're only addressing binary32 so far? not even
> binary64? (i'm used to binary128 not getting much love!)
>
> (oh, and thanks for picking a license that makes it much more likely that
> all the libcs can use your work!)
>
>
>> Rich
>>
>

[-- Attachment #2: Type: text/html, Size: 4225 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [musl] Re: integration of CORE-MATH routines into Musl?
  2022-09-02 12:17 ` [musl] Re: integration of CORE-MATH routines into Musl? Rich Felker
  2022-09-02 19:28   ` enh
@ 2022-09-05  9:09   ` Paul Zimmermann
  2022-09-05 13:08     ` Szabolcs Nagy
  2022-09-06 23:40     ` enh
  1 sibling, 2 replies; 8+ messages in thread
From: Paul Zimmermann @ 2022-09-05  9:09 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

       Dear Rich,

> Could you summaraize briefly what you have in mind, and what tradeoffs
> might be? Are these intended to be drop-in replacements for the
> existing standard functions, or implementations for the "cr" versions
> thereof? I have not followed closely the "mandatory requirement of
> correct rounding for mathematical functions in the next revision of
> the IEEE-754 standard" topic and how it relates to the future of C,
> but my vague recollection was that the direction folks were leaning
> was towards a separate set of cr*() functions or something.

the current situation is:

- IEEE 754 does not require correct rounding for mathematical functions

- indeed, the C2X standard will reserve cr_xxx names for correctly rounded
  functions

- thus mathematical libraries will have essentially 3 choices:

0) either provide incorrectly rounded functions as (say) exp.
   This is the current situation.

1) provide incorrectly rounded functions as exp, and correctly rounded
   functions as cr_exp.

2) or provide only exp, with correct rounding (then cr_exp could be an alias
   for exp)

It seems that LLVM-libc will go for 2), I have no news from other libraries.

> But if
> it's possible to do correct rounding in a way that's all-wins
> (performance, size, quality of results) or nearly all wins (maybe
> slightly larger?), at least for select functions, that seems very
> interesting.

If you look at Table II from https://hal.inria.fr/hal-03721525, you see that
for *single* precision functions (binary32), indeed that's all-wins.

Best regards,
Paul


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] Re: integration of CORE-MATH routines into Musl?
  2022-09-05  9:09   ` Paul Zimmermann
@ 2022-09-05 13:08     ` Szabolcs Nagy
  2022-09-05 14:39       ` Paul Zimmermann
  2022-09-06 23:40     ` enh
  1 sibling, 1 reply; 8+ messages in thread
From: Szabolcs Nagy @ 2022-09-05 13:08 UTC (permalink / raw)
  To: Paul Zimmermann; +Cc: Rich Felker, musl

* Paul Zimmermann <Paul.Zimmermann@inria.fr> [2022-09-05 11:09:04 +0200]:
>        Dear Rich,
> 
> > Could you summaraize briefly what you have in mind, and what tradeoffs
> > might be? Are these intended to be drop-in replacements for the
> > existing standard functions, or implementations for the "cr" versions
> > thereof? I have not followed closely the "mandatory requirement of
> > correct rounding for mathematical functions in the next revision of
> > the IEEE-754 standard" topic and how it relates to the future of C,
> > but my vague recollection was that the direction folks were leaning
> > was towards a separate set of cr*() functions or something.
> 
> the current situation is:
> 
> - IEEE 754 does not require correct rounding for mathematical functions
> 
> - indeed, the C2X standard will reserve cr_xxx names for correctly rounded
>   functions
> 
> - thus mathematical libraries will have essentially 3 choices:
> 
> 0) either provide incorrectly rounded functions as (say) exp.
>    This is the current situation.
> 
> 1) provide incorrectly rounded functions as exp, and correctly rounded
>    functions as cr_exp.
> 
> 2) or provide only exp, with correct rounding (then cr_exp could be an alias
>    for exp)
> 
> It seems that LLVM-libc will go for 2), I have no news from other libraries.
> 
> > But if
> > it's possible to do correct rounding in a way that's all-wins
> > (performance, size, quality of results) or nearly all wins (maybe
> > slightly larger?), at least for select functions, that seems very
> > interesting.
> 
> If you look at Table II from https://hal.inria.fr/hal-03721525, you see that
> for *single* precision functions (binary32), indeed that's all-wins.

when i worked on exp and log i noticed that for single prec it is
easy to do correct rounding with only minor overhead, but it required
either a bit bigger lookup table or a bit bigger polynomial vs going
for < 1 ulp error only.

a slightly bigger lookup table will not be measureable in a micro
beanchmark, but clearly will use more resources. (also measuring
against the system library is misleading: your code is static linked
while the libc is dynamic linked, -fPIC, does not have the same error
handling logic, same cflags for security hardening or whatever.
such differences can be significant when the entire math function is
about 10 cycles.)


so do we want correct rounding for a little bit of overhead?

my idea was that most users of binary32 care more about performance
than precision (if they want precision they can use binary64 with only
a small overhead on most cpus). so not doing cr was deliberate choice.

my answer changes if users start to expect cr version of math functions
in the libc, 2x code is hard to justify for minor benefits, so then
we should only have cr versions for binary32.

there are libm functions where the current code is low quality and
a fast cr implementation is strictly better, those are welcome i think.

the binary64 (and binary128) story is different (there it's more work
to get cr_ functions, in some cases like pow i don't think there is a
low latency solution as the worst case is not known). for functions
where the worst-case is known we can provide cr, if the overhead is not
too big (i think 10% overhead is acceptable in the common case and 10x
overhead for the rare half-way cases, but only if the code/rodata size
does not explode).

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] Re: integration of CORE-MATH routines into Musl?
  2022-09-05 13:08     ` Szabolcs Nagy
@ 2022-09-05 14:39       ` Paul Zimmermann
  2022-09-05 16:38         ` Szabolcs Nagy
  0 siblings, 1 reply; 8+ messages in thread
From: Paul Zimmermann @ 2022-09-05 14:39 UTC (permalink / raw)
  To: Szabolcs Nagy; +Cc: dalias, musl

       Dear Szabolcs,

> when i worked on exp and log i noticed that for single prec it is
> easy to do correct rounding with only minor overhead, but it required
> either a bit bigger lookup table or a bit bigger polynomial vs going
> for < 1 ulp error only.

please have a look at https://gitlab.inria.fr/core-math/core-math/-/blob/master/src/binary32/exp/expf.c: no big lookup table, degree 5 only.

Paul

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] Re: integration of CORE-MATH routines into Musl?
  2022-09-05 14:39       ` Paul Zimmermann
@ 2022-09-05 16:38         ` Szabolcs Nagy
  0 siblings, 0 replies; 8+ messages in thread
From: Szabolcs Nagy @ 2022-09-05 16:38 UTC (permalink / raw)
  To: Paul Zimmermann; +Cc: dalias, musl

* Paul Zimmermann <Paul.Zimmermann@inria.fr> [2022-09-05 16:39:02 +0200]:

>        Dear Szabolcs,
> 
> > when i worked on exp and log i noticed that for single prec it is
> > easy to do correct rounding with only minor overhead, but it required
> > either a bit bigger lookup table or a bit bigger polynomial vs going
> > for < 1 ulp error only.
> 
> please have a look at https://gitlab.inria.fr/core-math/core-math/-/blob/master/src/binary32/exp/expf.c: no big lookup table, degree 5 only.

"a bit bigger".

in this case the polynomial is bigger: order 5 instead of 3.
(order 3 is enough for < 1 ulp error).

the code size is also bigger:

core-math: size -G (x86_64 -O3):

      text       data        bss      total filename
       464        352          0        816 exp2/exp2f.o
       398        348          0        746 exp/expf.o

musl: size -G: (data is shared between expf, exp2f and powf)

      text       data        bss      total filename
         0        328          0        328 exp2f_data.o
       202         12          0        214 exp2f.o
       211         16          0        227 expf.o

i'd expect at least a bit of overhead between <1 ulp and cr functions
(but not significant overhead in case of binary32). so when core-math
is faster, it should be possible to write an even faster version that
only aims to be <1 ulp (but the perf diff will not be huge).

in case of binary64: i'd expect one can turn a close to 0.5 ulp
implementation into a cr one with small overhead by testing for near
halfway cases in the end and having a slow path for those. but the
slow path will be much slower and bigger (and harder to test).


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] Re: integration of CORE-MATH routines into Musl?
  2022-09-05  9:09   ` Paul Zimmermann
  2022-09-05 13:08     ` Szabolcs Nagy
@ 2022-09-06 23:40     ` enh
  1 sibling, 0 replies; 8+ messages in thread
From: enh @ 2022-09-06 23:40 UTC (permalink / raw)
  To: musl; +Cc: Rich Felker

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]

On Mon, Sep 5, 2022 at 2:09 AM Paul Zimmermann <Paul.Zimmermann@inria.fr>
wrote:

>        Dear Rich,
>
> > Could you summaraize briefly what you have in mind, and what tradeoffs
> > might be? Are these intended to be drop-in replacements for the
> > existing standard functions, or implementations for the "cr" versions
> > thereof? I have not followed closely the "mandatory requirement of
> > correct rounding for mathematical functions in the next revision of
> > the IEEE-754 standard" topic and how it relates to the future of C,
> > but my vague recollection was that the direction folks were leaning
> > was towards a separate set of cr*() functions or something.
>
> the current situation is:
>
> - IEEE 754 does not require correct rounding for mathematical functions
>
> - indeed, the C2X standard will reserve cr_xxx names for correctly rounded
>   functions
>
> - thus mathematical libraries will have essentially 3 choices:
>
> 0) either provide incorrectly rounded functions as (say) exp.
>    This is the current situation.
>
> 1) provide incorrectly rounded functions as exp, and correctly rounded
>    functions as cr_exp.
>
> 2) or provide only exp, with correct rounding (then cr_exp could be an
> alias
>    for exp)
>
> It seems that LLVM-libc will go for 2), I have no news from other
> libraries.
>

(fwiw, #2 is almost certainly what we'll do with bionic too.)


> > But if
> > it's possible to do correct rounding in a way that's all-wins
> > (performance, size, quality of results) or nearly all wins (maybe
> > slightly larger?), at least for select functions, that seems very
> > interesting.
>
> If you look at Table II from https://hal.inria.fr/hal-03721525, you see
> that
> for *single* precision functions (binary32), indeed that's all-wins.
>
> Best regards,
> Paul
>
>

[-- Attachment #2: Type: text/html, Size: 2580 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-09-06 23:41 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <mwv8q6ccj9.fsf@tomate.loria.fr>
2022-09-02 12:17 ` [musl] Re: integration of CORE-MATH routines into Musl? Rich Felker
2022-09-02 19:28   ` enh
2022-09-02 20:40     ` enh
2022-09-05  9:09   ` Paul Zimmermann
2022-09-05 13:08     ` Szabolcs Nagy
2022-09-05 14:39       ` Paul Zimmermann
2022-09-05 16:38         ` Szabolcs Nagy
2022-09-06 23:40     ` enh

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).