Which is faster?
-
Try with optimizations turned off.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
-
Hey, in case you care, i wrote a little tester that uses the high performance counter to check how much it takes to do the given equations 100million times, here are the resuls, 1a being the first method, 1b being the first method with the different order and 2 being the second method: <1a> 0.698949 sec <1b> 0.750401 sec <2 > 0.527537 sec ---------- <1a> 0.711031 sec <1b> 0.701738 sec <2 > 0.508943 sec ---------- <1a> 0.699821 sec <1b> 0.710665 sec <2 > 0.514772 sec ---------- <1a> 0.695679 sec <1b> 0.693272 sec <2 > 0.510279 sec ---------- <1a> 0.697279 sec <1b> 0.696093 sec <2 > 0.569204 sec Seems like method 2 indeed wins, changing the order doesn't seem to make much of a difference (diff. between 1a and 1b). [Edit] Tests were done with a no-optimization debug build.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
modified on Saturday, June 19, 2010 11:59 AM
That's interesting 'cause on three compilers (VC++2010, Digital Mars latest and gcc 4.1) I got pretty much the same execution times for all three cases (the variation between runs was of the same order as the variation between methods). VC++ and Digital Mars went a bit bonkers and optimised the entire calculation away until I did some fiddling to make sure that the results were referenced by something else. Cheers, Ash
-
That's interesting 'cause on three compilers (VC++2010, Digital Mars latest and gcc 4.1) I got pretty much the same execution times for all three cases (the variation between runs was of the same order as the variation between methods). VC++ and Digital Mars went a bit bonkers and optimised the entire calculation away until I did some fiddling to make sure that the results were referenced by something else. Cheers, Ash
I used a debug build to avoid optimisations, and the compiler comes from VS2003 (i know, i know, it's old...)
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
-
I used a debug build to avoid optimisations, and the compiler comes from VS2003 (i know, i know, it's old...)
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
Doesn't switching the optimiser off defeat the idea of having an optimising compiler? And I wouldn't worry about using VC++ 2003. It's under 10 years old and actually supports a reasonable amount of the C++ 98 standard unlike all the numpties who painted themselves into a corner using VC++ 6 and now can't move off it because they were programming to MS's standard. Cheers, Ash
-
Doesn't switching the optimiser off defeat the idea of having an optimising compiler? And I wouldn't worry about using VC++ 2003. It's under 10 years old and actually supports a reasonable amount of the C++ 98 standard unlike all the numpties who painted themselves into a corner using VC++ 6 and now can't move off it because they were programming to MS's standard. Cheers, Ash
As said here[^], probably the compiler modifies the code to its likes to produce the -possibly- fastest way to do it. Which kinda renders the whole question obsolete i guess, since no matter how i do it the result will be the same, or at least, which is faster will depend on the used compiler/optimization method. So i'd say, turning off optimizations is only important from the "hypothetical question's" point of view.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
-
Try with optimizations turned off.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
-
That's odd...
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
-
Doesn't switching the optimiser off defeat the idea of having an optimising compiler? And I wouldn't worry about using VC++ 2003. It's under 10 years old and actually supports a reasonable amount of the C++ 98 standard unlike all the numpties who painted themselves into a corner using VC++ 6 and now can't move off it because they were programming to MS's standard. Cheers, Ash
Aescleal wrote:
Doesn't switching the optimiser off defeat the idea of having an optimising compiler?
And the whole point of a speed test, I would say. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
In case you care, i did the testing, here are[^] the results.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
Yes, I can care. Anyway I wouldn't use a debug build for a speed test. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Yes, I can care. Anyway I wouldn't use a debug build for a speed test. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Just for you ( :) ), here are the results of a release build with "default" optimization (for speed): <1a> 0.0000022349 sec <1b> 0.0000019556 sec <2 > 0.0000019556 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000016762 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000016762 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000019556 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000019556 sec and with optimizations turned off: <1a> 0.7622823571 sec <1b> 0.7618152586 sec <2 > 0.5077494486 sec ---------- <1a> 0.7632852779 sec <1b> 0.7537491497 sec <2 > 0.5121279380 sec ---------- <1a> 0.7620644523 sec <1b> 0.7755153239 sec <2 > 0.5118524840 sec ---------- <1a> 0.7574504581 sec <1b> 0.7570453787 sec <2 > 0.5195719009 sec ---------- <1a> 0.7594526679 sec <1b> 0.7610942173 sec <2 > 0.5190137294 sec [EDIT] I wonder where the "variance" of the time needed for the 2nd method comes from with optimizations applied.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
-
Just for you ( :) ), here are the results of a release build with "default" optimization (for speed): <1a> 0.0000022349 sec <1b> 0.0000019556 sec <2 > 0.0000019556 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000016762 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000016762 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000019556 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000019556 sec and with optimizations turned off: <1a> 0.7622823571 sec <1b> 0.7618152586 sec <2 > 0.5077494486 sec ---------- <1a> 0.7632852779 sec <1b> 0.7537491497 sec <2 > 0.5121279380 sec ---------- <1a> 0.7620644523 sec <1b> 0.7755153239 sec <2 > 0.5118524840 sec ---------- <1a> 0.7574504581 sec <1b> 0.7570453787 sec <2 > 0.5195719009 sec ---------- <1a> 0.7594526679 sec <1b> 0.7610942173 sec <2 > 0.5190137294 sec [EDIT] I wonder where the "variance" of the time needed for the 2nd method comes from with optimizations applied.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
Thank you, sir. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
The only way to find out is to write some tests, compile and run them on your system. Arguing thoretically about what's faster is fairly pointless. Cheers, Ash
Wrong. The only way is to create the .COD file and see what the compiler generates for that code, then with a debugger, see what load time optimization may be done during loading. It is this final machine code that tells the story during execution. Dave.
-
Wrong. The only way is to create the .COD file and see what the compiler generates for that code, then with a debugger, see what load time optimization may be done during loading. It is this final machine code that tells the story during execution. Dave.
CAVEAT: This doesn't apply if you're talking about embedded systems where you have a greater degree of control over what's running. On your average desktop looking at an assembly listing won't tell you how fast a piece of code runs. It might give you an idea, might even tell you some idea of the relative speed [1] and where you could speed it up if you wanted to manually code it but won't tell you how fast it actually runs. As for "load time optimisation" I'm not sure what you mean in this context but load time shouldn't be a factor in measuring how fast a particular lump of code runs. Load time is long over by the time you start measuring how fast a particular piece of code runs. Cheers, Ash