QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: renormThe results with MinGW GCC 4.5 are similar to those posted by Cuchulainn.Are you sure that your test used polymorphic calls?We should get this topic to bed now. A clear message (which was discussed in detail in other threads by multiple posters) is needed. They all come to the same conclusions. So, virtual functions are between 3 and 10 times slower than non-virtual functions.? Below you are saying 20% slower for a single thread. Btw I think it's better to use cycles or nanosecs spend on the call instead of percentages of the full function evaluation. Eg in my machine the overhead is between 0 and 0.30 sec for 270.000.000 calls, so that's a billionth of a second call overhead. I will also at some future time publish assembler analysis here, which should give an *exact* view on what the compiler does under various scenarios. That would be a good demistifying publication.Forget threads for the moment and go back to the original discussion. There is no need for assembler code. They are irrelevant here. Virtual functions are appreciably slower.

Quote Virtual functions are appreciably slower. i am surprised that we even need to discuss this - there is a vtable lookup every time a virtual is invoked

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnVirtual functions are appreciably slower.it depends on the application. Somehwere between zero and a billionth of a second per call on my machine. You need to put this in perspective, otherwise people might think that you say that their application will run 10 times slower!I made no conclusions about the speed of an application. They are your words.Here is a specific question: how do you relate your conclusions to the gcc results posted yesterday? It claims 10 times slower. Have the other posters just not understood?I found this article from games.dev

QuoteOriginally posted by: outrunCuch,btw, did you add the loop index or some other changing value to the function call argument (in that screenshot result)?I changed nothing. I just ran your program as is under release mode VS2008.

QuoteThe 10x slowdown might give the illusion that if you do a 1.000.000 scenario MC run that takes 5 seconds, and does 1.000.000 virtual function call, that you'll have 4.5 sec overhead! In reality the 1.000.000 function calls would (on my machine) give 0.001sec overhead and *so* the slowdown is actually irreleveant / not worth optimizing for this case.The only way is to experiment. This is a small scale problem.Consider a 3 factor PDE that we model with 3 diffusion, 2 drift and 3 correlation coefficients and 1 reaction term. These functions will be called NX x NY x NZ x NT times (typical values == 20, depending on how good the fd scheme is; the value could be 400, 500).This is an appreciable part is the algorithm, in total 10 x NX x NY x NZ x NT function calls. Let's say 10^9 calculations. I have excluded functions in the boundary conditions in my forrmula (6 faces ==> 6 x NT calcs).

The (humble) namespace solution is a kind of compile-time polymorphism because we can switch between NS having the same functions and is faster as well. BTW boost::function is twice as expensive as virtual for this test.I like the NS solution.

QuoteOriginally posted by: outrunyou might like this:the Fastest Possible C++ DelegatesFrom the same place.The Impossibly Fast C++ Delegates.I my test they turned out to be somewhat slower than virtuals, even slower than boost::function.

Quoteyou might like this:the Fastest Possible C++ DelegatesQuoteFrom the same place.The Impossibly Fast C++ Delegates.I my test they turned out to be somewhat slower than virtuals, even slower than boost::function.boost::function is very flexible and if you don't call too many of them too often then it is fine. They cannot be inlined. They are slower than normal functions.

What do you think of this: pure virtual member function that _have_ a body in the base class! 1. Bug?2. Feature?3. Who overlooked this?4. Pure virtual functions don't exist.VS 2010 tested.

According to this -- http://www.objectmentor.com/resources/a ... abcpvf.pdf -- it's fine:"Pure Virtual FunctionsIn C++, pure interfaces are created by declaring pure virtual functions. A pure virtual function is declared as follows:virtual void Activate() = 0;The = 0 on the end of the declaration is supposed to represent the fact that the function has no implementation. However, as we will see, implementations are sometimes provided.[...]PURE VIRTUAL IMPLEMENTATIONSSometimes it is convenient for pure virtual functions to have implementations. C++ allows this. The implementation is coded in exactly the same way as the implementation of any other member function:void Actuator::Activate(){/* Do something clever here */}There are not very many good reasons to supply implementations for pure virtual function. After all, a pure virtual function represents a pure interface whose implementation would make no sense in the context of the abstract class. But sometimes there are exceptions."Some more comments:http://stackoverflow.com/questions/2089 ... tionHere's an interesting related study:http://www.artima.com/cppsource/pure_virtual.html

Well if the destructor is a pure virtual function you must have it implemented. If not, the linker complains.