CB compiler & performance question

[Fred]

My first question is related to the size of the executable.

I am trying to move over to CB from VS, as i feel more comfortable with the CB's IDE.

I have been playing with this IDE for a few days, but i have a few performance related questions
regarding the mingw compiler.

First of all, a simple console app with mingw generates about 6 kb filesize, though when including <iostream>
it jumps up to 270 kb, i have gone over all of the flags in the linker to see if i can reduce the file size but with no success.

And by looking at the exe in hex i see that it includes most standard iostream functions that i am not even using in my
test app, like free(), memset() etc. While VC8 generates the same exe at around 50 kb.

Only thing i can think of is that perhaps VC links to a core windows platform .dll and hides away allot of data from the executable,
while mingw embed everything in the exe for good compatibility.

Though a friend of mine that just uses mingw & a makefile(no IDE), can make 100 times larger programs and keep the size at 20-30 kb.
We went over the settings i used in CB with mingw and even with identical linker settings, with optimizers etc mine was still 270 kb.

example

Code

// ~270 KB
#include <iostream>
int main()
{
  printf("This is a test\n");
  return 0;
}

Code

// ~6 kb
int main()
{
  return 0;
}

My second question is related to performance speed.

As it is very important for me , that when i am moving away from VS i want to
maintain about the same computation performance in my programs, so  i did a few tests.

An example, the code bellow took about 11 sec to complete with VS's compiler, with default release
configurations, and in CB with MingW with the best combination of performance settings, in release mode
the best i could get was about 14 sec.

Code

#include <iostream>
#include <conio.h>
#include <Windows.h>
#include <Mmsystem.h>

inline float InvSqrt (float x)
{
    float xhalf = 0.5f*x;
    int i = *(int*)&x;
    i = 0x5f3759df - (i>>1);
    x = *(float*)&i;
    x = x*(1.5f - xhalf*x*x);
    return x;
}

int main()
{
    FILE *fp = fopen("Out.txt","wb");
    if(!fp)
        return 0;

    UINT StartTime = timeGetTime();
    for(UINT i = 0; i < 10000000; i++)
        fprintf(fp,"%f",InvSqrt(50));

    UINT EndTime = timeGetTime();

    printf("%f\n",((float)(EndTime - StartTime) / 1000));
    fclose(fp);
    _getch();
    return 0;
}

I don't mean to be a performance geek, but such a significant difference in small scale tests deeply concerns me.

I have heard allot of good info on MingW's capabilities so i wanted to make this post to see if there is something i could
do any differently.

Thanks,
Fred

[MortenMacFly]

These questions are not C::B related. Please ask in appropriate forums, e.g. one of the GCC/MinGW guys. In here, please ask C::B related stuff only. Thanks.

[Topic locked.]

[mandrav]

[Topic locked.]

Well, make an exception here MacFly
He 's not asking for programming help but wants to discuss about GCC in general.

[MortenMacFly]

He 's not asking for programming help but wants to discuss about GCC in general.

Ok - I didn't know we give GCC support, too. ;-)

[Ceniza]

Including iostream will always make your program bigger when using MinGW. As you have guessed, VS comes with its own DLLs which help reduce the size of the executable by making it depend on them. MinGW only links against version 6 of that DLL, so, in order to support all the things version 6 doesn't, it has to include everything in the exe. The reasons are mainly about licensing issues and DLL-Hell. For example, one of our users provides unofficial binary releases of the latest version of GCC (4.3.0). As a bonus, you can compile your programs against DLLs included with it, effectively reducing the size of your executable, but increasing the dependencies. If you want to give them a try, here's the link.

For example, compiling an empty program with the -O2 and -s flags creates an exe of 4.5 kB. Including iostream makes it 449 kB. However, the object file (created using -c) is only 1.03 kB. Compiling it with shared DLLs makes it only 5 kB (the exe). Thing is, it now depends on a DLL which is more than 1 MB. All of this with GCC 4.3.0-tdm2.

Another trick you may use is compressing your executables with UPX. As a test, using upx --best reduces the 449 kB one to 123 kB.

Now, about performance. Every compiler has its own tricks and algorithms to increase performance. The latest version of GCC is supposed to optimize better, but I haven't seriously tested it. Playing with all those optimizations flags is a bit tricky. Also, a specific program may perform better when compiled with compiler X than compiler Y, but another program may be the other way around. Even different combinations of flags may give you different results for different programs. You may want to try optimizing for a specific CPU using -march and see how it performs. You may also want to play with the -msse* flags.

I hope I've given you enough information (hopefully correct and understandable), and also more things to try

[thomas]

Since the Mandraman said we should make an exception:

You're making the same mistake as the big "d00d, gets sum real compila like VS, cuz gcc sux" crowd. You compare apples and oranges.

The version of MinGW that is bundled with Code::Blocks is from the GCC 3.4 branch which is over 4 years old (we bundle this version because it is so old, it has been profoundly tested).
The version based on the GCC 4.2 branch not only offers much better optimisation (which, unlike VS does not bail out when getting anywhere near an intrinsic or assembly), but also allows to link to the standard libary dynamically if desired, producing smaller executables (although I'd rather have bigger executables and no DLLs).
That said, choosing the right options (and coding correctly) can have a great impact on a compiler's performance too.

The code you posted is one of those well-known terribly stupid anti-optimization examples of bad compiler use which still roam the internet. Sorry if I'm saying it like this, but it has to be said. This thing is about as much of an optimization as the clever "xor swap without temporary storage" technique (that one is so "clever" that it hurts).

In your specific example, using standard functions, GCC 4.2 will produce code that runs twice as fast as that hack on any reasonably recent CPU (Pentium III or better) if you only let it.
Unless you target CPUs from the mid-1990s, there is no good reason for such a hack.

When used right, a reasonably recent version of GCC can compete with VS in every way. My deepest respect for the guys who wrote some of the best software available, and they don't even make you pay for it.

[mandrav]

He 's not asking for programming help but wants to discuss about GCC in general.

Ok - I didn't know we give GCC support, too. ;-)

Since the Mandraman said we should make an exception:

Well, this is one of those common light-hearted mis-conceptions about GCC. A discussion about this is not off-topic IMHO. If not for anything else, to produce a result for relevant search queries .

[JGM]

Code

// ~270 KB
#include <iostream>
int main()
{
  printf("This is a test\n");
  return 0;
}

Code

// ~6 kb
int main()
{
  return 0;
}

Code

#include <iostream>
#include <conio.h>
#include <Windows.h>
#include <Mmsystem.h>

inline float InvSqrt (float x)
{
    float xhalf = 0.5f*x;
    int i = *(int*)&x;
    i = 0x5f3759df - (i>>1);
    x = *(float*)&i;
    x = x*(1.5f - xhalf*x*x);
    return x;
}

int main()
{
    FILE *fp = fopen("Out.txt","wb");
    if(!fp)
        return 0;

    UINT StartTime = timeGetTime();
    for(UINT i = 0; i < 10000000; i++)
        fprintf(fp,"%f",InvSqrt(50));

    UINT EndTime = timeGetTime();

    printf("%f\n",((float)(EndTime - StartTime) / 1000));
    fclose(fp);
    _getch();
    return 0;
}

Something that i wanted to point also, is that actually on your code you are not using cout or any class related with include iostream, you are actually using the cstdio included in that file since you are only using printf.

So you should drop:

#include <iostream>

and replace it with

#include <cstdio>

that will give you a smaller executable on gcc, about 5k if i'm correct

[Fred]

Thanks for the advices, i did not mean to make this post , not CB related, in fact i thought my problem was perhaps related with the
setup between CB and the compiler, some hidden flags for example.

Also i did not mean to judge MingW vs Microsoft's compiler.. The main reason for why i am moving away from VS in the first place is
the strict licensing from MS(MFC for example, non cross platform etc), and that over the years i have seen the pro's and cons of many different compilers and i know
MS's compilers are far from the top 3 which made me wonder if CB supplied some "behind the scenes" setting to the mingw compiler in my practical
examples, as i expected more juice out of it.

The main reason for why i took iostream in this example was because i always end up using it for starters  , and my tests ranged from mathematical
operations to IO operations.

JGM
The code above was from me, except InvSqrt(); taken from Quake3 SDK for high performance mathematical test purpose.

Regards,
Fred

[JGM]

JGM
The code above was from me, except InvSqrt(); taken from Quake3 SDK for high performance mathematical test purpose.

Ok, just wanted to point that best regards! 

[thomas]

InvSqrt(); taken from Quake3 SDK for high performance mathematical test purpose.

You should be aware, however, that it is nothing like high performance on reasonably modern CPUs. You will fare much better if you stay away from such stuff. Despite what some people may tell you, it's truly an anti-optimization (plus, many such hacks are insafe -- this one is not, incidentially, but most are).