[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZopFT85iJ5nKZuOAGOW05utTNGcwOjY_tZOUoc_mtXMMXg@mail.gmail.com>
Date: Fri, 2 Sep 2022 12:28:33 -0700
From: enh <enh@...gle.com>
To: musl@...ts.openwall.com
Cc: Paul Zimmermann <Paul.Zimmermann@...ia.fr>
Subject: Re: Re: integration of CORE-MATH routines into Musl?
On Fri, Sep 2, 2022 at 5:18 AM Rich Felker <dalias@...c.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
>
Content of type "text/html" skipped
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.
