In article <383ADE3C.61F2BC9E@buckosoft.com> , Dick Balaska 
<dic### [at] buckosoftcom>  wrote:

> So if your code is using floats,
> they have to be converted to doubles before stuffing in the FPU (and
> converted back to float on the way out of the FPU).  So you lose precision
> and take a performance hit by using floats.

That is wrong! There is no time for conversion required, as it is a trivial
to "cut off" the exponent (reduce it from 11 to 8 bit) and the significant
(reducing it from 52 to 23 bit) when loading/storing them.
As a matter of fact, internally all current processors store floating-point
numbers as if they were doubles (or whatever other most precise internal
format they support). When performing the calculation as single-precision,
the other bits are just not taken into account.


     Thorsten

Post a reply to this message

Ron Parker wrote:

Comments a little bit from back top front:
>(This data is for
> the 386.  Other processors vary, of course.  

And as such it is of no value. Who has a 386?

I know something like FMUL taking (if the pipelines are full) arount
1/3 clock. Double floating points are indeed a lot faster than integers.

Markus
-- 
Der deutsche Schlager ist aus dem Klofenster gesprungen....

Post a reply to this message

Thorsten Froehlich wrote:
> 
> In article <383ADE3C.61F2BC9E@buckosoft.com> , Dick Balaska
> <dic### [at] buckosoftcom>  wrote:
> 
> > So if your code is using floats,
> ...
> 
> That is wrong! There is no time for conversion required, as it is a trivial
> to "cut off" the exponent (reduce it from 11 to 8 bit) and the significant
> (reducing it from 52 to 23 bit) when loading/storing them.
> As a matter of fact, internally all current processors store floating-point
> numbers as if they were doubles (or whatever other most precise internal
> format they support). When performing the calculation as single-precision,
> the other bits are just not taken into account.


It is a little more curious still.  You can force an Intel FPU to work
in several precision modes (32, 64, 80).  There are differences in the
total # of clocks from beginning to end based on how much data needs to
be pushed onto the FPU stack and the precision you run the FPU.

A secondary consideration is that with the tiny on chip cache of the
Intel chips, using larger data sizes (8 byte doubles) will cause misses
more often than using 4 byte singles.  When this happens you get a huge
performance hit.

Understanding and programming around these types of things is very
important to games programmers and real time sim packages.  It is also
quite platform dependent.

Xander

Post a reply to this message

On Wed, 24 Nov 1999 10:20:47 +0100, Markus Becker wrote:
>Ron Parker wrote:
>
>Comments a little bit from back top front:
>>(This data is for
>> the 386.  Other processors vary, of course.  
>
>And as such it is of no value. Who has a 386?
>
>I know something like FMUL taking (if the pipelines are full) arount
>1/3 clock. Double floating points are indeed a lot faster than integers.

But try getting any information on instruction timings from Intel these
days.  I checked both the PII and PIII reference manuals and they've dropped
that sort of information.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Markus Becker wrote:
> 
.
.
.
> Markus
> --
> Der deutsche Schlager ist aus dem Klofenster gesprungen....


I just wonder when some nongerman will ask you about your sig
<bg>

Marc

-- 
Marc Schimmler

Post a reply to this message

> Not really.  FLD with a 32-bit real operand is 20 clocks, as opposed to
the
> 64-bit version at 25 clocks.  FST is 44 vs. 45 clocks.  FMUL is 27-35
clocks
> for a float, or 32-57 for a double.  FDIV is 89 or 94.  So floats are
faster,
> under ideal conditions, but not by any significant amount.  (This data is
for
> the 386.  Other processors vary, of course.  Intel no longer seems to
publish
> this data, for the obvious reason that pipelining and other optimizations
> make it useless.)

But if you want to look anyway, I think Ralf Brown's Interrupt List
(http://www.pobox.com/~ralf) has the data.

Post a reply to this message

Marc Schimmler wrote:
> 
> I just wonder when some nongerman will ask you about your sig

I'm hoping for it. We had some good laughs already in our institute....

> <bg>
<veg>

BTW, this is not my courtesy, I found it on the last page of the
"SPIEGEL"
(Hohlspiegel), originally it was a headline in the "Zeit".

Markus
-- 
Der deutsche Schlager ist aus dem Klofenster gesprungen....

Post a reply to this message

Ron Parker wrote:
> 
> But try getting any information on instruction timings from Intel these
> days.  I checked both the PII and PIII reference manuals and they've dropped
> that sort of information.

You can download the developer pack from Intel (is it still free?) and
especially VTune, which will clear show you how much cycles your machine
instructions take and how the pipelines will be filled.

And you can alway try to time it for yourself.

Markus
-- 
Der deutsche Schlager ist aus dem Klofenster gesprungen....

Post a reply to this message

Markus Becker wrote:
> 
> I'm hoping for it. We had some good laughs already in our institute....
> 
> > <bg>
> <veg>
> 
> BTW, this is not my courtesy, I found it on the last page of the
> "SPIEGEL"
> (Hohlspiegel), originally it was a headline in the "Zeit".
> 

As subscribed reader of the SPIEGEL I certainly know that one! :-)

Now cm'on people ask! <vbg>

Marc

-- 
Marc Schimmler

Post a reply to this message

Marc Schimmler wrote:

> As subscribed reader of the SPIEGEL I certainly know that one! :-)
> 
> Now cm'on people ask! <vbg>

Well ?

-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message