From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: "patrick.mcgehearty@oracle.com" <patrick.mcgehearty@oracle.com>
Cc: "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>, nd <nd@arm.com>
Subject: Re: [PATCH] improves exp() and expf() performance on Sparc.
Date: Mon, 11 Sep 2017 18:50:00 -0000 [thread overview]
Message-ID: <DB6PR0801MB2053C6953E919EB64982AACC83680@DB6PR0801MB2053.eurprd08.prod.outlook.com> (raw)
Patrick wrote:
> When the differences are this large and the new max is faster than the
> old min, I don't see a need in doing further performance testing.
Agreed, the new version is significantly faster that there is really no contest.
What isn't obvious is how much penalty the very large tables have.
So while I think further improvements are feasible, that shouldn't hold up
adding it to generic code.
> Moving on to expf, the comparison for individual values shows an
> improvement in the range of 15x. benchtests does not measure expf().
We do now have an expf benchmark, see:
https://sourceware.org/ml/libc-alpha/2017-08/msg01126.html
> The Szabolcs code appears to provide similar benefits. There were
> some discussion of accuracy and of possible changes to the algorithm,
> perhaps by using a larger table. The Sparc code uses a larger table and
> thus may be more accurate for some ulp sensitive values. Or it may be
> a non-issue since both algorithms are using double precision for
> computation.
Part of the discussion was to further improve performance by reducing the
polynomial and increasing the table for a small increase in ULP error (still well
below 1ULP). Another aspect discussed was what one should do for non-nearest
rounding modes - I don't believe we should expect math functions to be perfect in
those modes if that means complicating or even slowing down round-to-nearest
(while this is no longer a critical performance bug on most targets after I fixed the
fenv implementation, it still causes significant slowdowns in many math functions).
Talking about tables, the Sparc version uses very large tables which may be
why it didn't do as well in the expf benchmark or running wrf_s (1.9% slower).
This appears to be inherent to the algorithm used - while it seems feasible to
almost halve the tables, it would mean lower throughput and increased latency.
> Wilco Dijkstra compared the new Sparc code to Szabolcs code on aarch64
> and found Szabolcs code to be 10% faster on aarch64. That result is
> close enough to justify testing on Sparc. In addition to a performance
> comparison, we'd want to compare accuracy to see if there are notable
> differences.
Accuracy is unlikely an issue given both are already far more accurate than
strictly necessary. For testing I would suggest running the expf trace as well as
wrf_s, both built and ifunced in the same way (as Joseph already suggested).
Wilco
next reply other threads:[~2017-09-11 18:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-11 18:50 Wilco Dijkstra [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-09-01 22:59 Patrick McGehearty
2017-09-01 23:14 ` Joseph Myers
2017-09-06 20:34 ` Patrick McGehearty
2017-09-06 21:01 ` Joseph Myers
2017-09-07 20:42 ` Patrick McGehearty
2017-09-07 21:05 ` Joseph Myers
2017-09-07 23:53 ` Patrick McGehearty
2017-09-04 11:43 ` Szabolcs Nagy
2017-09-06 20:31 ` Patrick McGehearty
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DB6PR0801MB2053C6953E919EB64982AACC83680@DB6PR0801MB2053.eurprd08.prod.outlook.com \
--to=wilco.dijkstra@arm.com \
--cc=libc-alpha@sourceware.org \
--cc=nd@arm.com \
--cc=patrick.mcgehearty@oracle.com \
/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).