From owner-cvs-all@FreeBSD.ORG Tue Nov 29 08:27:12 2005 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4531B16A41F; Tue, 29 Nov 2005 08:27:12 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B58143D62; Tue, 29 Nov 2005 08:27:11 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id jAT8R9sA009812; Tue, 29 Nov 2005 19:27:09 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id jAT8R7K2010374; Tue, 29 Nov 2005 19:27:07 +1100 Date: Tue, 29 Nov 2005 19:27:06 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andrey Chernov In-Reply-To: <20051129012102.GA84108@nagual.pp.ru> Message-ID: <20051129184901.I34802@delplex.bde.org> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, Andre Oppermann , cvs-src@freebsd.org, cvs-all@freebsd.org, Bruce Evans , Steve Kargl Subject: Re: cvs commit: src/lib/msun/src e_lgammaf_r.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2005 08:27:12 -0000 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