Mike Berry (on floats vs doubles) writes:

} As for which to use, it depends on and should be chosen to 
} match the situation.

} A few years ago I did a bulk search and replace in the csound 
} code for floats and changed them to doubles. I then compiled on 
} a PPC and found that things ran slower, not faster as I 
} expected. I expect that the memory access hit for the cache 
} outweighed the precision-conversion speed increase.


I don't know much about cache factors, but for my money it 
doesn't seem to be as simple as the mass replace described 
above and if one was to do it these days, additional 
considerations like the newer compilers, header files, the 
ordering of function variables, and the Motorola math library 
might yield a different result. I would guess that you compiled 
without CodeWarrior error checking.

Floats versus doubles aside for a moment, I worked extensively 
with the code for Perf a few months ago with the aim of 
providing a 'clean' environment for the Macintosh. I compiled 
with all error checking turned on except for "arithmetic 
conversion" and resolved every compiler error for both C and 
C++ with ANSI strict and require protos (about 5000 errors 
total came up in CodeWarrior). The net result was that the 
sound file generation time from the same orc/sco decreased from 
~16.9 seconds to ~13.9 seconds.

Replacing all instances of 'float' with 'double' would 
additionally require flagging errors for arithmetic conversion 
in order to ascertain where the code would have to be changed 
(or some values cast) to take advantage of the speed edge using 
doubles would give.

Compiling without error checking lets one get away with this 
kind of thing but when looking to shave microseconds off of 
function performance, it's not the best approach.

Unfortunately, there's only one way to check if this is indeed 
the case. Wanna make a guess as to how many arithmetic 
conversion errors will come up? Each one of those contributes 
to sluggish performance.


Basically though, I would agree with your remark from above: 
"As for which to use, it depends on and should be chosen to 
match the situation.", as being especially considerate in 
cross-platform code and would suggest that any such 
implementation be able to be redefined on a case by case basis. 
Which sort of brings up the previously discussed side issue of 
macros being evil.



Philip

...who would spell it 'precision' if he had started the thread.


Philip Aker
Composer, Pianist,
Finale Plugins

Suite 13
1405 West 11 Avenue
Vancouver BC
Canada V6H 1K9

philip@vcn.bc.ca