www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - You do WHAT with floating point numbers?

reply Tim Starling <Tim_member pathlink.com> writes:
I wasn't sure how closely you guys watch your wiki, so I thought I'd better post
this here as well. 

http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Float

Using large types for intermediate values will make floating point calculations
much slower, especially on a Pentium 4 or later. It's a really bad idea. You
should use the minimum by default.

-- Tim Starling
Sep 26 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <cj886h$16gn$1 digitaldaemon.com>, Tim Starling says...
I wasn't sure how closely you guys watch your wiki, so I thought I'd better post
this here as well. 

http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Float

Using large types for intermediate values will make floating point calculations
much slower, especially on a Pentium 4 or later. It's a really bad idea. You
should use the minimum by default.

Makes sense. Though I have to wonder why Intel has "effectively deprecated" 80-bit floating point. I haven't taken the time to read their docs. I don't suppose it says? Sean
Sep 27 2004
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
Tim Starling wrote:

 I wasn't sure how closely you guys watch your wiki, so I thought I'd
 better post this here as well.
 
 http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Float
 
 Using large types for intermediate values will make floating point
 calculations much slower, especially on a Pentium 4 or later. It's a
 really bad idea. You should use the minimum by default.
 
 -- Tim Starling

In the context of the Intel doc., it looks like what they are suggesting is that the /programmer/ (not the compiler developer) use single precision when double precision is not needed. AFAIK, it's always been recommended that the developer use single precision (floats) rather than doubles if the extra precision is not needed and there is a lot of fp data moving around, because it is often faster. On Intel (including the P4) the fp registers are 80 bit. All the author is suggesting in the context of the D language is that compiler developers shouldn't have to limit precision to 32 bits (floats) or 64 bits (doubles) if keeping 80 bit precision results in faster code. D is allowing for this where other languages may specify a maximum precision regardless of the what is best for the hardware. GCC/++, MSVC and the latest Intel compiler all use 80 bit precision to/from the fp registers for intermediate data, and all have a switch to "improve floating point consistency" by rounding/truncating intermediate values, which is often a speed "deoptimization". This includes the P4 and AMD64 chips. D on the other hand follows IEEE 754 minimum precision guidelines for floats and doubles, doesn't specify a maximum precision and also offers the real (80 bit floating point) type for code that would benefit from that. I don't see anywhere in that Intel doc. where it says that 80 bit fp register operations are "deprecated". It is a different ballgame when you are talking vectorization with SIMD instructions. For operations (and compilers) that take advantage of that, then it is probably best to stick to 32 or 64 bit floating-point for code that can be vectorized. From what I've seen, even Intel compilers don't do a great job of vectorizing though, and fall back to using the 80 bit fp general register operations. - Dave
Sep 27 2004
next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message
news:cj9s52$1893$1 digitaldaemon.com...
 Tim Starling wrote:

 I wasn't sure how closely you guys watch your wiki, so I thought I'd
 better post this here as well.

 http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Float

 Using large types for intermediate values will make floating point
 calculations much slower, especially on a Pentium 4 or later. It's a
 really bad idea. You should use the minimum by default.

 -- Tim Starling

In the context of the Intel doc., it looks like what they are suggesting

 that the /programmer/ (not the compiler developer) use single precision
 when double precision is not needed. AFAIK, it's always been recommended
 that the developer use single precision (floats) rather than doubles if

 extra precision is not needed and there is a lot of fp data moving around,
 because it is often faster.

 On Intel (including the P4) the fp registers are 80 bit. All the author is
 suggesting in the context of the D language is that compiler developers
 shouldn't have to limit precision to 32 bits (floats) or 64 bits (doubles)
 if keeping 80 bit precision results in faster code. D is allowing for this
 where other languages may specify a maximum precision regardless of the
 what is best for the hardware.

 GCC/++, MSVC and the latest Intel compiler all use 80 bit precision

 the fp registers for intermediate data, and all have a switch to "improve
 floating point consistency" by rounding/truncating intermediate values,
 which is often a speed "deoptimization". This includes the P4 and AMD64
 chips. D on the other hand follows IEEE 754 minimum precision guidelines
 for floats and doubles, doesn't specify a maximum precision and also

 the real (80 bit floating point) type for code that would benefit from
 that.

 I don't see anywhere in that Intel doc. where it says that 80 bit fp
 register operations are "deprecated".

 It is a different ballgame when you are talking vectorization with SIMD
 instructions. For operations (and compilers) that take advantage of that,
 then it is probably best to stick to 32 or 64 bit floating-point for code
 that can be vectorized. From what I've seen, even Intel compilers don't do
 a great job of vectorizing though, and fall back to using the 80 bit fp
 general register operations.

 - Dave

well said. I just want to add that Java's original requirement that all fp operations happen in exactly single or double precision IEEE 754 and no more or less meant performance went down the tubes. D generally seems to have learned from Java's mistakes in this regard.
Sep 27 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
You should add that to the wiki!
Sep 30 2004
parent Dave <Dave_member pathlink.com> writes:
Walter wrote:

 You should add that to the wiki!

Done..
Oct 01 2004