This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] How to add vector math functions to Glibc
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>
- Cc: Christoph Lauter <christoph dot lauter at lip6 dot fr>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 10 Oct 2014 15:23:29 +0000
- Subject: Re: [RFC] How to add vector math functions to Glibc
- Authentication-results: sourceware.org; auth=none
- References: <CAMXFM3tjquzniXP1weqxSVFJyhXqsf2PHuyrrrmqp7K0ZzORqA at mail dot gmail dot com> <54246CB5 dot 7020908 at redhat dot com> <CAMe9rOoLmJ2jHWmERoB0M83WNKovJOgh0--Kquw9O86A1tPU0g at mail dot gmail dot com> <5424733D dot 6010305 at redhat dot com> <CAMe9rOpacze055qyBFzz3M-b-GNtXCqZzMmkScBL9a94zVj28g at mail dot gmail dot com> <54247FAB dot 6050002 at redhat dot com> <CAMXFM3v8narOLMHC5U=fvyTFWV6s4ZACN-UrAC4fAcUs9SOFfA at mail dot gmail dot com> <54257507 dot 9070508 at redhat dot com> <CAMXFM3vOLspQtHxgJfD_Emht480w2RMbiwnEH6A_LhoS-JZFag at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409301620020 dot 15186 at digraph dot polyomino dot org dot uk> <542AF92E dot 8090708 at lip6 dot fr> <Pine dot LNX dot 4 dot 64 dot 1409302003410 dot 12188 at digraph dot polyomino dot org dot uk> <CAMXFM3tuM_p6Acp4hzoQ2xzR=4BZqtw8NbezqY6h8V4Xx=5hUA at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1410021411420 dot 24886 at digraph dot polyomino dot org dot uk> <CAMXFM3uPiuJvSpgmt+8d0B1qh3QSA=TVx0ZExfojDVHzrscL8A at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1410091724031 dot 23641 at digraph dot polyomino dot org dot uk> <CAMXFM3tdCun+Pk7x6joO1pqngjtJu1_ff=OTLKWwUHYKpE_ZKg at mail dot gmail dot com>
On Fri, 10 Oct 2014, Andrew Senkevich wrote:
> Table values were obtained mostly through many years of research and
> experimental work, were part of old enough codes and we have no
> detailed comments there either. So our proposal is to stay at current
> level of comments as these codes proved their correctness and
> effectiveness through many years of intensive usage in math
> applications in such institutions as CERN, LLNL, etc.
So maybe you aren't sure if e.g. the values are the result of rounding to
floating-point values a minimax polynomial approximation over the reals,
or if they are a minimax polynomial approximation over floating-point
values, or if they are some other kind of polynomial approximation. But
you can still make the comments say how they are used.
E.g. in <https://sourceware.org/ml/libc-alpha/2014-09/msg00680.html> you
have a comment saying "Poly = C3+R2*(C4+R2*(C5+R2*(C6+R2*C7)))". Now if
you repeated that in the table, with the additional information of *what
this is a polynomial approximation for* ((cos(x)-1)/x^2? (sin(x)-x)/x^3?),
and *what interval the approximation is used on*, you've provided enough
information there for someone who wants to recompute values optimized in a
particular way to do so.
This goes together with a few other things to make the table more
readable:
* If the values are 64-bit doubles, representing them with .quad rather
than as pairs of .long would make things clearer.
* Where you have vectors repeating the same value eight times, using .rept
/ .endr would make this obvious and make the source code smaller.
* Combining this with my previous suggestion in
<https://sourceware.org/ml/libc-alpha/2014-10/msg00040.html> regarding how
to make the offsets of table entries explicit, you could do:
/* Define a vector of eight copies of VALUE, whose offset from the
start of the table __gnu_svml_dcos_data must be OFFSET. */
.macro double_vector offset value
.if .-__gnu_svml_dcos_data != \offset
.err
.endif
.rept 8
.quad \value
.endr
.endm
and then define the values as
double_vector OFFSET_LABSMASK 0x7fffffffffffffff
double_vector OFFSET_LRANGEVAL 0x4160000000000000
etc. - you still need the comments explaining what each of the values is /
how it is used, and still need the function implementation to use those
OFFSET_* macros for offsets rather than hardcoding their values, but I
think macro calls like this are about as clear as you can get for actually
putting the constants into the table in a .S file.
> > And see my previous point about defining macros for the offsets in
> > this table in such a way that build errors will occur if the macro values
> > are wrong.
>
> We will follow-up, though these sources will not change often and they
> have no influence on usage value.
Software is for people to read and modify, not just for computers to
execute. It's inherent to Free Software that you don't know who might be
using or modifying it and in what way - so enough information should be
provided in the source code that someone other than the original author
can plausibly make local changes (e.g. changing the algorithm in a
particular case only).
--
Joseph S. Myers
joseph@codesourcery.com