for (int i = 0; i < 1000000; i++)
acos(.570);
Here, I''ve called acos() 1 million times, and on my computer the program executes instantly. So is acos() not that slow after all, or am I missing something?
arc cosine slow in c++ ?
Im reading Lamothe''s Tricks of the 3d GPG''s, and on p 1383 he makes a huge deal about not calling an arccosine() function in ''real-time'' code because its too damn slow. He then spends about 4 pages showing you how to make it faster.
The project Im working on right now uses C++''s acos() funciton in a couple of places, so I decided to see if it really was too slow to use.
Since I cant figure out how to use the profiler in VS.net, (Heck, I dont even know if there IS one), I decided to do it the old fashioned way and just call the code a bunch of times:
Probably, your compiler is optimizing away the whole thing, ergo that code is not very good for testing the performance of the function.
DISCLAIMER: If any of the above statements are incorrect, feel free to deliver me a good hard slap!
My games: DracMan | Swift blocks
[edited by - JohanOfverstedt on March 20, 2004 8:25:55 PM]
DISCLAIMER: If any of the above statements are incorrect, feel free to deliver me a good hard slap!
My games: DracMan | Swift blocks
[edited by - JohanOfverstedt on March 20, 2004 8:25:55 PM]
It might be a good idea to also have something to compare it to. Perhaps implementing what Lamothe suggests, or maybe just timing a similarly structured sqrt call in a loop.
Doc, I compared it to the sqrt function as you said, and it runs about the same speed (I increased the iterations to 10 million so i can more easily see a difference - now acos() takes about 1.5 seconds, while sqrt takes about 1 second)
JohanOfverstedt, I considered that, but if that were the case, then in my above test, I think that both sqrt and acos would take the same time wouldnt it? In any case, can you recommend a better test?
I guess what I want to know is: is that considered slow? If it takes 1.5 second to execute 10 million calls to arccos, is that really something you need to speed up?
[edited by - AndreTheGiant on March 20, 2004 8:35:42 PM]
JohanOfverstedt, I considered that, but if that were the case, then in my above test, I think that both sqrt and acos would take the same time wouldnt it? In any case, can you recommend a better test?
I guess what I want to know is: is that considered slow? If it takes 1.5 second to execute 10 million calls to arccos, is that really something you need to speed up?
[edited by - AndreTheGiant on March 20, 2004 8:35:42 PM]
quote:Original post by AndreTheGiant
I guess what I want to know is: is that considered slow? If it takes 1.5 second to execute 10 million calls to arccos, is that really something you need to speed up?
Depends on how many times you need to call it. I wouldn''t worry about it unless you really do need to call it a million times per frame. And chances are you don''t.
Apply the normal performance rule.
Write for maintainability, then profile for performance tuning (and optimize the hot spots). The other, slightly less important rule is look for algorithmic improvements rather than micro optimizations.
Chances are arccos is no where near the top when it comes to CPU consumption when mixed with an entire game-like application. Only after you''ve determined that arccos is required so much that it is a bottle neck, and there are no other algorithms without arccos to perform your task, should you start looking at making arccos faster.
Write for maintainability, then profile for performance tuning (and optimize the hot spots). The other, slightly less important rule is look for algorithmic improvements rather than micro optimizations.
Chances are arccos is no where near the top when it comes to CPU consumption when mixed with an entire game-like application. Only after you''ve determined that arccos is required so much that it is a bottle neck, and there are no other algorithms without arccos to perform your task, should you start looking at making arccos faster.
So.... Lamothe is a bonehead?
Also, as I said, Visual Studio .NET has no profiler surprisingly. What are my alternatives? Are there freely available profilers?
Also, as I said, Visual Studio .NET has no profiler surprisingly. What are my alternatives? Are there freely available profilers?
quote:Original post by AndreTheGiantUse cin >> x then calculate acos(x) instead.
In any case, can you recommend a better test?
Hmm well then how will I know that its not the I/O causing any delays? Im guessint it WOULD be the io.
Anyway, I dont think I care anymore. Maybe lamothe was using an older compiler than I am, and his didnt optimize. In fact, his 4 pages of code to make acos() faster implemented some sort of a lookup table. Maybe thats what my compiler does.
Either way, its plenty fast enough for me.
Anyway, I dont think I care anymore. Maybe lamothe was using an older compiler than I am, and his didnt optimize. In fact, his 4 pages of code to make acos() faster implemented some sort of a lookup table. Maybe thats what my compiler does.
Either way, its plenty fast enough for me.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement