> 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

Ron Parker <ron### [at] povrayorg> wrote:
: 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.)

  As someone already said, this is not true anymore for pentium-class
processors.
  In a plain pentium (if I remember right) the fld takes about 6 clocks
and fst about 3 (for both float and double) and fmul takes 1 clock (amazingly)
in most cases.
  In a P-II it's even faster.

  On the other hand, all values are internally converted to 80 bits floating
numbers by the FPU (this is usually the long double type in C compilers for
PC). However, it's not faster to use the long double type. Double is faster.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 24 Nov 1999 13:11:01 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: 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.)
>
>  As someone already said, this is not true anymore for pentium-class
>processors.
>  In a plain pentium (if I remember right) the fld takes about 6 clocks
>and fst about 3 (for both float and double) and fmul takes 1 clock (amazingly)
>in most cases.
>  In a P-II it's even faster.

Y'all seem to be missing the point.  My point was that it is not true that 
there is a conversion penalty for using 32-bit floats on Intel x86 processors, 
and that that has been true since at least the 387.  Whether later processors
made the difference smaller or nonexistent is irrelevant: even when there was a
penalty, it favored using floats over doubles rather than the other way around
as stated, and even then it was really small (5 clocks on a 33-MHz 387 is 150ns.
It takes millions of FLDs - even on a 387 - before that even comes close to 
taking measurably more or less time.)

-- 
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

In article <383BD96F.47668841@mitre.org> , Alexander Enzmann 
<xan### [at] mitreorg>  wrote:

> 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.

Well, that is true up to the 486 (and maybe Pentium). As all current x86
processors translate instructions internally, there is bottleneck between
the FPU and its registers.

> 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.

Yes, this will happen when using old code or compilers that don't support
proper alignment. Usually cache row sizes are 16 or 32 bytes and a processor
will always fetch a complete row anyway.
Of course you will see a performance hit if your data really takes up large
parts of the caches.
However, I have tried to define DBL as float on a Mac (PowerPC) and could
not find any significant speed increase for large scenes, for example Anton
Raves' Lego scene heli_3.pov takes 79 s with DBL as double and 76 s with DBL
as float (using radiosity and anti-aliasing). That makes only four percent
speed increase, other scenes I tried didn't even show that much at all.
So I guess POV-Ray does not suffer that much from "DBL size". Its memory
access bottlenecks are probably somewhere else.

> 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.

Yes, and then those four percent would matter!


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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

Hmm, well, not easy to translate, but I'll try. A little bit of
background.
German songs that go well in germany are called "Schlager", you could
translate it as "hit". One of our most beloved "Schlager"-singers,
called
Rex Gildo, commited suicide one of the last weeks. He jumped out of the
toilet window while some reporters where waiting in another room.

Literally it would mean: "The german hit has jumped out of the toilet
window".

You didn't laugh? I knew it!

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

Post a reply to this message

Markus Becker wrote:

> You didn't laugh? I knew it!

I guess I would have had to be there :)

-- 
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