Which is faster?
-
Hey folks! I was just wondering, which of these would be faster:
RECT R1, R2;
POINT Offset;
...
R1 = R2;
R1.left += Offset.x;
R1.right += Offset.x;
R1.top += Offset.y;
R1.bottom += Offset.y;or
RECT R1, R2;
POINT Offset;
...
R1.left = R2.left + Offset.x;
R1.right = R2.right + Offset.x;
R1.top = R2.top + Offset.y;
R1.bottom = R2.bottom + Offset.y;As a "sub question of this", would this:
R1.left += Offset.x;
R1.right += Offset.x;
R1.top += Offset.y;
R1.bottom += Offset.y;be faster than this:
R1.left += Offset.x;
R1.top += Offset.y;
R1.right += Offset.x;
R1.bottom += Offset.y;? I mean, in the first version when the first addition is done Offset.x is already loaded into one of the registers so the second addition needs less memory access, while in the second version, it would need to retrieve Offset.y to do the addition, then retrieve Offset.x again and then Offset.y again. In the first version it has to retrieve both Offset.x and Offset.y only once during the 4 additions, so that's half the memory access from Offset's point of view. Right? If so, I also wonder if the compiler is smart enough to change the order of these to produce a more speed optimized code (i personally highly doubt this). Thanks for any sharing of thoughts. :)
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Computers don't kill programs, users kill programs < > "It doesn't work, fix it" does not qualify as a bug report. <
-
Hey folks! I was just wondering, which of these would be faster:
RECT R1, R2;
POINT Offset;
...
R1 = R2;
R1.left += Offset.x;
R1.right += Offset.x;
R1.top += Offset.y;
R1.bottom += Offset.y;or
RECT R1, R2;
POINT Offset;
...
R1.left = R2.left + Offset.x;
R1.right = R2.right + Offset.x;
R1.top = R2.top + Offset.y;
R1.bottom = R2.bottom + Offset.y;As a "sub question of this", would this:
R1.left += Offset.x;
R1.right += Offset.x;
R1.top += Offset.y;
R1.bottom += Offset.y;be faster than this:
R1.left += Offset.x;
R1.top += Offset.y;
R1.right += Offset.x;
R1.bottom += Offset.y;? I mean, in the first version when the first addition is done Offset.x is already loaded into one of the registers so the second addition needs less memory access, while in the second version, it would need to retrieve Offset.y to do the addition, then retrieve Offset.x again and then Offset.y again. In the first version it has to retrieve both Offset.x and Offset.y only once during the 4 additions, so that's half the memory access from Offset's point of view. Right? If so, I also wonder if the compiler is smart enough to change the order of these to produce a more speed optimized code (i personally highly doubt this). Thanks for any sharing of thoughts. :)
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Computers don't kill programs, users kill programs < > "It doesn't work, fix it" does not qualify as a bug report. <
-
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
I guess you have a point there...
> 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 folks! I was just wondering, which of these would be faster:
RECT R1, R2;
POINT Offset;
...
R1 = R2;
R1.left += Offset.x;
R1.right += Offset.x;
R1.top += Offset.y;
R1.bottom += Offset.y;or
RECT R1, R2;
POINT Offset;
...
R1.left = R2.left + Offset.x;
R1.right = R2.right + Offset.x;
R1.top = R2.top + Offset.y;
R1.bottom = R2.bottom + Offset.y;As a "sub question of this", would this:
R1.left += Offset.x;
R1.right += Offset.x;
R1.top += Offset.y;
R1.bottom += Offset.y;be faster than this:
R1.left += Offset.x;
R1.top += Offset.y;
R1.right += Offset.x;
R1.bottom += Offset.y;? I mean, in the first version when the first addition is done Offset.x is already loaded into one of the registers so the second addition needs less memory access, while in the second version, it would need to retrieve Offset.y to do the addition, then retrieve Offset.x again and then Offset.y again. In the first version it has to retrieve both Offset.x and Offset.y only once during the 4 additions, so that's half the memory access from Offset's point of view. Right? If so, I also wonder if the compiler is smart enough to change the order of these to produce a more speed optimized code (i personally highly doubt this). Thanks for any sharing of thoughts. :)
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Computers don't kill programs, users kill programs < > "It doesn't work, fix it" does not qualify as a bug report. <
2 no :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use < PRE > tags for code snippets, it preserves indentation, and improves readability.
-
Hey folks! I was just wondering, which of these would be faster:
RECT R1, R2;
POINT Offset;
...
R1 = R2;
R1.left += Offset.x;
R1.right += Offset.x;
R1.top += Offset.y;
R1.bottom += Offset.y;or
RECT R1, R2;
POINT Offset;
...
R1.left = R2.left + Offset.x;
R1.right = R2.right + Offset.x;
R1.top = R2.top + Offset.y;
R1.bottom = R2.bottom + Offset.y;As a "sub question of this", would this:
R1.left += Offset.x;
R1.right += Offset.x;
R1.top += Offset.y;
R1.bottom += Offset.y;be faster than this:
R1.left += Offset.x;
R1.top += Offset.y;
R1.right += Offset.x;
R1.bottom += Offset.y;? I mean, in the first version when the first addition is done Offset.x is already loaded into one of the registers so the second addition needs less memory access, while in the second version, it would need to retrieve Offset.y to do the addition, then retrieve Offset.x again and then Offset.y again. In the first version it has to retrieve both Offset.x and Offset.y only once during the 4 additions, so that's half the memory access from Offset's point of view. Right? If so, I also wonder if the compiler is smart enough to change the order of these to produce a more speed optimized code (i personally highly doubt this). Thanks for any sharing of thoughts. :)
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Computers don't kill programs, users kill programs < > "It doesn't work, fix it" does not qualify as a bug report. <
You may have a look at the assembly code (compile with /E option). :)
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] -
You may have a look at the assembly code (compile with /E option). :)
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]Yeah, i thought of that too... I think i will just try to write a small proggie that test these methods and see which performs better. Thanks for your answer.
> 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. <
-
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
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
-
2 no :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use < PRE > tags for code snippets, it preserves indentation, and improves readability.
In case you care, here[^] are some test results, seems like you are right. :thumbsup:
> 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. <
-
You may have a look at the assembly code (compile with /E option). :)
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. <
-
Yeah, i thought of that too... I think i will just try to write a small proggie that test these methods and see which performs better. Thanks for your answer.
> 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. <
-
In case you care, here[^] are some test results, seems like you are right. :thumbsup:
> 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. <
Thanks. I had already seen your other message. You should make clear what build you used (debug/release) and what optimization level, it may be relevant, not to the outcome, but to the relative difference. And the conclusion should be: moves are not free; try and combine them with actual calculations. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use < PRE > tags for code snippets, it preserves indentation, and improves readability.
-
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]