From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8688 invoked from network); 2 Sep 2022 20:41:07 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 2 Sep 2022 20:41:07 -0000 Received: (qmail 11274 invoked by uid 550); 2 Sep 2022 20:41:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 10211 invoked from network); 2 Sep 2022 20:41:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=NnvaTgjVRf+Ul9h+QAYt0U2edwb4gZZSYOvj7Zm2bgE=; b=A5jMhwxE7VhtrCT3q+YD24lCUW0tbvsIwxIkH7K9QZXK4Rip/HpsVrUn67Lnl9ltrG 5bci0g7fzEXfXvK8nmRKROqIaBcwK666SkwAdSC3Hf5NGno0aEWeNmU7xI8vs+sBYDjy pMzeG+p5ebeGuRBqK0aLlv4me1M7+D8FZ0DUGkRbbdq6/z6f29c17ae62Du4o6VKMNkf sk/mEoQyblFiQ3gx4CoIDeLnVYpD2NAGD+OerkEPxZaNzJ0v7RK6m9jGTUptt0apBjEa HDURQVZRm9lRFozsaFb1sa/ERhdZmFHRU+2RnssaIYrGMRL/jKG4poHkU3GjI+A4R0hc eLWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=NnvaTgjVRf+Ul9h+QAYt0U2edwb4gZZSYOvj7Zm2bgE=; b=m61YuNF0BIZ6Z7F45XkOAjpCSMMbwEw8jPJrPLI4A7G2j+jSB3No7BTsZ4WjwY7gVT ALs/bIPQi8ikgmB2irPm6aKHkWpgMhiQd0U7SQ0YV0KVkkr1rXaKpfM9BjtCChcJtUFG AiVMsEl/bax8hFsrlKiguswTKlvLi78/W9d1/18eFD9IsodaK7FBIiRrWxLnhPZDDHWC 5VIKpU3gGETK7MT4ZtHHlFo7hk2t/geyh5bT0Qm/4ZnGsQczNCi3cdCx4PRjhK3Rwsrm fZfDXiH9VYYaRqxwChF6pxhcd+Urbl5wDIf1vH6DCyu4wpV6aAxQXi+sWT9BuTvNHt9C 9wtQ== X-Gm-Message-State: ACgBeo0WVSiYjttM3ZW09Euabn7wRaC6qSrsjOxdX8QAIxBIhdDP16UZ +EANrKNP3EHpjHQbAKt3U39dtyXVPlB4MFnIe7yGO1YvLNg= X-Google-Smtp-Source: AA6agR6BPZzeq97G4i5bv/uPSIEtn7fH0FJHFn00FC1SU3G63G+K+TPYkyrWy4B8SgX2zT/jdkhCYYuoU1iLjKCAyqw= X-Received: by 2002:a05:6512:36cb:b0:494:a6b6:392e with SMTP id e11-20020a05651236cb00b00494a6b6392emr1743497lfs.39.1662151252250; Fri, 02 Sep 2022 13:40:52 -0700 (PDT) MIME-Version: 1.0 References: <20220902121755.GS7074@brightrain.aerifal.cx> In-Reply-To: From: enh Date: Fri, 2 Sep 2022 13:40:40 -0700 Message-ID: To: musl@lists.openwall.com Cc: Paul Zimmermann Content-Type: multipart/alternative; boundary="000000000000f4c4b505e7b7be74" Subject: Re: [musl] Re: integration of CORE-MATH routines into Musl? --000000000000f4c4b505e7b7be74 Content-Type: text/plain; charset="UTF-8" (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 wrote: > > > On Fri, Sep 2, 2022 at 5:18 AM Rich Felker 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 >> > --000000000000f4c4b505e7b7be74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(having now had time to skim the whole paper, i see you ar= e already comparing against llvm-libc [if not actually talking to them], an= d 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:<= br>


On Fri, Sep 2, 2022 at 5:18 AM Rich Felker <dalias@libc.org> wrot= e:
On Fri, Sep 0= 2, 2022 at 12:10:18PM +0200, Paul Zimmermann wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 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" vers= ions
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").
<= div>
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 http= s://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 h= ave had a heavy libm focus) that they probably don't have existing impl= ementations for a lot of stuff.

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

(oh, an= d thanks for picking a license that makes it much more likely that all the = libcs can use your work!)
=C2=A0
Rich
--000000000000f4c4b505e7b7be74--