From owner-freebsd-hackers Sun Apr 26 02:16:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA21304 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 02:14:07 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iq.org (proff@polysynaptic.iq.org [203.4.184.222]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA21118 for ; Sun, 26 Apr 1998 02:11:40 -0700 (PDT) (envelope-from proff@iq.org) Received: (qmail 10048 invoked by uid 110); 26 Apr 1998 09:11:33 -0000 To: marc@bowtie.nl cc: billm@suburbia.net Subject: Re: math library cc: freebsd-hackers@freebsd.org References: <199804240642.IAA21344@bowtie.nl> From: Julian Assange Date: 26 Apr 1998 19:11:32 +1000 In-Reply-To: Marc van Kempen's message of "Fri, 24 Apr 1998 08:42:52 +0200" Message-ID: Lines: 53 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@freebsd.org Precedence: bulk X-Loop: FreeBSD.ORG Marc van Kempen 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