cvs commit: src/lib/msun/src e_lgammaf_r.c

[Bruce Evans]

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.

Bruce