Visual C++ vs GCC

[alex.gman]

Is it me, or does VC++ 2005 produce much better code than GCC? (about
twofold difference in the release configuration vs -O3) Has anyone done
a comprehensive study?

 

[Mirek Fidler]

Is it me, or does VC++ 2005 produce much better code than GCC? (about
twofold difference in the release configuration vs -O3)

Depends on what you are measuring... It is almost twofold difference in
size when comparing MinGW and VC++ (well, with the right optimizations
and alternate linker - uld; using default size optimization and "ld"
linker, it can easily be 3-fold or more).

I have never measured the speed.

Despite bugs and non-conformance, both VC++ 2003 and 2005 are pretty
good C++ compilers.

Mirek

 

[Thomas Tutone]

Is it me, or does VC++ 2005 produce much better code than GCC? (about
twofold difference in the release configuration vs -O3) Has anyone done
a comprehensive study?

Short answer - it's just you.

Longer answer - Define what you mean by "better code" and "twofold
difference." Do you mean size of executable? Speed of execution?

<OT>

You don't say which version of gcc you are using. If you are referring
to size of the executable, VC++ uses dynamic linking, while (the minGW
implementation of ) gcc uses static linking - so the gcc executable is
typically larger than the VC++ executable.

If you are referring to the speed, it depends on what you're measuring.
For example, the minGW implementation of gcc, unlike most other
versions of gcc, implements exceptions using setjump/longjump, which
causes overhead even when exceptions are not called. So I have found
that the minGW implementation can be considerably slower than other
implementations of gcc when the code involves a lot of try-catch blocks
propogating through functions. This slowdown disappears, for example,
when running the same program on djgpp.

But in general, I haven't seen anything suggesting that across various
standard benchmarks, VC++ 2005 is twice as fast as gcc. If you think
it is, I'd be interested in seeing your code and results.

</OT>

Best regards,

Tom

 

[Mirek Fidler]

You don't say which version of gcc you are using. If you are referring

to size of the executable, VC++ uses dynamic linking, while (the minGW

VC++ uses linking you set by options....

implementation of ) gcc uses static linking - so the gcc executable is

....whereas MinGW uses always msvcrt.dll as the runtime library. So in
fact, it is almost opposite.

typically larger than the VC++ executable.

FYI, if VC++ is forced to static linking and MinGW is left in default
mode (means msvcrt.dll/dynamic linking), resulting binary can easily be
3 times as long for MinGW (gcc 3.4.4). Sad, but true.

I _hope_ that speed comparison would yield better results (dead code
elimination (in VC++), function-level linking (in VC++) and too
aggressive inlining even in the size-optimized code (in GCC) seems to be
the cause of difference).

Mirek

 

[alex.gman]

VC++ uses linking you set by options....


...whereas MinGW uses always msvcrt.dll as the runtime library. So in
fact, it is almost opposite.


FYI, if VC++ is forced to static linking and MinGW is left in default
mode (means msvcrt.dll/dynamic linking), resulting binary can easily be
3 times as long for MinGW (gcc 3.4.4). Sad, but true.

I _hope_ that speed comparison would yield better results

Not a chance, GCC has been lagging behind VC++ for a while. Check out
this KILLER feature:

http://msdn.microsoft.com/library/default.asp?url=
/library/en-us/vccore/html/vcgrfglwholeprogramoptimization.asp

This is VERY relevant for speed, but VC++ has GCC beat on the
speed-of-development front as well: safe mode, change code while it's
being debugged, precompiled headers, ...

I predict that now that Apple will be competing with MS on similar
hardware, they will be forced to invest into GCC development, but it
will take them MANY years only to get where VC++ is now.

 

[Thomas Tutone]

VC++ uses linking you set by options....


...whereas MinGW uses always msvcrt.dll as the runtime library. So in
fact, it is almost opposite.

<OT>

I was referring to the C++ standard library, not to the C runtime
library. minGW links in the C++ standard library statically, not
dynamically.

If you want to discuss this further, I suggest we do it privately
off-list.

</OT>

Best regards,

Tom

 

[Christopher Hulbert]

Not a chance, GCC has been lagging behind VC++ for a while. Check out
this KILLER feature:

http://msdn.microsoft.com/library/default.asp?url=
/library/en-us/vccore/html/vcgrfglwholeprogramoptimization.asp

Off Topic:

The next release series of GCC will include whole-program optimization
(http://gcc.gnu.org/gcc-4.1/changes.html). When MinGW or cygwin will implement
this I don't know.

This is VERY relevant for speed, but VC++ has GCC beat on the
speed-of-development front as well: safe mode, change code while it's
being debugged, precompiled headers, ...

Off Topic:

GCC is a compiler. Changing code while it's being debugged is a feature of the
IDE, not the compiler itself.

As for precompiled-headers, I haven't used the feature, but this may interest you:
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

I predict that now that Apple will be competing with MS on similar
hardware, they will be forced to invest into GCC development, but it
will take them MANY years only to get where VC++ is now.

GCC's claim to fame isn't speed, but platforms.

 

[alex.gman]

Off Topic:

The next release series of GCC will include whole-program optimization
(http://gcc.gnu.org/gcc-4.1/changes.html). When MinGW or cygwin will implement
this I don't know.

Thanks. That's interesting.

GCC is a compiler. Changing code while it's being debugged is a feature of the
IDE, not the compiler itself.

As a Lisp programmer, I'm not closed-minded enough to think like this.
What matters is whether something can be done or not.

 

[Calum Grant]

Is it me, or does VC++ 2005 produce much better code than GCC? (about
twofold difference in the release configuration vs -O3) Has anyone done
a comprehensive study?

My own experiences are that VC++ is becoming an awesome compiler. With
heavy use of template metaprogramming, gcc-3 can be really quite poor,
while gcc-4 is a lot better, but still is generally a little slower than
VC++ in all the benchmarks I've ever done.

But those are just my own experiences, and may not be typical. I can't
comment on floating-point performance.

I've seen a small increase in performance between VC2003 and VC2005 but
nothing dramatic.

Calum

 

[Mike Smith]

VC++ uses linking you set by options....



...whereas MinGW uses always msvcrt.dll as the runtime library. So in
fact, it is almost opposite.

MinGW uses MSVCRT for the C runtime, but the C++ runtime is statically
linked, whereas it can be either static or dynamic for VC++.

 

[Mike Smith]

Christopher Hulbert wrote:




Thanks. That's interesting.




As a Lisp programmer, I'm not closed-minded enough to think like this.
What matters is whether something can be done or not.

If you're going to get snotty about Lisp, one could just as easily say
that rather than being "open-minded", you are willfully ignorant of the
details and underlying forces and issues that can, in practice, make a
big difference in the real world. C++ is good that way - it keeps you
on your toes. ;-P

 

[atgraham]

What makes you think VC++ produces better code? Are you talking about
code size? Are you talking about benchmarking? Have you done
disassemblies of the executables and compared the output? Have you
explored the real virtues of the compilers and compared them in light
of the fact that Microsoft doesn't want you to know VC++ faults? How
much do you know about compilers?

 

[Evgenii Rudnyi]

First a few words about myself. I am using gcc since 1998, before I
have used BC++. I am working on Mac nowadays and compile code for Sun,
Linux and Windows (under cygwin). Yet, I used to be MCT, MCSE +I for
NT and MCSE for Windows 2000. Well, I do know different technologies.

Tastes differ and I am not going to convince you that gcc is the best
option. VC++ is a good compiler, no doubts. I just would like to make a
few general comments.

1) In my view, the main problem with VC++ is a result of Microsoft
paradigm "Windows everywhere". This means that if at some point you
need to switch to another platform, you will be at lost.

2) When you speak about effeciency, you should not forget 1). For
example, the comparison of gcc on Mac with VC++ is impossible in
principle.

3) Microsoft is, after all, a monopoly and it does not disclose many
internal secrets. This was the main reason for MS to drive other
compilers for Windows out of the business (I do not insist that I am
right but this is my personal impresson after a war Borland C++ vs.
VC++).

4) gcc on Windows is not tuned for Windows, it is an external body (see
3). A better comparison would be if you install both Linux and Windows
on the same computer and then compare the code compiled by gcc under
Linux with that compiled by VC++ on Windows.

5) It is easy to start programming with IDE, no doubts. Yet, it is hard
to continue. When your code is below 1000 lines, then there should be
no problem. Yet, if you go to 10 000 lines, this is another story. You
must learn that there is a compiler, a linker, a librarian, a debugger,
etc, and all of them have different behavior.

6) If you target numerical problems, you will face soon that you have
problems to use existing scientific libraries. Go to netlib, choose a
library and try to compile with VC++. It happens that this is not that
easy. Remember about 1).

Best wishes,

Evgenii

 

[Mirek Fidler]

First a few words about myself. I am using gcc since 1998, before I

have used BC++. I am working on Mac nowadays and compile code for Sun,
Linux and Windows (under cygwin). Yet, I used to be MCT, MCSE +I for
NT and MCSE for Windows 2000. Well, I do know different technologies.

Tastes differ and I am not going to convince you that gcc is the best
option. VC++ is a good compiler, no doubts. I just would like to make a
few general comments.

While those points are well put, they are no excuse for the poor code
generated by GCC in comparison to VC++.

> 1) In my view, the main problem with VC++ is a result of Microsoft
> paradigm "Windows everywhere". This means that if at some point you
> need to switch to another platform, you will be at lost.

Why?

Right now I am using VC++ to develop applications for both Win32 and
Linux - I just compile them using gcc on linux. That is why C++ is
standardised language....

> 2) When you speak about effeciency, you should not forget 1). For
> example, the comparison of gcc on Mac with VC++ is impossible in
> principle.

Well, I guess in just another year, it will likely be possible

> 3) Microsoft is, after all, a monopoly and it does not disclose many
> internal secrets. This was the main reason for MS to drive other
> compilers for Windows out of the business (I do not insist that I am
> right but this is my personal impresson after a war Borland C++ vs.
> VC++).

x86 assembly and optimization guides are freely available online.

> 4) gcc on Windows is not tuned for Windows, it is an external body (see

Does not matter. It should be tuned for x86, not Windows.

How do you think the C++ compiler can be "tuned for windows"?

> 3). A better comparison would be if you install both Linux and Windows
> on the same computer and then compare the code compiled by gcc under
> Linux with that compiled by VC++ on Windows.

Yes, that is exactly what I do. VC++ wins by 50% in code size (static
linking). That is a lot.

> 5) It is easy to start programming with IDE, no doubts. Yet, it is hard

All I am using is just commandline VC++. I am using U++/TheIDE as my IDE...

> to continue. When your code is below 1000 lines, then there should be
> no problem. Yet, if you go to 10 000 lines, this is another story. You

....to develop ~200000 lines crossplatform projects. Do not judge IDEs by
your Xcode experiences

Mirek

 

[roberts.noah]

Does not matter. It should be tuned for x86, not Windows.

How do you think the C++ compiler can be "tuned for windows"?

Executable formats differ between the two systems. Dynamic linking for
one is completely different. This shouldn't affect the main part of
the program, optimizations in particular areas, but it would certainly
have an effect on exe size and there will be major differences any time
there is a dynamic library call.

Yes, that is exactly what I do. VC++ wins by 50% in code size (static
linking). That is a lot.

Code size is a pretty silly measure. Is VC++ doing all the loop
unrollings it can? Is GCC? Fast code is often "larger" than slow
code. Are you measuring total exe size or the amount of code in a
given area? Does this measure account for differences in library
linking and exe format?

GCC has all sorts of switches to turn on and off optimizations. You
have a very high degree of control over exe size vs. performance. I
assume you have much of the same control in MSVC++ but I don't know.
Point is that their defaults are definately different (for one thing
VC++ turns off RTII by default and GCC does not). If you really want
to make a valid comparison then first you have to be sure that you are
telling the compilers to build the same thing and not least of all you
need more to compare than just "code size".

 

[Mirek Fidler]

4) gcc on Windows is not tuned for Windows, it is an external body (see

Executable formats differ between the two systems. Dynamic linking for
one is completely different. This shouldn't affect the main part of
the program, optimizations in particular areas, but it would certainly
have an effect on exe size and there will be major differences any time
there is a dynamic library call.

Actually, while this does have nothing to do with "tuning for windows",
this is valid argument.

Code size is a pretty silly measure. Is VC++ doing all the loop
unrollings it can? Is GCC?

Optimize for size in effect on both sides (means no loop unroling).

Fast code is often "larger" than slow
code. Are you measuring total exe size or the amount of code in a
given area?

Well, I did a lot of things, from playing with options down to comparing
assembly for the same function generated by both compilers. Still there
is huge difference even at that level. Unfortunately.

Does this measure account for differences in library
linking and exe format?

GCC has all sorts of switches to turn on and off optimizations. You
have a very high degree of control over exe size vs. performance.

That is true. My 50% difference came after playing with options for a
while. Originally it was more like 150% (with default size optimization).

And, actually, there is not that much options affecting optimizations in
GCC. Those relevant ones are on using either -O1 or -O2, see this
excelent article about the issue:

http://freshmeat.net/articles/view/730/

Actually, despite being instructed otherwise, I kept playing with
options and for the size optimization, the best set seems to be:

-Os -finline-limit=20 -ffunction-sections

(of course, as long as your linker is able to cope with that).
"inline-limit" couriously makes a huge difference in size.

I
assume you have much of the same control in MSVC++ but I don't know.
Point is that their defaults are definately different (for one thing
VC++ turns off RTII by default and GCC does not).

I turn it on.

If you really want
to make a valid comparison then first you have to be sure that you are
telling the compilers to build the same thing and not least of all you
need more to compare than just "code size".

Be sure I am.

Now please, this can seem like I despise GCC. No. Just VC++ is at the
moment way better compiler (another issue is compilation speed - VC++ is
2-3 times faster).

It is a pity, imagine how good would be Mac or Linux if it had better
compiler.... But of course, GCC keeps going on, leaving us with hope it
will gradually improve to the level of VC++. But we should not be blind
and think GCC is better just because it is open-source while VC++ is
produced by that evil company....

Mirek

 

[Christopher Hulbert]

Actually, while this does have nothing to do with "tuning for windows",
this is valid argument.



Optimize for size in effect on both sides (means no loop unroling).



Well, I did a lot of things, from playing with options down to comparing
assembly for the same function generated by both compilers. Still there
is huge difference even at that level. Unfortunately.



That is true. My 50% difference came after playing with options for a
while. Originally it was more like 150% (with default size optimization).

And, actually, there is not that much options affecting optimizations in
GCC. Those relevant ones are on using either -O1 or -O2, see this
excelent article about the issue:

http://freshmeat.net/articles/view/730/

Actually, despite being instructed otherwise, I kept playing with
options and for the size optimization, the best set seems to be:

-Os -finline-limit=20 -ffunction-sections

(of course, as long as your linker is able to cope with that).
"inline-limit" couriously makes a huge difference in size.



I turn it on.



Be sure I am.

Now please, this can seem like I despise GCC. No. Just VC++ is at the
moment way better compiler (another issue is compilation speed - VC++ is
2-3 times faster).

It is a pity, imagine how good would be Mac or Linux if it had better
compiler.... But of course, GCC keeps going on, leaving us with hope it
will gradually improve to the level of VC++. But we should not be blind
and think GCC is better just because it is open-source while VC++ is
produced by that evil company....

Mirek

Perhaps this discussion should be taken elsewhere as it has deviated from
iso/ansi c++.

clc++ Off Topic:
Mac and linux are just fine; In fact source I compile with VC++ on windows can
run faster with gcc under linux. For a number of compilers, check out
PGI,PathScale,Intel,etc. VC++ (like those just mentioned) is a commercial
compiler. GCC is a free open-source compiler.

 

[atgraham]

Yes, that is exactly what I do. VC++ wins by 50% in code

size (static linking). That is a lot.

You're really barking up the wrong tree here. The static libraries in
your standard gcc distribution are compiled with large linker sections,
essentially meaning the linker will bring lots of stuff into the
executable that isn't used at all. A disassembly or simple "nm" will
tell you this. This isn't a fault of the compiler, it's just the
result of a linker performance tradeoff that the package maintainer
(not necessarily consciously) made while building the library, and it's
also a result of the fact that static linking is generally discouraged.
Those who are concerned about executable size (embedded developers)
know how to easily fix this problem.

If you haven't even bothered stripping out debug information, then I
can tell you without reservation that a larger executable is almost
certainly better.

There are a myriad of other issues as well. But it's safe to say that
you're quite misled and that you're generalizing way beyond your level
of understanding. And since you're posting your interpretations of
your results rather than hard data and code, I'll just assume (as most
others are) that you're just blowing smoke.

 

[Mirek Fidler]

You're really barking up the wrong tree here. The static libraries in
your standard gcc distribution are compiled with large linker sections,

Just for the record, I am not using std-c++ libraries. And I am using
static CRT with VC++ and shared GLIBC with Linux/GCC.

There are a myriad of other issues as well. But it's safe to say that
you're quite misled and that you're generalizing way beyond your level
of understanding.

I would be really glad to know how to decrease my binary size to the
levels I am able to achieve with VC++. Any hints are welcome....

BTW, it is quite easy to reproduce my findings. Download U++
(http://upp.sf.net), compile e.g. "UWord" example (that is three clicks
of mouse away after installing) on all platforms with the best set of
options you are able to invent and then return back to tell me what
should I fix.

And since you're posting your interpretations of
your results rather than hard data and code,

I am not original poster. Last time I have tried was 6 months ago, I do
not have data ready and I guess this is not the place to present them.

I'll just assume (as most
others are) that you're just blowing smoke.

Why stating that VC++ outperforms GCC makes you angry?

Mirek

 

[=?iso-8859-1?q?Stephan_Br=F6nnimann?=]

You're really barking up the wrong tree here. The static libraries in
your standard gcc distribution are compiled with large linker sections,
essentially meaning the linker will bring lots of stuff into the
executable that isn't used at all. A disassembly or simple "nm" will
tell you this.

[snip]

[OT]
You are wrong: if (under UNIX, don't know about Windows) a program
is linked against static libraries (i.e., lib<X>.a) then the libraries
are used
to resolve undefined symbols of A) the object files and B) any new
undefined symbols that result from step A.

If you link object files (i.e., <X>.o) the all symbols from these
object
files are put into the binary. In this respect, shared libraries behave
like object files when loaded by the loader.
[/OT]

Regards, Stephan