Re: [musl] Re: integration of CORE-MATH routines into Musl?

[enh <enh@google.com>]

[-- 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 --]