From owner-freebsd-numerics@FreeBSD.ORG Wed May 29 11:04:54 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D32E175A for ; Wed, 29 May 2013 11:04:54 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5C6F33 for ; Wed, 29 May 2013 11:04:54 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 8C5461217FE; Wed, 29 May 2013 21:04:51 +1000 (EST) Date: Wed, 29 May 2013 21:04:50 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Stephen Montgomery-Smith Subject: Re: Patches for s_expl.c In-Reply-To: <51A5580C.9000607@missouri.edu> Message-ID: <20130529203350.V1268@besplex.bde.org> References: <20130528172242.GA51485@troutmask.apl.washington.edu> <20130529062437.V4648@besplex.bde.org> <20130528225310.GA53144@troutmask.apl.washington.edu> <51A53B1A.9040607@missouri.edu> <20130529000622.GA53899@troutmask.apl.washington.edu> <51A5580C.9000607@missouri.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=e4Ne0tV/ c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=SI7jfN9uMIUA:10 a=hyAGcHVSu_I8guswM6YA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: freebsd-numerics@FreeBSD.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 11:04:54 -0000 On Tue, 28 May 2013, Stephen Montgomery-Smith wrote: > On 05/28/2013 07:06 PM, Steve Kargl wrote: >> On Tue, May 28, 2013 at 06:17:46PM -0500, Stephen Montgomery-Smith wrote: >>> On 05/28/2013 05:53 PM, Steve Kargl wrote: >>> >>>> Given that I've merged, unmerged, remerged, disremerged, and >>>> undisremerged numerous diffs over the last 2+ years, I am not >>>> surprise that there are issues with the patches. I'm neither >>>> an expert in floating arithmetic nor style(9). If I understand >>>> half of what you write when you annotate one of your diffs, I >>>> feel lucky. Mail is not a very suitable medium for exchanging patches (but is better than a vcs that is not shared, or url). >>>> (Un)fortunately, I only have a few hours this week to work on >>>> expl/expm1l, and then I'll disappear again for a month or two >>>> (due to work and life). (Un)fortunately, theraven (under the >>>> ... It can take a long time to merger patches, especially when the turnaround time is months. I take more than a few hours a week on this when I'm working on it. >>> ... >>> Anyway, I think it is better for Steve to commit, and then for Bruce to >>> make changes later on. >> >> It's too late. In making some change since the last time I test >> has introduced a massive regression in the computation of expm1l. >> >> laptop-kargl:kargl[204] ./testl -n 5 -b >> prec: 64 >> For x in [-64.0000:-0.1659], 5M expm1l calls in 2.176513 seconds. >> For x in [-0.1659:0.1659], 5M expm1l calls in 0.415051 seconds. >> For x in [0.1659:11356.0000], 5M expm1l calls in 0.550342 seconds. >> >> Notice, the first interval is now 4 to 5 times slower than the >> other intervals. This was not the case with an older version >> of the code. I don't see this (only checked on i386 so far). expm1l on [-64.0000:-0.1659] takes about 55-59 cycles (22 nsec; 5M calls in 0.11 seconds) on freefall (Xeon i7(?)) when compiled by gcc. Other intervals are only a couple of cycles faster, except when compiled by clang expm1l takes only 44-45 cycles on [-0.1659:0.1659]. Large slowdowns may be caused by exceptions, but I tested the above range with overflow and underflow traps and didn't get any. > I think it is still better to commit. Then figure out where the > regression was later, when you have time. This is OK for transient efficiency regressions, not for accuracy ones. Bruce