Compiler Speed Issue

OK I’ve run into a problem porting our code from the 2.95.3 version of the compiler to the 3.3.1 version of the compiler using the Dinkum libaries.

The problem is occurring during run time of our application. It’s now so slow that we are missing hard real time committments to the hardware that is causing all kinds of havoc.

After a lot of looking at code and trying a lot of tests I have come up with the following question/issue:

Here is a simple test program I wrote to illustrate the problem:

#include
#include <stdio.h>
#include <stdlib.h>
#include

using namespace std;

const std::string s_volumeString = “Volume”;

int main()
{
std::string name = “Volume1fdgfdgdf”;
int val = 0;

for (int i=0; i<1000000; i++)
{

// val = name.compare(0, (s_volumeString.length()-1), s_volumeString, 0, (s_volumeString.length()-1));
val = name.compare(s_volumeString, 0, (s_volumeString.length()-1));

    if (val == 0)
    {
        cout << "Strings are equal" << endl;
    }
    else
    {
         cout << "Strings are not equal " << val << endl;
    }

}
	
return 0;

}

If you compile this code using the following options (the ones we use):

$ qcc -V2.95.3,gcc_ntox86_gpp -lang-c++ -D_PTHREADS=1 -g -w8 -Wall
-Wno-deprecated -Werror test.cpp

and then do a ‘time a.out > x’ I get numbers of:

16.70s real 3.27s user 0.96s system

on my server.

If I then compile this same code using the following options (the ones we want to switch to and to get this example to compile you need to comment out the ‘val’ line and uncomment the other ‘val’ line):

$ qcc -V3.3.1,gcc_ntox86_cpp -lang-c++ -D_PTHREADS=1 -g -w8 -Wall
-Wno-deprecated -Werror test.cpp

and then do a ‘time a.out > x’ I get numbers of:

17.59s real 4.19s user 1.06s system

on my server.

Looking at the user time which is the CPU time needed I can see it’s a full 28% slower using the new compiler and libraries.

In actual real experience timing with our application we are seeing times of approximately 75% slower using the new compiler (there we use the STL libaries too plus stuff like in the example above).

I thought a new compiler and set of libraries would be at least as fast as the old ones.

Does anyone have any idea why everything is so much slower under the new compiler and libraries and is there some kind of flag to turn on to speed things up? If not, we are going to have to abandon our port to 3.3.1 because our app can’t function with the delays.

TIA,

Tim

You should use -O option (0,1,2) to enable optimisation (with both 2.9 and 3.3).

Mario,

Even with -O (I didn’t know you could add a 1,2 and 3 after it) the 3.3.1 compiled version of our code runs slower that the 2.95.3 version running without a -O!

Something has changed in either the Dinkum libs or the compiler itself to dramatically slow down some or all of I/O, Std Libs or STL.

I was hoping some one might know what it is and what can be done about it.

Tim

Tim, not to directly answer your question…

Since it appears that you may be targeting x86 only, I would think that the investment in the Intel compiler might be worth your while (should produce considerably faster executables than 2.95 and should also be 100% ANSI C++ to boot).

Just a thought…

Rennie

what are you measuring in your testcase? It would appear to be mostly the implementation of iostreams.
I notice you are compare 2.95.3 with the gnu libstdc++ vs 3.3.1 and the dinkum libcpp too.

Colin,

Yes, it is mostly a comparison of I/O streams.

When we switched compilers we switched to the Dinkum libs because of issues encountered with the GCC 3.3.1 libraries not being thread safe (I noted that in another thread here).

Your right that the I/O streams are MUCH slower. That’s what we have been observing since I wrote this test case program to try to figure out what has changed so much.

The question we have now is, can anything be done to speed up the I/O streams under 3.3.1 so that they can be made to work with our application.

Tim

I think you will have to take this up with the QNX tools team, and maybe get Dinkumware involved.

I will let them know that there is an issue in any case…