cvs commit: src/lib/msun/src e_lgammaf_r.c
bde at zeta.org.au
Tue Nov 29 08:27:12 GMT 2005
On Tue, 29 Nov 2005, Andrey Chernov wrote:
> On Tue, Nov 29, 2005 at 11:49:13AM +1100, Bruce Evans wrote:
>> I don't like writing papers, and rarely read them these days.
> Not writting the paper about your libm changes will increase chances your
> changes will be simple lost at some step. Possible scenario: 1) One of
They won't be lost, becaue they are in cvs :-).
> other *BSD totally rewrite its libm using some outside source, many new
> latest standard conforming functions added. 2) Although it is not so good
> in many aspects as yours, users will demand switching, since knows not at
> all about your goal/efforts/ulps/etc. 3) Someday someone switch from
> obsoleted N-years old etc. libm to be compatible with the rest of *BSD.
Then the new library might be better, or someone doesn't care about its
performance or accuracy, and they won't notice the difference.
I might care more if I get around to fixing and optimizing more than a few
functions in libm.
> BTW, do you optimize Athlon only calculation? What about Intel EM64?
I only have Athlons and some older machines handy. I've never used
any sort of P4. There are still none in the FreeBSD cluster. But the
optimizations aren't very Athlon-specific. Even the ones for parallelism
are fairly generic for machines that have parallelism. I had to add
1 or 2 instructions to increase parallelism, and these have a small
negative effect on K6's, but it is relatively small since K6's take
more cycles (about twice as many) anyway. I haven't got back to
checking the effect on machines in the FreeBSD cluster.
More information about the cvs-all