Patches for s_expl.c
brde at optusnet.com.au
Wed May 29 11:04:54 UTC 2013
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 ./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.
More information about the freebsd-numerics