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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16820 invoked from network); 11 Aug 2021 08:23:22 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 11 Aug 2021 08:23:22 -0000 Received: (qmail 15528 invoked by uid 550); 11 Aug 2021 08:23:19 -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 15510 invoked from network); 11 Aug 2021 08:23:18 -0000 Date: Wed, 11 Aug 2021 10:23:06 +0200 From: Szabolcs Nagy To: Stefan Kanthak Cc: musl@lists.openwall.com Message-ID: <20210811082306.GC37904@port70.net> Mail-Followup-To: Stefan Kanthak , musl@lists.openwall.com References: <0C6AAAD55DA44C6189B2FF4F5FB2C3E7@H270> <20210810213455.GB37904@port70.net> <5C60D05C95724A36B3DB9942D06CFE5F@H270> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C60D05C95724A36B3DB9942D06CFE5F@H270> Subject: Re: [musl] [PATCH] Properly simplified nextafter() * Stefan Kanthak [2021-08-11 00:53:37 +0200]: > Szabolcs Nagy wrote: > > it's target dependent if float compares are fast or not. > > It's also target dependent whether the floating-point registers > can be accessed by integer instructions, or need to be copied: > some win, some loose! as Rich said, fp values are moved to int regs no matter what, but float cmp can be avoided. > Just let the compiler/optimizer do its job! compilers cannot do this kind of refactoring. (if they could, your change would not be needed) > > (the i386 machine where i originally tested this preferred int > > cmp and float cmp was very slow in the subnormal range and > > iirc it also raises the non-standard input denormal exception, > > which is fine i guess. > > This exception resp. the (sticky) flag is explicitly raised/set > in the part following the patch. that is raised if the result is subnormal, but not if y is. but we don't care about x86 specific denormal exception only about standard underflow, so fcmp is fine. > > of course soft float abis much prefer int cmp so your code is > > likely much slower and bigger there). > > 0. Doesn't musl provide target specific routines for targets with > soft FP? no. > > 1. If not: the compiler knows the target ABI and SHOULD generate > the proper integer comparisions there. it can't, you get extern calls with register spills etc. > > but i'm not against the change, it is likely better on modern > > machines. did you try to benchmark it? or check the code size? > > I STILL don't run a system supported by musl. then how did you test it? > The code is of course smaller ... but not as small and fast as a > proper i386 or AMD64 assembly implementation ... which I can > post upon request. if this is an optimization patch then give us numbers (and add them to the commit message). at least you can look up instruction timings if you don't want to benchmark: e.g. aarch64 cortex-a72 optimization guide says fcmp: 3 latency, 1 throughput cmp: 1 latency, 2 throughput i.e. 1 fcmp ~ 6 cmp in the ideal case. some of the removed instructions can execute in parallel so i'd expect the original code to be faster on a cortex a72 for most inputs. but on many other cores it will be faster or you can optimize for code size or as Rich said it makes sense to have consistent algorithm with nexttoward (which does not use int representation to avoid dealing with many different long double formats). but you have to explain why you are doing a change.