Date: Wed, 29 May 2013 21:04:50 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Stephen Montgomery-Smith <stephen@missouri.edu> Cc: freebsd-numerics@FreeBSD.org Subject: Re: Patches for s_expl.c Message-ID: <20130529203350.V1268@besplex.bde.org> In-Reply-To: <51A5580C.9000607@missouri.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130529203350.V1268>