From nobody Wed Sep 27 18:59:25 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RwmBG50MZz4tqpt for ; Wed, 27 Sep 2023 18:59:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RwmBG29Jhz3g1x for ; Wed, 27 Sep 2023 18:59:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 38RIxPG1039185; Wed, 27 Sep 2023 11:59:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 38RIxPVe039184; Wed, 27 Sep 2023 11:59:25 -0700 (PDT) (envelope-from sgk) Date: Wed, 27 Sep 2023 11:59:25 -0700 From: Steve Kargl To: Alexander Leidinger Cc: Paul Zimmermann , freebsd-hackers@freebsd.org Subject: Re: Accuracy of Mathematical Functions Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <1395eeabc6d404997f6a09a7b39d3da5@Leidinger.net> <8849166a6a2deb6ebc1f307d6e8a66a9@Leidinger.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8849166a6a2deb6ebc1f307d6e8a66a9@Leidinger.net> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Queue-Id: 4RwmBG29Jhz3g1x On Wed, Sep 27, 2023 at 10:32:18AM +0200, Alexander Leidinger wrote: > Am 2023-09-26 20:08, schrieb Steve Kargl: > > On Tue, Sep 26, 2023 at 03:26:16PM +0200, Alexander Leidinger wrote: > > > Am 2023-09-25 15:50, schrieb Paul Zimmermann: > > > > > > > We have updated our comparison: > > > > > > > > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > > > > > > > This new update includes for the first time the FreeBSD math library, > > > > whose accuracy is quite good, except: > > > > > > I wonder how those functions/libs you tested compare in terms of > > > speed... > > > It would allow to provide a hint to the question > > > "Which lib is the fastest and fulfills the needs in terms of > > > accuracy for > > > the intended use-case?" > > > > > > I agree that the best way to do this requires to run all libs on the > > > same > > > hardware and OS, which is not feasible in your approach. What may be > > > feasible is to compare the relative performance of those subsets, > > > which you > > > run on the same hardware. > > > > > > > Speed vs accuracy is always a trade-off. Consider > > Yes. > > [examples] > > The latter is more accurate, but its underlying algorithm > > uses summation-and-carry of the ascending series. This > > algorithm is sensitive to compiler options, so I haven't > > pushed it FreeBSD (, yet). > > A thought just crossed my mind... should we consider to provide two ABI > compatible math libs, one fast (and "acceptable accurate"... whatever this > means), and one accurate (and this one being the default to link against)? > Users then could use libmap.conf(5) to use the one according to their needs. This is certainly possible, but implementing it across all supported architecture might be problematic. For float and double, FreeBSD may be able to leverage CoreMath that Paul and his colleagues at Inria are developing (https://core-math.gitlabpages.inria.fr/). I have not tried to build and test it on FreeBSD, yet. Unfortunately, compiler options like -ffast-math and -Ofast tend to lead users down a potentially hazardous path. Everyone wants their codes to run "fast". They just don't know that "fast" might also mean wrong. -- Steve