From: Patrick McGehearty <patrick.mcgehearty@oracle.com>
To: libc-alpha@sourceware.org
Subject: Re: [PATCH] v11 Improves __ieee754_exp() performance by greater than 5x on sparc/x86.
Date: Wed, 7 Feb 2018 13:19:50 -0600 [thread overview]
Message-ID: <fd33ecf5-9b16-7087-f268-1f2f6ab7ff58@oracle.com> (raw)
In-Reply-To: <361bac88-5538-227f-b6dc-76416178192c@arm.com>
On 2/2/2018 8:40 AM, Szabolcs Nagy wrote:
> On 29/01/18 21:44, Patrick McGehearty wrote:
>> New with this version:
>> Adds updates sparc and x86_64 libm-test-ulps files (1 ulp for
>> various exp tests). Rewrite of full comment to reflect current
>> state of patch.
>>
>> Summary of patch rationale
>>
>> These changes will be active for all platforms that don't provide
>> their own exp() routines. They will also be active for ieee754
>> versions of ccos, ccosh, cosh, csin, csinh, sinh, exp10, gamma, and
>> erf.
>>
>> Typical performance gains are 2x on Sparc s7 and 5x on x86_64.
>> The former code included a slow path to assure no 1 ulp errors
>> that could be 50-200 times slower than the normal path.
>> Informal testing suggests perhaps 1 in 200 values might invoke
>> the slow path.
>>
>> Using the glibc_perf tests:
>> sparc (nsec) x86 (nsec)
>> old new old new
>> max 18180 936 4863 275
>> min 399 96 15 15
>> mean 5499 419 1336 24
>>
>
> i tested this patch on aarch64 against the current code
> with the slow path removed and the later was about 10%
> faster on both my throughput and latency benchmarks.
> (i also removed the rounding mode settings in both cases
> as that can be avoided at least on aarch64)
>
Removing the rounding mode settings certainly makes a big
difference in performance. When I started, my base code did
not include the rounding mode changes. Unfortunately,
that also generated many more test failures in the non-round-to-nearest
settings, including failures in other ieee754 functions that used
ieee754_exp(). Most platforms do not have a way to avoid the
rounding mode settings, making that option unavailable
for most users of the generic IEEE754 code.
Has there been a serious discussion in the past of to what degree
of accuracy glibc/libm should support other rounding modes than
round-to-nearest? If a concensus decision were made that
other rounding modes were allowed slightly greater ulp diffs,
we could remove all the rounding mode checks and get
faster code. Failing that concensus, I don't see how we
can bypass the rounding mode checks for the generic code.
> so i suggest just removing the slow path first, which
> should have good enough error rate and similar performance.
I'll look into comparing removing the slow path on Sparc and
x86, including running my own "10 million values" test to
get a sense of how frequently the slow path is triggered
and what the largest relative error that test observes.
I'll also run timing tests.
May be a little while before I have something to report.
> i did some testing and i think it's possible to do the
> common case >30% faster with similar table size and around
> 0.501 ulp error, with a slower path for values close to
> overflow/underflow (at least on aarch64, which has
> convert-to-nearest-int instruction that does not depend on
> rounding mode, i'll see if it can be done in a generic way)
- patrick
next prev parent reply other threads:[~2018-02-07 19:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-29 21:44 [PATCH] v11 Improves __ieee754_exp() performance by greater than 5x on sparc/x86 Patrick McGehearty
2018-02-02 14:40 ` Szabolcs Nagy
2018-02-02 15:33 ` Joseph Myers
2018-02-02 16:35 ` Szabolcs Nagy
2018-02-07 19:19 ` Patrick McGehearty [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-02-08 11:40 Wilco Dijkstra
2018-02-14 1:18 ` Patrick McGehearty
2018-02-14 16:41 ` Joseph Myers
2018-02-14 20:05 ` Szabolcs Nagy
2018-02-22 19:22 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fd33ecf5-9b16-7087-f268-1f2f6ab7ff58@oracle.com \
--to=patrick.mcgehearty@oracle.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).