C++ Compilers' Performance
Implementation's quality

Authors / Авторы: Sergey Satskiy
Motorola Inc.
Roman Plekhanov
Motorola Inc.

Publication date / Опубликовано: 30.09.2006
Version / Версия текста: 1.10

Introduction

There is a certain number of publications available in the Internet which compare performance of a code generated by different C++ compilers on various hardware platforms for some test tasks (e.g. a review on the "coyote gulch" site). This type of reviews is also issied by compiler manufacturers to draw attention to their products. Surely this type of reviews is very practical; they help to take into account a factor of the generated code absolute performance while selecting a development toolchain.

At the stage when a compiler has already been selected, however, a developer faces a question of what approach should be used for implementation a particular piece of code. As soon as any C++ compiler is able to compile a C code as well there is always a choice: to use new language features provided by C++ or to implement the same functionality in pure C. In other words there is a question of overheads which are introduced by new C++ features or how well the corresponding feature is implemented by a certain C++ compiler.

There are not too many comparisons of a performance a C++ code and a functionally equivalent C code which are generated by the same compiler. In fact there is only one well known source - it is "Technical Report on C++ Performance" issued by WG21 committee. The report gives specific numbers and the used test code while the compilers are left anonymous. The logic of the committee is understandable however practicing engineers need more specific information.

The above mentioned report is taken as a basis for the article. The set of tests was extended; the code was modified in some cases and the more detailed analysis of the incurred overheads is provided. In most cases the exact figures are given for each pair: a compiler - a hardware platform. The reader may get an answer not only for the question "what overheads are incurred by that language feature?" but for the question "how big are those overheads?" as well.

Hardware platforms, compilers and test results representation

The table below describes tested hardware platforms, compilers and operating systems.

The same multiplatform compiler can show different performance results for the code generated for different hardware. The performance depends considerably on the hardware specific optimizer and hardware specific code generator. This is the reason why each compiler was tested on various hardware if it was applicable.

While developing test code and its execution environment all the efforts were applied to:

• To reduce requirements to the installed software
• To simplify the process of adding a new compiler into the list of tested ones
• To simplify the process of adding a new test

In fact the main requirement is to have GNU make, awk and bash utilities installed.

The idea behind covering gcc 2.95 is to look at how gcc compilers progressed over the last years. In spite of the fact that this version is still in use it is rather related to C than to C++. As soon as C++ comes up developers prefer to use newer gcc releases in most of the cases.

The gcc series 2 version on the IA-64 platform differs to the versions of this compiler on other platforms. This is because of the fact that gcc 2.95.3 configuration script does not support the platform. The Linux provider however supplied gcc 2.96 for this platform so this version was used in tests on IA-64.

The following model was used to analyse the results:

• Each C++ feature was associated with a functional equivalent written in C
• A time spent on execution C and C++ versions was collected
• C execution time was expressed as percentage of the C++ time

So if a number in a table is above 100 it means that C++ revealed better performance. In case if the analysis way differs to the described above a description is provided separately for each case.

Overheads Sources

Three types of overheads might appear if C++ is used instead of C:

1. Run-time overheads which consist of the following:

• CPU(s) time spent on the generated code execution
• RAM amount required for the generated code execution

1. Compile-time overheads which consist of the following:

• Time spent on the code compilation
• RAM amount required to a compiler
• Disk space required to store object and probably temporary files

1. Disk space overheads. This is the size of the generated executable file and possibly dynamic libraries.

Nowadays RAM and disk space is getting to be a cheap resourse in many cases. So the most interesting aspect of the overheads is the generated code performance. Compile-time overheads are mitigated quite often by crosscompiling on power host computers. There are at least various ways of avoiding compile-time overheads problems.

Bearing in mind the speculations above the main focus will be on the generated code performance while the size related figures will be provided just as a reference.

C++ Features that do not Imply Significant Overheads

Namespaces and explicit type convertions are such features.

Strictly speaking namespaces may introduce overheads of increasing compilation time. This increase however is neglible small to talk about this seriously.

C++ introduces 4 new explicit type conversion statements: static_cast, const_cast, reinterpret_cast and dynamic_cast. First 3 influence the compilation stage only while the dynamic_cast may introduce run-time overheads. These overheads are related to the analysis of RTTI information and will be discussed later in a separate chapter.

Abstraction Layers Penalties

Alex Stepanov Test

Alex Stepanov, the STL inventor, developed tests to estimate abstraction layers penalties. The test does semantically the same calculations using 13 different ways and the execution time of each way is collected. The actual task is to calculate a sum of 2000 double values from an array. A C++ wrapper around pod double variable is used to introduce an abstraction layer.

struct Double
{
    double    value;

    Double() {}
    Double( const double &  x ) : value( x ) {}
    operator double() { return value; }
};

double    data[ 2000 ];
Double    Data[ 2000 ];

double_pointer and Double_pointer wrappers for pointers to double and Double are introduced similarly. The ways to fulfil the task are as follows:

0. for ( size_t  i = 0; i < 2000; ++i ) result += data[ i ];
1. accumulate( data, data + 2000, 0 );
2. accumulate( Data, Data + 2000, Double( 0 ) );
3. accumulate( double_pointer( data ), double_pointer( data + 2000 ), 0 );
4. accumulate( Double_pointer( Data ), Double_pointer( Data + 2000 ), 0 );
5. Using reverse_iterator< double *, double >
6. Using reverse_iterator< Double *, Double >
7. Using reverse_iterator< double_pointer, double >
8. Using reverse_iterator< Double_pointer, Double >
9. Using reverse_iterator< reverse_iterator< double *, double >, double >
10. Using reverse_iterator< reverse_iterator< Double *, Double >, Double >
11. Using reverse_iterator< reverse_iterator< double_pointer, double >, double >
12. Using reverse_iterator< reverse_iterator< Double_pointer, Double >, Double >

Each next calculation way increases the abstraction level. Execution time of each way is measured and the overheads are calculated as geometric mean of divisions:

Figure 1. Geometric mean of execution time ratios

The calculated value characterizes a compiler optimization quality. The smaller value - the better. Greater then one values mean loss of performance with new abstraction layers.

The results are given in the tables below.

The -fomit-frame-pointer optimization key is introduced to give a compiler a chance to use all the available CPU registers effectively.

The results are that modern compilers eliminate abstraction layers overheads well with optimization switched on. Gcc series 3 demonstrated strange results on IA-64 and ARM platforms. It seems that performance raises with new abstraction layers. The analysis revealed that most probably the root cause for this is that a not effective code was generated for C version i.e. for the way #0.

The Intel's compiler also demonstrated unexpected result on the IA-64 platform. The higher optimization led to worse performance. The analisys of the case revealed that the C performance increased significantly while the C++ performance did not change.

The whole picture is still bright for modern C++ compilers. The generated C++ code is about the same powerfull as its C functional equivalent.

Functors vs Function Pointers

Abstraction layers might increase C++ performance in comparison to C one in some cases. For example, functors may win versus function pointers. Let's take sorting as a typical programming task. C library provides the qsort function which requires a pointer to an element comparing function to be passed as an argument. In case of C++ the std::sort algorithm could be used. The algirothm accepts various ways of the elements comparison.

The tables below give the various sorting options performance results.

It is easy to see that C++ wins against C significantly. The win might reach 600% on the IA-32 platform. It is also obvious that the win on the IA-32 platform is higher than on other platforms in general. This might be a kind of evident of the compilers maturity on this platform.

The usage of functions pointers as the way to compare elements is slower than other ways in most of the cases. So if there is a choice between function pointers and functors it is preferably to use functors.

It is worth to say that sorting which uses the native ::operator < (:) is faster than other options in most of the cases.

Templates

Instantiated templates work at run-time at the same speed as non-template equivalent classes so the run-time overheads are the same as it was discussed in "Abstraction Layers Penalties" chapter.

At the compilation time templates may introduce considerable overheads however. Moreover disk space overheads may also appear due to the "bloating code" effect.

There are at least three main approaches to implementation of the C++ template instantiation:

• "Greedy"
• By request
• Iterative

The instantiation process may depend considerably on the way an application or a library is built. Suppose that a classic scheme with two components - a compiler and a linker - is used. A compiler translates source code files into object files that hold a machine code and have cross references to other object files and libraries. A linker combines object files resolving references into a single executable file. C and C++ compilers handle each compilation unit independently. A straightforward approach to templates implementation would suppose instantiation of non-inlined functions for each compilation unit. So there is a chance that more than one object file will hold function bodies with the same names. The linkage stage will fail in this case.

Let's consider in details how each of the mentioned above instantiation approaches resolve the described problem and what overheads come up to the picture.

"Greedy" Instantiation Approach

The greedy instatiation allows creating duplicates in many object files however those duplicates have a special mark (e.g. "instantiated template that should be linked"). As soon as linker finds duplicates it keeps only one throwing away all the others. This approach has some drawbacks:

• A compiler may spend time on generating and optimizing actually the same function bodies while the only one will be used. The object files size may also be increased.
• The generated template instantiations may vary a bit for the same specialization so the instantiated bodies are not usually checked for binary identity. Thus it is possible that not the best dublicate will be selected from many which came from compilation units compiled with different optimization keys.

There are advantagies as well:

• The traditional scheme - a compiler and a linker - is kept unchanged; there are no new elements. There is still a correspondence: one translation unit - one object file.
• Implementation of inline functions is relatively easy because duplicates are allowed. For example if a compiler is not able to inline all the inline function calls it keeps the function body in an object file.

So the greedy instantiation approach overheads are increased compilation and linkage time and probably increased size of object and the final executable files. There is also a chance of releasing not the best optimized code.

Queried Instantiation

This approach supposes creation and support of a special database which is used during compilation of all the translation units. The database holds information of instantiated templates specializations as well as their dependencies on the source code. The bodies of the instantiated templates are usually stored in that database as well.

In case of instantiation by request a compiler does not perform unnecessary template instantiations however there are difficulties in the implementation of the approach:

• The traditional translation scheme is not applicable any more. A single unit compilation produces more than just a single object file. The linkage stage requires not only object files but the generated instantiations of templates specializations from a database as well.
• Many compilers implement a parallel compilation which makes the template database support complicated.
• A linkage with libraries which have template specializations becomes more complicated. If a database has no information about what templates specializations are in the libraries code duplication may come up.

The main overhead here is the disk space which is occupied by the templates specializations database.

Iterative Instantiation

There exist various similar methods implementing an iterative instantiation scheme. Their specific is in using of a preliminary linker. On of them is implemented in Comeau compiler. Automatic instantiation method works as follows:

1. The first time the source files of a program are compiled, no template entities are instantiated. However, the generated object files contain information about things that could have been instantiated in each compilation. For any source file that makes use of a template instantiation an associated ".ii" file is created if one does not already exist.
2. When the object files are linked together, a program called the prelinker is run. It examines the object files, looking for references and definitions of template entities, and for the added information about entities that could be instantiated.
3. If the prelinker finds a reference to a template entity for which there is no definition anywhere in the set of object files, it looks for a file that indicates that it could instantiate that template entity. When it finds such a file, it assigns the instantiation to it. The set of instantiations assigned to a given file is recorded in the associated ".ii" file.
4. The prelinker then executes the compiler again to recompile each file for which the ".ii" file was changed.
5. When the compiler compiles a file, it reads the ".ii" file for that file and obeys the instantiation requests therein. It produces a new object file containing the requested template entities (and all the other things that were already in the object file).
6. The prelinker repeats steps 3--5 until there are no more instantiations to be adjusted.
7. The object files are linked together.

Some compilers store information about things that could have been instantiated in associated ".ti" files, also storing information about how object file is compiled.

Using this approach may result in increased link time. This increase is not dramatic though as soon as the linkage is not done on the preliminary stage. Moreover the instantiation requests files can be reused for subsequent linkages so the number of recompilations is reduced.

Iterative instantiation overheads are increased linkage time and a disk space to store instantiation requests files. Most probably the required disk space will be insignificant.

Templates Tests

The following information was collected: the compilation time, the executable file size with and without symbols information. The strip utility was used to remove the symbols information from the executables.

Two versions of the source code were tested. The first version instantiated 40 std::list containers and each container holded pointers to its own type. The second version instantiated 40 std::list containers and all the containers holded pointers to the same type. The results are in the tables below:

The interesting thing here is a confirmation of the fact that compilers made a big step to reducing the compilation time and the executable file size. In some cases the gcc compilation time reduced by factor 100 by moving from series 2 to series 4.

The ARM platform compilation time is not given because a crosscompiler was used so the compilation time depended on the host system speed (IA-32). Numbers for a single compiler on this platform are not really interesting however the table is given with the hope to extend it in the future.

Basic Class Operations

Member Functions

A member function call is roughly the same as a free function call with one additional parameter - a pointer to an object. Let's consider three options of calling a member function:

Tests compare function calls with an integer argument which is shown as "i" in the table above. The "ps" in the table is a pointer while "s" is an object.

The test results are given in the tables below.

C++ performance on the IA-32, Sun and ARM platforms does not differ from the C performance more than on 10% in most of the cases. The results on the IA-64 platform are not so even. The C++ performance significantly depends on a particular case and varies from overwhelming of C++ (gcc series 4 with max optimization for notation '.' - 207%) till a major loss (gcc series 4 with max optimization for static member functions - 33%).

Virtual Functions - C and C++ Versions

Virtual functions as well as non-virtual could be called using notations '->' and '.'. As soon as pointers to virtual functions are stored in a separate table a virtual function call is about the same as a call a function with one additional parameter via a pointer which is stored in an array. The table below describes C++ and C calls options.

Here "I" is an integer parameter, "p" is a functions pointers array, "ps" is a pointer to an object and "s" is an object.

The test results are given in the tables below.

It is possible to notice that C++ almost always wins in case of notation '.'. Sometimes C++ wins at the rate of 5 - 7. Most probably it is because of an optimizer implementation specific. In case of C++ the optimizer is able presumably to perform de-virtualisaton while in case of C there are no tries to do a similar thing.

In case of notation '->' C wins a bit except of rare cases. Thus gcc series 4 on the IA-32 platform without optimization generated better code for C++. The Intel's compiler on the IA-64 platform without optimization demonstrated lack of C++ performance in turn.

Virtual and non-virtual Functions - C++ Only

Overheads on calling virtual and non-virtual C++ member functions can be different. The tables below give the results of comparing virtual and non virtual functions calls. Each table cell shows a percentage of virtual functions calls performance. A number greater than 100 means that virtual functions calls are faster than non-virtual.

The fact that the notation '.' virtual and non-virtual functions calls performance is about the same can be explained by the ability for compilers to perform de-virtualisation of the virtual functions calls.

In case of the notation '->' virtual functions lose in most of the cases. Sometimes the loss is dramatic - Intel's compiler lost at the rate of 16 on the IA-32 platform and gcc series 4 lost at the rate of 6.

In some cases (e.g. gcc series 4 on Sun, -O3) the significant loss of virtual functions calls performance in comparison to the performance of non-virtual functions calls can be explained by the fact that the compiler was able to inline the non-virtual function while the virtual function was not inlined.

Inline Functions

Inline functions is a C++ alternative to C macroses. The tables below give performance comparison of those alternatives for notations '->' and '.'.

With optimization switched off compilers even don't try to inline functions calls. First two lines in each of the tables confirm this assumption.

With optimization switched on the results differ a lot for various platforms and cases. The most stable results are demonstrated by gcc series 4 on the IA-32 platform - inline functions and macroses have the same performance. The Intel's compiler demonstrates loss of inline functions performance for notation '->' on the IA-32 platform.

The IA-64 platform revealed both wins and losses. For example the Intel's compiler inline functions win for notation '.' while gcc series 4 inline functions loss significantly for notation '.' and -O2 optimisation.

Inheritance and Virtual Functions

Additional run-time overheads may come up for calling virtual functions in comparison to calling non-virtual ones. There could be both a CPU overhead and a RAM overhead. The overheads could vary for various inheritance cases - single and multiple - and even for various sequence of inheritance. Let's consider in details what is going on in various cases for a typical C++ implementation.

Single Inheritance

Suppose that the following type is used as a base one.

struct Base
{
    Data          d1;

    virtual void  f( void );
    void          g( void );
};

Objects of the Base type will be allocated in RAM as shown on the figure below.

Figure 2. Allocation of an object with a virtual function

A virtual functions table (vtbl) for the Base type holds a pointer to a virtual function f and the data members are extended with a pointer (vptr) to the vtbl. What exact elements stored in the virtual functions table is not important for now. That could be pointers, deltas for "this" pointer correction or something else.

Now suppose that there is type Derived which inherits from Base:

struct Derived : public Base
{
    Data          d2;

    virtual void  f( void );
    virtual void  h( void );
};

Objects of the Derived type will be allocated in RAM as shown on the figure below.

Figure 3. Allocation of an object in case of a single inheritance

The base type mebers are allocated first followed by the derived type members. The vtbl is extended with one more pointer &Derived::h and the &Base::f is replaced with &Derived::f.

It is necessary to notice that in case of allocating an object of type Derived (i.e. in case of single inheritance) the addresses of both Base and Derived objects are the same. One more interesting feature is that it is possible to store only one copy of the vtbl for many allocated objects of the same type. That reduces run-time memory overheads and possibly disk space overheads.

Multiple Inheritance

Suppose that there are two base types: Base1 and Base2:

struct Base1
{
    Data          d1;

    virtual void  f( void );
};
struct Base2
{
    Data          d2;

    virtual void  f( void );
    virtual void  g( void );
};

Now suppose that DerivedMultilpe type derives from both Base1 and Base2:

struct DerivedMultiple : public Base1, public Base2
{
    Data          d3;

    virtual void  f( void );
    virtual void  g( void );
    virtual void  h( void );
};

Allocation of the objects of the Base1 and Base2 types is similar to the allocation of the type Base objects as shown on figure 2. The interesting part is the DerivedMultiple type objects allocation:

Figure 4. Allocation of an object in case of multiple inheritance

"s" marks a size occupied by the Base1 type object.

The Base1 members are allocated in memory first followed by the Base2 members. The DerivedMultiple members follow Base2 members. The most important detail here is that the DerivedMultiple object has two addresses which are marked as a1 and a2 on the figure. The addresses appear when a developer writes a similar code similar to the following:

DerivedMultiple *    Object( new DerivedMultiple );  // Corresponds to a1
Base1 *              base1( Object );                // Corresponds a1 as well
Base2 *              base2( Object );                // Corresponds a2

When the virtual function f is called, however, it is required to pass the correct "this" pointer i.e. a pointer to the object which was originally created. This is the a1 pointer in the example. If there is the a2 pointer additional actions are required - the a2 pointer should be corrected to the size of the base1 that is "s". That is why the vtbls on the figure are extended with one more information element. It is the value for the "this" pointer correction in case of virtual function calls.

A similar situation appears when the described hierarchy is used as follows:

Base2 *  base2a( new Base2 );
Base2 *  base2b( new DerivedMultiple );

base2a->f();
base2b->f();

The Base2 * in the example above can point to the Base2 object or to a part of the DerivedMultiple object. In the first case of calling virtual function f the Base2::f will be called while in the second - DerivedMultiple::f. As soon as base2b points to the Base2 part of the DerivedMultiple the "this" pointer should be corrected to make it pointing to the DerivedMultiple object. The correction value is s.

Analysing the description above it is easy to see that the RAM (storing vtbls) and CPU (analysis of those tables and possibly "this" corrections) run-time overheads come up when virtual functions are used. Funtion inlining will not either working in case of virtual functions.

It is worth to say that quite often a virtual function is called in a context when a compiler has all the required type information which makes it possible to convert a virtual function call into an ordinary function call. This kind of optimization is called de-virtualisation and allows moving from an indirect call via a table of function pointers to a direct function call.

There are at least two approaches which can be employed by compilers to implement virtual functions. The first one supposes storing deltas for the "this" pointer as shown on the figures above. The second approach supposes generation of small piece code called "thunk" which corrects the "this" pointer. In cases if the correction is not required the corresponding thunk code gets empty which optimizes a virtual function call.

Test Results

As it was mentioned above the functions calls overheads can be different for the cases of single and multiple inheritance. The overheads can be also different for virtual and non-virtual functions. The sequence of the inheritance may also influence the overheads. The test results for all the mentioned cases are given below.

The diagram below shows two types hierarchies which were used in tests. The branch which is related to the Base1 base class in case of multiple inheritance will be referred as the "first" branch for the further discussion. The branch which is related to the Base2 base class will be referred ans the "second" branch correspondingly.

Figure 5. Functions calls

The performance of the virtual and non-virtual functions calls is measured in the tests for various inheritance cases. In case of multiple inheritance the performance is measured twice for both branches of inheritance.

The table below provides functions calls performance in case multiple inheritance in comparison to the case of single inheritance. That is a number larger than 100 means that a function call in case of multiple inheritance if faster than in case of a single inheritance.

It is possible to notice that the sequence of inheritance does not affect the performance of calling non-virtual functions considerably for the modern compilers. The picture is different for the virtual functions. The Intel's compiler with the optimization switched on demonstrated the same performance of a virtual functions calls regardless of the inheritance sequence and it was about the same as for the performance of a virtual functions calls in case of a single inheritance.

Gcc compilers series 3 and 4 with the optimization switched on demonstrated a minor difference in performance of virtual functions calls depending on the inheritance branch. The second branch performance lost was between 10% and 30% in comparison to virtual functions calls in case of a single inheritance. Such losses are practically neglected in case of the first inheritance branch.

Virtual Inheritance

In case of virtual inheritance data structures become even more complicated. Let's consider the following hierarchy:

Figure 6. Type hierarchy with virtual inheritance

Mediator1 and Mediator2 inherit virtually from the TopBase. Suppose that the types are defined as follows:

struct TopBase
{
    Data          d1;

    virtual void  f( void );
};

struct Mediator1 : virtual public TopBase
{
    Data          d2;

    virtual void  f( void );
    virtual void  g( void );
};
struct Mediator2 : virtual public TopBase
{
    Data          d3;

    virtual void  f( void );
    virtual void  h( void );
};

struct DerivedVirtual : public Mediator1, public Mediator2
{
    Data          d4;

    virtual void  f( void );
    virtual void  g( void );
    virtual void  h( void );
};

Objects of the TopBase type are allocated in memory similar to the way shown on figure 2. The allocation of the Mediator1 type objects for a typical implementation is shown below. The Mediator2 objects are allocated similar to the Mediator1 ones.

Figure 7. Allocation of an object with a virtual base class

The virtual base class members are located after all the other data members. This is done to unify run-time analysis of the vtbl regardless of what exact object type (Mediator1, Mediator2 or DerivedMultiple) was created. The Mediator1 vtbl is extended with a pointer to the virtual base object pTopBase. Access to the virtual base members is provided not directly but via pTopBase pointer in the vtbl. The indirect access leads to run-time overheads.

The figure below shows the DerivedVirtual objects allocation.

Figure 8. Allocation of an object with a virtual base class in case of multiple inheritance

Data members of a virtual base object appear in memory once so the exact location of this portion is known only to the really allocated object. It is the reason why a pointer to the beginning of the virtual base object is stored in the vtbl of each deriving objects.

The described above approach supposes unified access to the virtual base object members - via a pointer in the vtbl - regardless of what exact object is allocated whether it was Mediator1, Mediator2 or DerivedMultiple. It is also valid for the case when the DerivedVirtual object was created and a pointer to that object was converted to the pointer to Mediator1 or to Mediator2 objects.

Some compilers hold a pointer to the beginning of a virtual base object not in the vtbl but as an additional data member.

Tests Results

The virtual inheritance may lead to a loss of performance in comparson to a usual inheritance. The loss may come up in case of calling member functions or accessing data members of a virtual base class.

A virtual base class may have both virtual and non-virtual functions. The performance of calling those functions can be different.

The test results are grouped by relation to virtual and non-virtual member functions. For non-virtual functions the results are given for virtual and usual single inheritance. A function call incremented a member of a usual or a virtual base class. The table below refers to the cases of incrementing a single member of a base class as "option 1". For virtual functions the results are also given for virtual and usual single inheritance. Two options of functions calls which are illustrated below were used.

Figure 9. A virtual function call, option 2a

Figure 10. A virtual function call, option 2b

The table below provides the functions calls performance in case of virtual inheritance in comparison to the functions calls performance in case of usual inheritance. A number greater that 100 means that the function call in case of virtual inheritance is faster than in case of usual inheritance.

The performance of functions calls in case virtual inheritance loses significantly against the case of a usual inheritance in most of the cases regardless it was a virtual or a non-virtual function.

The fact that "option 2a" call was almost always faster than "option 2b" call means that the spent time depends on the number of times the virtual base class data members were accessed in the function. Theoretically it is possible to get rid of this dependency if compilers stored a pointer to the virtual base class object at the beginning of the function.

RTTI

The most interesting case of the RTTI usage is convertion tries which suppose type hierarchies analysis. Such an analysis is performed when dynamic_cast is used. The C programming language does not support explicitly type hierarchies so it is difficult to find a functional equivalent. Due to these difficulties there will be only theoretical analysis of possible RTTI implementation and implied overheads without comparison of performance between C and C++ implementations.

Suppose that there is a type hierarchy shown below (it is necessary to note that the E type must be polymorphic).

Figure 11. RTTI hierarchy

Suppose also that there is the following C++ code:

E *       pE( new E );
B *       pB( pE );

D *       pD( dynamic_cast< D * >( pB ) );

It is obvious that the conversion at the last line must be completed successfully. The obstacle is that the argument of the conversion is a pointer to type B which is not a direct base type of type D. In order to complete the conversion successfully it is necessary to walk down the type hierarchy to the type E and then to complete the conversion. The described hierarchy traversal could be supported by RTTI implementation shown on the figure below.

Figure 12. Typical RTTI implementation

The vtbl is extended with one more pointer which helps to retrieve type information. Information about all the types is stored in a separate table. Having a pointer to B (pB) the beginning of the really created object is found at the first stage. Then a table with information of all the type E predecessor types is located. Then the target type_info is compared consequently with all the type_infos from the predecessors list. If type_infos are equal at some stage then the conversion is possible.

So the run-time overheads on supporting RTTI are as follows:

• RAM for storing more pointers in the vtbls
• RAM for storing RTTI table
• CPU time for searching the RTTI table
• CPU time for type_info comparisons

Quite often the comparisons do not require expensive string comparisons however there are compilers that use strings.

Exceptions

C++ provides exceptions for error handling. Traditional C alternatives are as follows:

• Return code analysis
• Calls of error handling functions
• Longjump-ed error handlers
• Passing an additional object pointer to each called function. The object holds the current state information.

Exceptions in C++ are usually implemented using one of two approaches: a table approach and a code approach.

The table approach supposes creation of special tables on the compilation stage. Those tables associate PC counter value ranges with actions that should be executed in case if an exception is generated. Those actions could be passing the execution control to the corresponding catch block, calling local objects destructors, stack unwinding etc. The main run-time overhead in case of the table approach is RAM for storing prepared tables.

The code approach supposes generation on-the-fly a list of actions which should be executed in case of exceptions. The list of actions is similar to what is stored in tables in case of the table approach. The main run-time overhead in case of the code approach is the CPU time. The dynamically generated actions take much less RAM than static actions tables in case of the table approach.

The most popular and simple way of error handling in C is the return code analysis. C code is usually similar to the following:

int  f( void );
. . .
{
    int    ReturnValue;

    . . .

    ReturnValue = f();
    if ( ReturnValue != 0 )
    {
        /* Process error some way */
    }

    /* No errors */

The main run-time overhead in the code above is the CPU time spent on comparing the return code with some value and possibly a jump. This comparison is performed regardless whether the f function completed successfully or not. In case if C++ exceptions are used there is no return code so there is no if statement. Therefore if the function f completed successfully there will not be run-time CPU overheads. The CPU overheads however in case if function f generated an exception will be most probably higher. It is possible to measure time for an exception processing in C++ case and for error code checking for C. The ratio of those times will give some value. The value means what the minimum number of successful C++ calls of function f should be done to make the C++ code more effective than the C equivalent in terms of CPU consumption. For example, if the value is 220 that means that if an exception is generated rearer than one time per 220 calls then the C++ code will work faster than return code analyzing C version.

The tables below demonstrate test results with the ratio of time spent on an exception handling to time spent on return code analysis.

The values in the tables can be used by developers while making a decision for a certain way of error handling. An interesting fact is that gcc compilers demonstrate similar results while the Intel's compiler loses up to 2.5 times against gcc.

Gcc series 2 on the IA-32 platform with optimization switched on generated a code which aborted at run-time so the corresponding cells in the table has N/A.

IOStream Library

The C++ input/output library has a reputation of not effective one. The library performance migh be affected by the syncronisation mode with the C input/output streams. The mode is on by default.

Test code performed file input/output operations for decimals, heaxadecimal and float values for both synchronization modes - switched on and off. The figures below show the results. The vertical axis is the time spent on the operations so the higher bar is the worse performance it means.

Figure 13. IA-32 input

Figure 14. IA-32 output

Figure 15. IA-64 input

Figure 16. IA-64 output

Figure 17. Sun input

Figure 18. Sun output

Figure 19. ARM input

Figure 20. ARM output

C++ I/O performance is worse than C in all the cases except one. The worst result is slowing down at the rate of 600%. The exception is gcc series 2 C++ I/O performance however some sources explain it by incorrect implementation of the I/O streams in term of C++ standard requirements. Besides the gcc series 2 is out-of-date now and is not considered seriously by developers as a candidate for C++ projects.

Conclusion

Modern C++ compilers demonstrate high quality of the new language features implementation on all the tested platforms. The C++ code does not practically lose against C and sometimes allows reaching a higher performance. The regrettable exception is the C++ input/output however there is a workaround. The C++ compiler will easily compile C-style input/output code. And we surely have a hope on the compilers developers. The C++ input/output library will be gaining better and better anyway. Bearing in mind that C++ directly supports more programming paradigms than C the latter will have less and less chances to be used in complicated projects.

Tests Automation

To make the process of collecting test results on various platforms for different compilers and various compilation keys a set of scripts was developed. The scripts could be easily extended with new tests, new compilers and new combinations of compilation keys. In order to do that some changes should be done in the files described below.

compilers.list File

The file is located at the top of the framework directories structure and holds a list of the tested compilers. An example of the file is given below:

# File format:
# first   compiler vendor
# second  c compiler path
# third   c++ compiler path

gcc4.1.1
/home/twinpeek/compilers/gcc/4.1.1/bin/gcc
/home/twinpeek/compilers/gcc/4.1.1/bin/g++

intel9.1
/home/twinpeek/compilers/intel/9.1.038/bin/icc
/home/twinpeek/compilers/intel/9.1.038/bin/icpc

The example defines names and pathes to two compilers - gcc series 4 and Intel's compiler. The comment lines start with the '#' character. Empty lines are allowed.

projects.list File

The file is also located at the top of the directories structure and holds a list of projects which are included into the tests. An example of the file is given below:

# File format:
# Pathes to the projects

abstraction_penalty/stepanov_test
abstraction_penalty/mitigation
abstraction_penalty/templates_boat_diff
abstraction_penalty/templates_boat_same

The example defines four projects which are specified in a form of relative pathes. The comment lines start with the '#' character. Empty lines are allowed.

optimization.info File

A number of optimization keys sets which are used with each of the compilers is defined separately for each of the projects. That is why the optimization.info file is located in the home directory of each project. For example the optimization.info file for the abstraction_penalty/stepanov_test project can look as follows:

0
1
2

Each line gives a name of the optimization keys set. Here we have digits as the names.

Optimisation Keys

The search of the compiler optimization keys which correspond to each of the sets from the optimizations.info file is done as follows. A file name is formed using the following rule:

<CompilerName>_opt<OptimisationKeysSetName>.flags

For example for the Intel's compiler and the last optimization keys set the following name will be formed:

intel9.1_opt2.flags

The search of this file will start with the "flags" directory in the corresponding project home directory. If the file is not found in that folder the search will continue in the "flags" directory which is located at the top of the framework directories structure. The file should define two variables - for C and for C++ - with the corresponding optimization keys. For example the intel9.1_opt2.flags file can look as follows:

CFLAGS=-O3 -fomit-frame-pointer
CPPFLAGS=-O3 -fomit-frame-pointer

Such an approach supports ability to have common optimization keys for all the projects and ability to tune optimization keys individually for a specific project.

Running

To run compilation of all the projects and collect the tests results the following command could be used:

./do_test.sh > TestResults.log

References

1. GCC 4.0. A Review for AMD and Intel Processors. http://www.coyotegulch.com/reviews/gcc4/index.html
2. Technical Report on C++ Performance. http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf
3. David Vandevoorde, Nicolai M. Josuttis. C++ Templates. The Complete Guide. http://www.amazon.co.uk/C++-Templates-Complete-David-Vandevoorde/dp/0201734842
4. Bjarne Stroustrup. The C++ Programming Language, Special Edition. http://www.amazon.co.uk/C%2B%2B-Programming-Language-Special/dp/0201700735
5. Scott Meyers. Effective C++: 55 Specific Ways to Improve Your Programs and Designs http://www.amazon.co.uk/Effective-C%2B%2B-Specific-Professional-Computing/dp/0321334876
6. Scott Meyers. More Effective C++: 35 New Ways to Improve Your Programs and Designs http://www.amazon.co.uk/More-Effective-C%2B%2B-Professional-Computing/dp/020163371X
7. Stephen C. Dewhurst. C++ Gotchas: Avoiding Common Problems in Coding and Design http://www.amazon.co.uk/C%2B%2B-Gotchas-Addison-Wesley-Professional-Computing/dp/0321125185
8. Jonathan L. Schilling. Optimizing Away C++ Exception Handling. http://sco.com/developers/products/ehopt.pdf