From: Joseph Myers <joseph@codesourcery.com>
To: Patrick McGehearty <patrick.mcgehearty@oracle.com>
Cc: <libc-alpha@sourceware.org>
Subject: Re: [PATCH] Improves __ieee754_exp() performance by greater than 5x on sparc/x86.
Date: Thu, 19 Oct 2017 22:48:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.20.1710192235050.9397@digraph.polyomino.org.uk> (raw)
In-Reply-To: <6d6104ad-b846-68b3-8f87-3216d1e52412@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 4004 bytes --]
On Thu, 19 Oct 2017, Patrick McGehearty wrote:
> For the copyright issue, would it be appropriate to move the
> previous copyright notice to right before __exp1?
> I'm reluctant to move __exp1 as that might also require changes
> to Makefiles which are not currently required.
There should be exactly one copyright notice with a given copyright holder
in a given source file, so only one set of dates (2001-2017) given. The
"IBM Accurate Mathematical Library" comment might be updated to describe
what parts of the file come from where.
> For slowexp, I have some reservations that removing slowexp.o
> might cause older object modules to break due to the missing
> reference. I know they should not be directly referencing
> an internal function, but still...
> Anyway, I can't find any other direct usage of __slowexp.
> I will remove all references to __slowexp and see
> if anything breaks to show I missed a reference.
>
> I find the following files have references, including some more
> files to be removed.
This list seems to be missing (at least)
sysdeps/powerpc/power4/fpu/Makefile (CPPFLAGS-slowexp.c setting).
> benchtests/strcol1-inputs/filelist#C and filelist#en_US.UTF-8
> have references to slowexp*.c
> I'm supposing those should also be removed.
I know some people do edit this benchmark input when removing files, but I
think that's inappropriate; it's just a test input that happens to be
based on a list of files in some version of glibc, there is no need for it
to correspond to current glibc, and in the interests of comparability of
benchmark results it would be best for it never to change.
> I've been uncomfortable with hex floats approach
> as it only works for ieee754 representations
> that use base 2. I admit that is most current machines.
This file is in a directory for such a binary format, and it's tuned for
that particular format (regarding polynomial size chosen, etc.). Any code
written for decimal formats would naturally use decimal constants, but in
code written for binary formats, hex constants are appropriate for such
precomputed constants to make clear exactly what value / representation is
intended. (And in the 0x1p-54 case, it makes the code a lot more readable
to put that in hex.)
> Underneath the definitions of SET_RESTORE_ROUND, it ultimately relies
> on __fegetround() and __fesetround(). The extra cost for
> SET_RESTORE_ROUND is that it requires a flag to always be set (mode
> changed or did not change). A short time the flag must tested to
> determine if the rounding mode needs to be restored. If the compiler
> puts that flag on the stack or in memory, the reading of a value that
> was just written to cache triggers a "Read after Write" HW hazard,
> causing a typical delay of 30-40 cycles. Avoiding the test also
> avoids a possible mis-predicted branch. For M7 and earlier, Sparc
> branch prediction is not ideal and mis-prediction is expensive. The
> code I provided avoids the need to set the flag or test it by
> duplicating small segments of code for each case.
Well, there are lots of lower-level interfaces such as libc_fesetround
that could be used if appropriate. Maybe additional such interfaces need
to be added to support such cases of duplicating code. It would seem
natural to start with the existing interfaces (SET_RESTORE_ROUND), with a
view to a followup possibly then adding further optimizations, just as the
expf changes started by adding something wrapped by the existing wrapper,
then arranged to avoid a wrapper in subsequent patches in the series.
> > Guaranteeing "inexact" is not part of the goals for most libm functions,
> > so I expect you can remove that term.
> The "inexact" test was required to pass the (make check) math lib tests.
You'll need to explain more. For functions which are not fully defined by
a binding to IEEE operations, both spurious and missing "inexact" should
be allowed by the testsuite.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2017-10-19 22:48 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 16:56 Patrick McGehearty
2017-10-18 17:22 ` Joseph Myers
2017-10-18 23:22 ` Joseph Myers
2017-10-19 22:31 ` Patrick McGehearty
2017-10-19 22:48 ` Joseph Myers [this message]
2017-10-20 15:04 ` Patrick McGehearty
2017-10-21 5:23 ` Patrick McGehearty
2017-10-23 12:47 ` Joseph Myers
2017-10-23 19:58 ` Patrick McGehearty
2017-10-23 21:31 ` Joseph Myers
2017-10-20 11:41 ` Szabolcs Nagy
2017-10-20 14:56 ` Patrick McGehearty
2017-10-20 16:10 ` Joseph Myers
2017-10-23 12:25 ` Siddhesh Poyarekar
2017-10-23 15:58 ` Joseph Myers
2017-10-20 13:38 Wilco Dijkstra
2017-10-20 14:58 ` Patrick McGehearty
2017-10-26 16:44 Patrick McGehearty
2017-10-26 17:20 ` Joseph Myers
2017-10-26 17:25 ` Joseph Myers
2017-10-26 18:30 ` Patrick McGehearty
2017-10-26 19:44 ` Joseph Myers
2017-10-26 22:53 Patrick McGehearty
2017-11-01 0:26 ` Joseph Myers
2017-11-07 4:25 Patrick McGehearty
2017-11-16 17:52 ` Patrick McGehearty
2017-11-16 18:27 ` Carlos O'Donell
2017-11-16 18:31 ` Joseph Myers
2017-11-23 21:19 ` Joseph Myers
2017-12-01 0:47 ` Patrick McGehearty
2017-12-01 0:51 Patrick McGehearty
2017-12-01 0:56 ` Joseph Myers
2017-12-04 21:53 Patrick McGehearty
2017-12-05 23:20 ` Joseph Myers
2017-12-08 23:08 Patrick McGehearty
2017-12-11 8:14 ` Siddhesh Poyarekar
2017-12-11 17:04 ` Patrick McGehearty
2017-12-11 17:53 ` Siddhesh Poyarekar
2017-12-14 1:28 ` Joseph Myers
2017-12-18 20:11 ` Patrick McGehearty
2017-12-29 23:42 Patrick McGehearty
2018-01-01 1:36 ` Joseph Myers
2018-01-01 16:31 ` Patrick McGehearty
2018-01-01 16:41 ` Joseph Myers
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=alpine.DEB.2.20.1710192235050.9397@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--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).