Attempting to run that test on my computer caused everything to come to a complete standstill. It might have something to do with compiling it with g++/MinGW, though. And my system is fairly beefy, too.
In any case, I got negligible difference between the two, when you average it out. The interesting thing was the function pointer always seemed to be faster, which is not something I would have expected. Again, perhaps it has something to do with MinGW.
Last edited by Zach_the_Lizard; 09-27-2009 at 09:22 AM.
There are several optimizations for the pointer version that gcc might be using, such as keeping a copy of the pointer in a register, while the function version would be an explicit call, which would increase memory utilization, decreasing overall performance.Originally Posted by Zach_the_Lizard
Unless you are on a fast dual-core or better, your system might stall due to the time critical nature priority that we set it to to minimize interference.
I might try the code later. What is Test doing in your latest test, though?
I have an Intel Q6600 running at 2.4 Ghz.
Well, I decied to test it with a handful of compiler optimization flags. This is the average of the results from one run of the program.
GCC (mean run time, no optimization flags at all)
pFunc: 5,422.875 ms
Func: 5,516.625 ms
GCC (mean run time, -O2)
pFunc: 4009.11 ms
Func: 4307.44
This was the only result that had a significant difference, and even then, I couldn't repeat it.
GCC (mean run time, -O3)
pFunc: 2,983 ms
Func: 2,955.6 ms
no changes, btu here it is jsut to be sure -
Multi-core processors usually do worse on single threaded code, as they have shorter pipelines. The shorter pipeline is a performance trade-off for multicore environments, since pipeline flushes due to a miss in the preemptive execution are more expensive than the gains from a longer pipeline.Code:extern unsigned long Count; // here to ensure forced linkage void Test(unsigned long* Junk){ *Junk+=2; return; }
Last edited by abachler; 09-27-2009 at 10:40 AM.
I used a Core 2 Duo @ 1.87 GHz to do the tests, btw + Windows 7 Prof x86.
But with so much variance in your tests, it is impossible to say which one is best or if there is any difference.
Agreed, the only way to work ti out for sure would be to run a longer test, which I shall do directly, I will allow it to run for 10 minutes, and average the times.
[edit]
Results -
pFunc Took 4054ms avg per run over 150 runs
Func Took 4012ms per run over 150 runs
Each test took approx 10 minutes to run, and the results were normalized for a single run.
So it's a 1.04% gain, probably worth it for an inner loop, but irrelevant anywhere else in your code.
Last edited by abachler; 09-27-2009 at 11:57 AM.
Right, but it has to look up the v_table, which is an extra level of indirection.
If you want to compare virtual calls to regular call, why not do so.
Also, because memory is weak link here, the test is pretty much useless, as after the first iteration the memory will simply be cached, eliminating the typical costs that come from memory access. If you want to test repeated memory access, at least change the location each time. You want to make sure that that the two locations are not in the same block. Load testing may be a better option, but that has it's own problems.
Actually, Corned Bee pointed out that the branch predictor may be a slowdown, and your test will be effective test for that. So apparently there is little additional branch predictor penalty for an indirect function call.
Last edited by King Mir; 09-27-2009 at 08:05 PM.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
4% gain is low. It might be within error. You might be better off taking several times, so that you can find the standard deviation.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
4%? 1.04% is within error.
1.046859422% is actually 1.05% though.
It might not be error though, I can imagine the gain being 1%. I wouldn't be apposed to more timings.
Warning: Have doubt in anything I post.
GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101
Running the program for about an hour, compiled with g++ -O3, resulted in the following averages:
pFunc: 3,356.45 ms
Func: 3,356.27 ms
The difference started out being greater, but as the program continued to run, the difference began to shrink.
Of course, all this proves is there is no branch penalty. It speaks nothing of delays associated with accessing memory. Likely, the decreasing percentage on longer runs is due to the first iteration being less significant.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
