[LC++]OS Programming

Davide Bolcioni 9odb6x3rfr001 at sneakemail.com
Thu Oct 3 05:42:01 UTC 2002

Jan Reimers reimers at infoserve.net [mltuxcpp/linux-cpp list] wrote:

> I often here this argument being made, but have you acually tested it for 
> C++? The extra level of indirection is on the order of a few (2-4) clock 
> cycles on modern processors, so unless your calling lots of virtual functions 
> that don't do any processing you are unlikely to notice the effect of virtual 
> dispach.

Yes and no; modern processors are complicated and *much* faster than 
memory. For example, I remember a paper showing distinct improvement
in performance (about 8% IIRC) replacing a virtual call with a compiler
generated switch-on-typeid constructed according to profiling
information: knowledge of the exact type allowed the compile better
inlining chances.

> Also, polymoprhic function calls replace one of two things in non OO 
> programming 1) an if/switch statment, 2) calling a function from an array of 
> function pointers.  So there is no free lunch when the system design requires 
> runtime decisions.

while case (2) should make no difference, case (1) is debatable: while the
penalty for a mispredicted branch is staggering, hinting and scheduling
allow the compiler some room for optimization which is simply not there
with virtual calls.

> I think the main reason OS's are still mostly written in C is the maturity of 
> the standards and compiler technology.  Most notably there has only recently 
> been a standardization of the C++ ABI, but nobody has implemented it yet.  
> g++ is working towards that goal.

In my opinion, while a standard C++ ABI is nice, the point about lack of 
maturity applies to C++ optimizations: there is still much room for

As far as performance goes, however, in my opinion the one advantage of
C++ over C is in templates; I would not advise restricting use of
templates in performance critical code, if the necessary expertise is at 
hand to fight bloat.

Davide Bolcioni
There is no place like /home.

More information about the tuxCPProgramming mailing list