Is virtual calls really slow or it is just bull........?

This is a discussion on Is virtual calls really slow or it is just bull........? within the C++ Programming forums, part of the General Programming Boards category; Attempting to run that test on my computer caused everything to come to a complete standstill. It might have something ...

  1. #31
    Registered User
    Join Date
    Sep 2009
    Posts
    63
    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.

  2. #32
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Zach_the_Lizard View Post
    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.
    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.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  3. #33
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,587
    Quote Originally Posted by Zach_the_Lizard View Post
    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.
    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?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #34
    Registered User
    Join Date
    Sep 2009
    Posts
    63
    Quote Originally Posted by Elysia View Post
    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.
    I have an Intel Q6600 running at 2.4 Ghz.

    Quote Originally Posted by Elysia View Post
    What is Test doing in your latest test, though?
    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

  5. #35
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Elysia View Post
    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?
    no changes, btu here it is jsut to be sure -
    Code:
    extern unsigned long Count; // here to ensure forced linkage
    
    void Test(unsigned long* Junk){
    	
    	*Junk+=2;
    	
    	return;
    	}
    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.
    Last edited by abachler; 09-27-2009 at 10:40 AM.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  6. #36
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,587
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #37
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Elysia View Post
    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.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  8. #38
    Registered User
    Join Date
    Apr 2006
    Posts
    2,032
    Quote Originally Posted by Elysia View Post
    All in all, the same as virtual function calls.
    Looking at assembly for function calls, the compiler will basically just call a specific function pointer inside the vtable inside the class. So this is basically the same code.
    Some compilers might do differently, but this is sufficient for me.
    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.

  9. #39
    Registered User
    Join Date
    Apr 2006
    Posts
    2,032
    Quote Originally Posted by abachler View Post
    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.
    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.

  10. #40
    Dae
    Dae is offline
    Deprecated Dae's Avatar
    Join Date
    Oct 2004
    Location
    Canada
    Posts
    1,034
    Quote Originally Posted by King Mir View Post
    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.
    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

  11. #41
    Registered User
    Join Date
    Sep 2009
    Posts
    63
    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.

  12. #42
    Registered User
    Join Date
    Apr 2006
    Posts
    2,032
    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.

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 26
    Last Post: 07-05-2010, 10:43 AM
  2. Replies: 48
    Last Post: 09-26-2008, 03:45 AM
  3. pure virtual calls in destructor
    By FillYourBrain in forum C++ Programming
    Replies: 2
    Last Post: 08-21-2003, 08:31 AM
  4. C++ XML Class
    By edwardtisdale in forum C++ Programming
    Replies: 0
    Last Post: 12-10-2001, 10:14 PM
  5. Exporting Object Hierarchies from a DLL
    By andy668 in forum C++ Programming
    Replies: 0
    Last Post: 10-20-2001, 01:26 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21