float versions of libm-routines?

float versions of libm-routines?

Post by Kai Arsti » Fri, 16 Aug 1996 04:00:00



I'm currently writing scientific computing programs in Linux
environment.  As my code makes heavy use of routines in math-library I
have been interested whether there exists float-defined versions of
normally double-defined mathematical routines for Linux for occasions
where accuracy is not so important.

I have tried to find such a library from here and there, but found only
a version for FreeBSD, which was not trivial to compile for Linux.
Is there a big difference in the efficiency of between float and double
operations in Intel x86 (especially Pentium Pro) processors?

****************************************************************************
Kai Arstila                                 phone: +358-0-191 40009
Accelerator Laboratory, Univ. of Helsinki   fax:   +358-0-191 40042

FI-00014 Helsinki, Finland                  
****************************************************************************

 
 
 

float versions of libm-routines?

Post by Neil Moor » Fri, 16 Aug 1996 04:00:00



> I'm currently writing scientific computing programs in Linux
> environment.  As my code makes heavy use of routines in math-library I
> have been interested whether there exists float-defined versions of
> normally double-defined mathematical routines for Linux for occasions
> where accuracy is not so important.

> I have tried to find such a library from here and there, but found only
> a version for FreeBSD, which was not trivial to compile for Linux.
> Is there a big difference in the efficiency of between float and double
> operations in Intel x86 (especially Pentium Pro) processors?

I may be wrong (I usually am), but I think all floating point numbers are
converted to an 80-bit format in x86 FPUs. If that is the case, the main
difference would be storage space rather than speed. I think float vs.
double would only matter for some emulators (I'm not even sure about that).

--
-Neil Moore

 
 
 

float versions of libm-routines?

Post by Ulrich Drepp » Sat, 17 Aug 1996 04:00:00



> I'm currently writing scientific computing programs in Linux
> environment.  As my code makes heavy use of routines in math-library I
> have been interested whether there exists float-defined versions of
> normally double-defined mathematical routines for Linux for occasions
> where accuracy is not so important.

As part of libm-5.  But probably earlier.  The versions you saw on
FreeBSD are of higher quality and are part of GNU libc.

Quote:> I have tried to find such a library from here and there, but found only
> a version for FreeBSD, which was not trivial to compile for Linux.
> Is there a big difference in the efficiency of between float and double
> operations in Intel x86 (especially Pentium Pro) processors?

Shouldn't make any difference.  In libc-5 ASCII<->float conversion is
a bit faster and some of the more complex math operations in libm
might be a tiny bit faster, but as long as the FPU is used it makes no
difference.  it always uses long double internally.
--
-- Uli

Ulrich Drepper \    ,--------------------'   \  76149 Karlsruhe/Germany

 
 
 

float versions of libm-routines?

Post by James Youngm » Sat, 17 Aug 1996 04:00:00




Quote:>I may be wrong (I usually am), but I think all floating point numbers are
>converted to an 80-bit format in x86 FPUs. If that is the case, the main
>difference would be storage space rather than speed. I think float vs.
>double would only matter for some emulators (I'm not even sure about that).

This is true only up to a certain point.  Knowing that the result of a
computation is only a float allows one to terminate many caculations early,
before the full precision of a double has been achieved.  This is true of
almost all iterative numerical algorightms.  Also some functions can be
calculated with a simpler and quicker-to-compute approximation.


this out to me.  Followups directed to comp.lang.c.

--
James Youngman                               VG Gas Analysis Systems
The trouble with the rat-race is, even if you win, you're still a rat.

 
 
 

float versions of libm-routines?

Post by Andreas Dilg » Sun, 18 Aug 1996 04:00:00




Quote:>I may be wrong (I usually am), but I think all floating point numbers are
>converted to an 80-bit format in x86 FPUs. If that is the case, the main
>difference would be storage space rather than speed. I think float vs.
>double would only matter for some emulators (I'm not even sure about that).

Actually, I remember reading some time ago that with most new processors
(ie 32-bit systems with FPUs) it is faster to use doubles than floats
because of the float <-> double conversion that happens each time you
use an intermediate variable as a result of always using doubles in the
FPU to do FP calculations.  The article recommended that floats only
be used when you are using large arrays of values and memory usage is
an issue, and to use doubles for intermediate calculations to avoid
float <-> double conversion as much as possible.  However, YMMV.

Cheers, Andreas.
--
Andreas Dilger   University of Calgary  \"If a man ate a pound of pasta and
(403) 220-8792   Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \   cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/       hungry?" -- Dogbert

 
 
 

float versions of libm-routines?

Post by James Youngm » Tue, 20 Aug 1996 04:00:00





>>I may be wrong (I usually am), but I think all floating point numbers are
>>converted to an 80-bit format in x86 FPUs. If that is the case, the main
>>difference would be storage space rather than speed. I think float vs.
>>double would only matter for some emulators (I'm not even sure about that).

>Actually, I remember reading some time ago that with most new processors
>(ie 32-bit systems with FPUs) it is faster to use doubles than floats
>because of the float <-> double conversion that happens each time you
>use an intermediate variable as a result of always using doubles in the
>FPU to do FP calculations.  The article recommended that floats only
>be used when you are using large arrays of values and memory usage is
>an issue, and to use doubles for intermediate calculations to avoid
>float <-> double conversion as much as possible.  However, YMMV.

Perhaps the article you read was a little simplistic.  Many of the
routines in libm calculate functions like sin() and j0() by series
expansion or other iterative methods.  They do this by using +-/*,
but if they know that the result is going to be converted to a float,
they don't need to produce as many digits of precision and so the
algorithms could terminate sooner, leading to faster execution.

--
James Youngman                               VG Gas Analysis Systems
The trouble with the rat-race is, even if you win, you're still a rat.

 
 
 

1. Ported fast Cray libm routines now available !

Hello all,

a first version 0.90 of my port of the (scalar) benchlib routines by
Cray is now available at

http://people.frankfurt.netsurf.de/Joachim.Wesner/libfm.0.90.tar.gz

It contains instructions to create a static library libfm.a that can be
linked with your executables (put it in /usr/lib). Temporary variables
are now stored on the stack, instead with the other *constants*, so the
software could also be changed into a shareable object in future.

I made many other small fixes to the appearence of the source code as
elimation of commented out code and unused variables etc., besides the
differences in assembler source format. Especially trying to
automatically convert the block data subprograms into appropriate
assembler data statements while interchanging several lines etc., by a
simple patch, seemed too complicated or would have ended in a patch:
"Delete all original lines, insert the following new lines ..."

So in the end I decided to publish my complete final version together
with the orginal sources. Remember, the software is still Copyright by
Cray, see the file reply.cray for a first promising statement of one of
the developers of the code about use of the code.

libfm 0.90 contains the following functions:

double sin(double x);
double cos(double x);
double tan(double x);   /* derived using cossin() below */
struct complex {double re, im;} cossin(double x);
        /* simultaneous cos()/sin() at a running time only slightly
           longer than cos() ! */

double exp(double x);
double log(double x);
double log10(double x); /* derived from log() */
double sqrt(double x);
double sqrti(double x); /* Somewhat faster version of 1./sqrt(x) */

double powr(double x, double y);
        /* Less accurate, but MUCH faster 'quick and dirty' variant of
           pow() that also does no special handling of integer
exponents.
           If you like it to completely replace pow(), change all
references
           to powr in file powr.S and recompile */

/* Float precision variants that even squeeze out a bit more running
time.
   However, these routines turn out to be only marginally faster on my
   LX 533, see the file 'timings' */

double exp32(double x);
double log32(double x);
double sqrt32(doubel x);

I hope you will like that code, please send any bug reports etc. to my
email adress.

HOWEVER, better, fully GPL, math routines will probably be also
available in the future on "another track":

Kazushige Goto was able to port my old sincos routine I had mentioned
before on this group to assembler and to further improve it, now running
faster than the above cray routines, even for large arguments (sin() in

functions.

I will be on a conference till saturday, I hope dowloading will work OK,
(this is the first time I use my homepage), DON'T crash the server of my
ISP !!

Best wishes,

Joachim Wesner

2. Message "idle task may not sleep"

3. Version 0.21 of free fast math routines (libffm, preliminary version) now released !

4. NEWBIE : HELP needed w/Apache

5. routine "finite()" not in libm.a

6. fcagent RPC program number

7. Fast cray libm routines available !?

8. Solaris x86 2.6 CDE / Xaccel color palette problem

9. Floating Exception with acos(-2.0) in libm.4.5.26

10. Floating point conversion routines

11. Floating point routines built under Redhat 5.x return unexpected "NaN" value?

12. Float conversion routines from VMS to UNIX

13. libm.so.5, needed by /usr/lib/libstdc++.so, conflicts with libm.so.6