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