Date: 26 Apr 1998 19:11:32 +1000 From: Julian Assange <proff@iq.org> To: marc@bowtie.nl Cc: freebsd-hackers@freebsd.org Subject: Re: math library Message-ID: <wx67jx2bi3.fsf@polysynaptic.iq.org> In-Reply-To: Marc van Kempen's message of "Fri, 24 Apr 1998 08:42:52 %2B0200" References: <199804240642.IAA21344@bowtie.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Marc van Kempen <marc@bowtie.nl> writes: > Hi Julian, > > I hope you don't mind me asking this question, but I found an > elaborate article of yours about optimal math performance, > posted to freebsd-hackers. > > What is the current status on getting optimal math performance? > Did you manage to get the same performance as Linux has? > > In a simple test program I still see a difference of about 9%. > (in favor of Linux :-() > > Regards, > Marc. 9% - that's nothing :) I was seeing close to 100% difference. FreeBSD has two maths libraries. The original CSRG library, and libmsun (/usr/src/msun). The latter has become the default FreeBSD maths library (although, I'm not sure as of when). 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. 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. If you have a very tight inner loop and you *understand the constraints of the 387*, you are probably best off re-writing the loop in 387 code, or breaking the inner loop out into a .c file of its own and compiling it with --fast-math (and possibly --fancy-math-387). This essentially inlines a number of libm functions at the expensive of having them behave like a 3 year old child with an abacus). billm@suburbia.net wrote the linux (used elsewhere too) floating point emulator code (note emulator, not libm). He may have something to say on this matter. Cheers, Julian. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?wx67jx2bi3.fsf>