On Fri, 31 Aug 2007, Chris Jones wrote: > Yes, I have profiled the code, quite extensively, using the valgrind/calltree > application. From this I know this that I'm know I've tidying up this to the > point where its hard to find big improvements, the cpu time is fairly well > spread around, not isolated in a few places. So am now looking a a few places > where math calls are taking more time than I would hope. I'm not going to get > factors in speed in the overall application, but I hope in a few places > things can be improvemed a lot locally. Another poster mentioned that pentiums have hardware instructions for trig functions. If you are using them, there isn't much hope for speed up. If you are not using them, it might be because you need some processor-specific flags that tell gcc that they are available. It's possible that you will have to look at the assembler listing for the math library to get the information you want. Getting the error handling right might require wrappers for the hardware instructions. My recollection is that -ffast-math tells gcc to assume error free math. If you want something that *might* beat the hardware instructions: #define sin(x) (x) #define cos(x) (1-(x)*(x)/2) These will get you about 10% accuracy in the range +-0.71 Note that the sum of the squares is 1+x**4/4 . Similar functions near pi/2 will cost you a subtraction. Near pi/4 we have sin(x) roughly (sqrt_2*(1-pi/4)) + sqrt_2*(x) cos(x) roughly (sqrt_2*(1-pi/4)) - sqrt_2*(x) Where sqrt_2=sqrt(0.5) The sum of the squares is 1+(x-pi/4)**2/2 These formulas will probably not be useful unless you know in advance the ranges of their arguments. -- Mike hennebry@xxxxxxxxxxxxxxxxxxxxx "Horse guts never lie." -- Cherek Bear-Shoulders
