strange sqrt speed
Author
Hi. I recently ran some hacked up tests to test the speed of the sqrt function from the math library in VC++ 6.0. I used the multiply operation, as a comparison. I've heard that the sqrt function takes an enormous amount of time, but my results seem to contradict this. Can anyone shed some light on this?
[edited by - SH on January 17, 2003 3:55:13 PM]
so was the random function part of the loop?
maybe it would be good to do all the random stuff first. Ie. make an array of random numbers before you start testing.
maybe it would be good to do all the random stuff first. Ie. make an array of random numbers before you start testing.
hey - you''ve changed your post - taken out the stuff about using random numbers and things - and not explained why.
what''s going on?
what''s going on?
Author
Sorry, I removed that stuff because it seemed like extraneous information. I guess I really just wanted to know if the sqrt function really has the porformance hit it''s famous for. I''ve read that look-up tables are used for part of the sqrt function, and perhaps this explains things a bit. Also, maybe other stuff going on (such as task-switching) negates the difference between the sqrt and the multiply instruction I tested again.
Anyway, to answer question, the sqrt function was part of the loop:
while( TIME_LEFT )
{
x = sqrt( rand_f( 100 ));
count++;
}
and similar. I also tried things like x = sqrt( x + rand_f(100) ), and made sure to report the final output of x, to make sure x was "relevant" and the compiler wouldn''t optimize it out. I''ve run tests both in release and debug mode. The results are different, but not near the massive chasm in performance I expected.
Anyway, to answer question, the sqrt function was part of the loop:
while( TIME_LEFT )
{
x = sqrt( rand_f( 100 ));
count++;
}
and similar. I also tried things like x = sqrt( x + rand_f(100) ), and made sure to report the final output of x, to make sure x was "relevant" and the compiler wouldn''t optimize it out. I''ve run tests both in release and debug mode. The results are different, but not near the massive chasm in performance I expected.
You should try to avoid it when you can, but nowadays the sqrt performance issue isn''t as big as it used to be when there wasn''t as much processor power to go around.
As petewood was getting at, you won''t get accurate results because you''re not timing the right thing - in this case you want to time the sqrt() call, not the sqrt() call along with the call to rand(), which is what you are doing. Pre-generate an array of random numbers and iterate through this.
Also, if you don''t use ''x'' after the while loop, most compilers will simply optimize away the line of code ''x = sqrt()...'' because ''x never gets used.
Author
quote:Original post by Miserable
As petewood was getting at, you won''t get accurate results because you''re not timing the right thing - in this case you want to time the sqrt() call, not the sqrt() call along with the call to rand(), which is what you are doing.
That''s certainly true, but that would tend to make sqrt even slower. I did what you suggested though, and used arrays for both the sqrt and the multiply instruction. Same basic time results-- sqrt seems to be only marginally slower, not even close to twice as slow. Again, I''m accumulating and reporting the results of the operations at the end, so the compiler can''t optimize them out.
Thanks for replying everyone. If, as Zipster has said, the actual time for the sqrt function itself isn''t really as critical on todays processors, then I think I have my answer, there.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement