From owner-freebsd-hackers Sun Apr 26 22:58:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA21170 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 22:58:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from emu.melbpc.org.au (emu.melbpc.org.au [203.12.152.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA21154 for ; Sun, 26 Apr 1998 22:58:05 -0700 (PDT) (envelope-from billm@melbpc.org.au) Received: from melbpc.org.au (root@dingo16.melbpc.org.au [203.12.157.16]) by emu.melbpc.org.au (8.8.7/8.8.6) with ESMTP id PAA29953; Mon, 27 Apr 1998 15:57:44 +1000 (EST) Received: (from melbpc@localhost) by melbpc.org.au (8.8.8/8.8.8/Debian/GNU) id NAA01120; Mon, 27 Apr 1998 13:09:34 +1000 From: Bill Metzenthen Message-Id: <199804270309.NAA01120@melbpc.org.au> Subject: Re: math library To: proff@iq.org, marc@bowtie.nl, freebsd-hackers@FreeBSD.ORG Date: Mon, 27 Apr 1998 13:09:33 +1000 (EST) Reply-To: billm@melbpc.org.au X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Assange wrote: > libmsun has been extensively tested to confirm correct calculation in > a variety of pathological circumstances. The 9% difference you are seeing > is probably related to this. I would NOT trust the linux libm for ANY > scientific calculation. Linux is moving to glibc. I feel sure that the people working on glibc would appreciate any contribution to improving their libm. > I ported the linux libm to FreeBSD because of the 100% difference in > speed I was seeing during the rendering phase of a scientific > visualisation project I was working on. Rendering is not a process > especially prone to error amplification or pathological conditions, > yet I was seeing a clear difference in results between the two > libraries - so much so that I was unable to use Linux and FreeBSD > boxes together in a distributed rendering environment. Often results > like this can be attributed to machines with different fp word-lengths, > or random number generators, (assuming an iterative process), but both > the linux and FreeBSD machines were 586's, running my own PRN > generation code. My observation of messages appearing in the newsgroups is that the reasons for such differences can often be traced back to the precision setting which is used for the x87 FPU on Linux. The commonly used start-up code on Linux currently (and has for some time) sets the FPU to 64 bit precision. Some other x86 operating systems use 53 bits. This will lead to different results -- independent of the quality of the libm implementation. Whether you get "better" results with one precision setting or the other depends upon: (1) what you define as "better" -- pseudo-religious arguments can enter here, and (2) the particular code and data which you try. I once issued a challenge to the 53 bit school to show that their approach gave "better" results for most computations, but I saw not one attempt at an answer. To be fair, few people probably saw my message. It is possible (under C, etc) for a programmer to set the precision (e.g. to 53 bits) for his own programs. The code which I have on my web pages on suburbia.net makes this easy to do for C on Linux (not that it is difficult to do anyway). Cheers, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message