Too big difference in speed of binaries ,produced with different compilers (C++) [closed]

I have used mainly gcc in my last project and today I decided to benchmark different compilers' results.

I used the same source for gcc 4.5,MSVC from Visual Studio 2010 and Intel C++ .The program gets its input from a text file,makes a lot of string manipulations and writes the output to another text file.

I counted only time o

EDIT: benchmarking:

I counted only time of executing the algorithm ,not of file io. Basically I put

    clock_t clock0;
    double z;
    clock0 = clock();

    double clock1=(clock() - clock0) / (double) CLOCKS_PER_SEC;

It started with a small file(around 200 lines) and there was almost no difference (around <0.15 sec ).With a 4K lines file MSVC's output worked for 1.23 sec compared to 0.1 for gcc's output.

Finally I tested with 60K lines file :

  (program compiled with ) Intel compiler ran for 6.7 sec and with  gcc : 1 sec.

Now I just wonder why there is such a difference (that was without optimization flags) and what can be the reason about that.(I used c++0x standard - but obviously Intel compiler supports it).I am not sure if the fact that my co开发者_高级运维de compiles to fast binary only with one compiler isn't alarming

EDIT 2:

I didn't compile it in debug mode with MSVC or Intel

Here we go again...

The STL implementation from Visual Studio does really heavy iterator checking in debug mode. Then there are the normal debug checks for stack and register integrity. It also does this when no optimizations are turned on afaik. GCC can only be so fast if it does no (or little to no) debug checking whatsoever. Also, taken from my comment:

benchmarking without optimization flags is kinda pointless

Or you tricked us and compiled in release mode with gcc and in debug mode with Visual Studio / Intel C++...

If you didn't use optimization flags, then the answer can be easily explained by poor debugging facilities in the faster compilers. Micro-benchmarks like this are generally not valid anyway, and it's definitely not valid if you don't post the code.

You could likely provide a far bigger speed difference than changing compiler by using algorithmic optimizations, custom memory allocators, and that sort of thing.

Don't measure performance with optimizations disabled.

The reason for not compiling with optimizations is usually for ease of debugging, and so the compiler will generate debug-friendly code when optimizations are disabled. For some compilers (MSVC, for example), that involves adding a lot of runtime checks to help you catch more errors.

If you want to compare performance, do it as if performance mattered: by telling the compiler to worry about performance and optimize the code.

I'm not sure how you compiled the g++, nor what g++ does with regards to libraries, but clock() with VC++ is broken; it measures wall clock time, and not CPU time, as required by the standard. It sounds like g++ is picking up a correct version of clock(), and Intel is using the one in the VC++ library. (When reading a large file, most of the time will not be CPU time.)