From owner-freebsd-hackers@freebsd.org Mon May 28 21:09:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1BD0EF0C66 for ; Mon, 28 May 2018 21:09:09 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C5B2879FE; Mon, 28 May 2018 21:09:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w4SL9749077542 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 May 2018 14:09:07 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w4SL97Lf077541; Mon, 28 May 2018 14:09:07 -0700 (PDT) (envelope-from sgk) Date: Mon, 28 May 2018 14:09:07 -0700 From: Steve Kargl To: Adhemerval Zanella Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, emaste@freebsd.org Subject: Re: Code with apache-2 on /usr/src Message-ID: <20180528210907.GA77475@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180528190444.GE3789@kib.kiev.ua> <20180528193506.GA76705@troutmask.apl.washington.edu> <1c09023e-9bf5-d23a-dedc-1c4f4706bbde@linaro.org> <20180528202117.GA77184@troutmask.apl.washington.edu> <72101038-9e89-3f23-ab67-1c97b2a89803@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72101038-9e89-3f23-ab67-1c97b2a89803@linaro.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 21:09:09 -0000 On Mon, May 28, 2018 at 05:47:09PM -0300, Adhemerval Zanella wrote: > > On 28/05/2018 17:21, Steve Kargl wrote: > > On Mon, May 28, 2018 at 04:47:21PM -0300, Adhemerval Zanella wrote: > >> > >> On 28/05/2018 16:35, Steve Kargl wrote: > >>> > >>> The above URL seems to contain only single precision code, > >>> e.g., sinf(x). What benefit does this code have over the > >>> current implementations of these functions? Doesn't ARM > >>> support at least a double precision type? > >> > >> Yes, the github repository only contains single precision implementation and > >> at the moment my idea is to contribute with expf, powf, logf, expf2, and > >> log2f. All these implementation are faster than current FreeBSD ones (I > >> plan to dig into with more details in patch proposal). > >> > >>> Why have an > >>> algorithms for single precision that differ from the > >>> algorithms at higher precision? > >>> > >> > >> Are you asking why use an implementation for single precision and another > >> for double and/or long double (if the case) or why to use a different > >> mathematical method for each one? > > > > Your question don't make any sense to me. My question means that > > if you only have ARM-specific single precision routines, then the > > underlying algorithms for those SP routines will by definition be > > different than the double and long double precision routines. One > > can do for example 'diff -u s_sinf.c s_sin.c' while debugging. > > The difference that one sees are usually restricted to different > > numerical literal constants and the number of terms in polynomial > > approximations. > > > > Sorry if I was not clear, I did not fully get your question. Also for avoid > further misconceptions, this new implementation is *not* ARM-specific, but > rather a different one which is faster than current for FreeBSD (in fact > faster on x86 as well). > > And is having a different algorithm for single and double prevision > a blocker for a future patch proposal? No. Given the comment in sinf.c that max ULP is 0.56072, I do note that the current implementation of sinf in lib/msun is more accurate (for interesting values of x). I also looked at single/s_sincosf.c. It is rather dubious to have 80+ digit numerical constants for a float, which at most has 9 relevant digits. -- Steve