Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Nov 2005 19:27:06 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Andrey Chernov <ache@freebsd.org>
Cc:        src-committers@freebsd.org, Andre Oppermann <andre@freebsd.org>, cvs-src@freebsd.org, cvs-all@freebsd.org, Bruce Evans <bde@freebsd.org>, Steve Kargl <sgk@troutmask.apl.washington.edu>
Subject:   Re: cvs commit: src/lib/msun/src e_lgammaf_r.c
Message-ID:  <20051129184901.I34802@delplex.bde.org>
In-Reply-To: <20051129012102.GA84108@nagual.pp.ru>
References:  <200511280832.jAS8WGvs059057@repoman.freebsd.org> <438AD8FB.A8B96AB6@freebsd.org> <20051128172718.GA59929@troutmask.apl.washington.edu> <20051129110058.T33820@delplex.bde.org> <20051129012102.GA84108@nagual.pp.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051129184901.I34802>