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