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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to