[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
improvement.
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