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]

al*******@gmail.com wrote:

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]

al*******@gmail.com wrote:

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]

Mirek Fidler wrote:

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

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]

Mirek Fidler wrote:

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.

<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]

al*******@gmail.com wrote:

Mirek Fidler wrote:

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

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/Pr...d-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]

Christopher Hulbert wrote:

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]

al*******@gmail.com wrote:

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]

Mirek Fidler wrote:

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.

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

[Mike Smith]

al*******@gmail.com wrote:

Christopher Hulbert wrote:

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.

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

--
Mike Smith

[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

--
http://Evgenii.Rudnyi.Ru/
http://www.imtek.uni-freiburg.de/simulation/mor4ansys/

[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]

Mirek Fidler wrote:

> 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"?

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.

> 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.

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

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.

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

> 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.

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]

Mirek Fidler wrote:

> 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"?

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.

> 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.

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

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]

at******@gmail.com wrote:

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,

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

[Stephan Brönnimann]

at******@gmail.com wrote:

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.

[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

[Christopher Hulbert]

Stephan Brönnimann wrote:

at******@gmail.com wrote:

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.

[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

Off Topic:

Just to clarify and give an example of what atgraham [I believe] is talking about.

consider two files a.c and b.c
$ cat a.c
void a1(void) { return;}
void a2(void) { return;}
#include <stdlib.h>

$ cat b.c
extern void a1(void);

int main(void)
{
a1();
}

Then,

$ gcc -c -oa.o a.c;ar r liba.a a.o
$ nm liba.a

a.o:
0000000000000000 T a1
0000000000000006 T a2
$ gcc b.c -L. -la
$ nm a.out | grep a2
000000000040047a T a2


Notice how the program compiled from b linking against liba.a used a2 despite
b.c never calling it. This is a shortcoming in the GNU linker in which it can
not perform function-level linking (i.e. extracting just the function a1 from
a.o). So for object files with many functions in it (consider the HDF 5 library
for example), this starts to add up. That is what I think he was reffering to,
or he should correct me. This is why a lot of code is written with few
functions per source file.

[Mirek Fidler]

[OT]

Notice how the program compiled from b linking against liba.a used a2
despite b.c never calling it. This is a shortcoming in the GNU linker
in which it can not perform function-level linking (i.e. extracting just
the function a1 from a.o).

Actually, this is an interesting topic. There is a -ffunction-section
option of GCC that puts each funtion to separate section in order to
allow linker to eliminate dead code.

However, on some linux distros (means, ld versions), this option seems
to be "tolerated" but not actually used by ld, while on others this
makes linking process fail (Ububuntu 5.10).

We have implemented Win32 linker for MinGW (uld) that is able to
eliminate unused sections and indeed, it indeed has lead into
significant reduction of executable size (about 20%).

For linux ld, documentation is blurry. Does anybody know what the real
state of affairs is there?

Mirek

[atgraham]

[OT]

However, on some linux distros (means, ld versions), this option seems
to be "tolerated" but not actually used by ld, while on others this
makes linking process fail (Ububuntu 5.10).

There is also -fdata-sections. In order for it to work at all, you
need to supply ld with "--gc-sections" at link time. I've never seen
these -f*-sections cause problems with gnu ld. But you need to be more
precise about the ordering of your link line (or use the
--start-group/--end-group options) since it makes the linker dependency
graph much more complicated and thus more likely to fail in cases where
you "got lucky" before.

I haven't tried the ld that comes with Ubuntu 5.10. But I have used
some systems where the linker isn't gnu ld at all, or is a version that
is largely modified and produces different behavior.

[Evgenii Rudnyi]

> While those points are well put, they are no excuse for the poor code

generated by GCC in comparison to VC++.
I am not sure if I understand what you mean. Could you please 1) Define
what is poor code; 2) Choose a case study and make it available for
others; 3) Describe your observations for 2).

Then it would be more clear what you mean and other people could make
independent checks.

> 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....

My remark was about using Win32 API. If you do not use it, then your
code is portable.

> 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.

Again I have meant Win32 API.

> 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"?

A process interacts with OS and a compiler should choose the right
system call.
...to develop ~200000 lines crossplatform projects. Do not judge IDEs by
your Xcode experiences :)

My IDE is vim. I am a command like freak.

Best wishes,

Evgenii

[Ian]

Mirek Fidler wrote:

[OT]

Notice how the program compiled from b linking against liba.a used a2
despite b.c never calling it. This is a shortcoming in the GNU linker
in which it can not perform function-level linking (i.e. extracting
just the function a1 from a.o).

Actually, this is an interesting topic. There is a -ffunction-section
option of GCC that puts each funtion to separate section in order to
allow linker to eliminate dead code.

How does the compiler treat non inlined inline functions, are they local
to each compilation unit or global? This can make a big difference to
executable size, not to mention link time!

Ian

[james.moughan]

Mirek Fidler wrote:[snip]

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....

It would be nice if MS were to conform to the standard a little better.
:)

> 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.

gcc benchmarks very well against Intel's C++ compiler, so that is
unlikely to be the problem. Unless you want to tell Intel a thing or
two about x86 optimisation.

Without specific pieces of code to benchmark on this is pointless.
E.g., if the original problem involved lots of small string
manipulation the VC++ is going to be much faster, butthet's not a
factor of the quality of the compiler.

James M

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

[Michael Schuster]

Evgenii Rudnyi wrote:

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.

Well in my view: Better VC++ or gcc is a highly religious question, if you
refer to the optimization issues. MS is of course highly interested to sell
a compiler with good results and will pump money into the development. On
the other hand gcc is open, a lot of people look into the details, so this
compiler will produce good (=fast) code, too. You won't find a final
answer. My expierience (writing a simulation system) is, the most
performance gain is always in your own code, compilers may vary in speed
differences of smaller 3%.
gcc which I'm using has the advantages:
+ It's available on nearly every platform
+ free

Michael


--
Remove the sport from my address to obtain email
www.enertex.de - Innovative Systemlösungen der Energie- und Elektrotechnik

[Stephan Brönnimann]

Sorry, I was wrong.
Thanks to the insights and corrections.

Regards, Stephan

[Gabriel]

al*******@gmail.com wrote:

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?

Try to compile this short 29-character program with both compilers. Then
you know which compiler you want to use:
[begin main.cpp]
int main(){return 0 and 0;}
[end main.cpp]

Gabriel

--
Who is General Failure and why is he reading my hard disk?

[Mirek Fidler]

at******@gmail.com wrote:

[OT]

However, on some linux distros (means, ld versions), this option seems
to be "tolerated" but not actually used by ld, while on others this
makes linking process fail (Ububuntu 5.10).

There is also -fdata-sections. In order for it to work at all, you
need to supply ld with "--gc-sections" at link time.

Yes, I know. However, I might be wrong, but to me it looks like
specifying both has no effect anyway (binary size is the same).

I haven't tried the ld that comes with Ubuntu 5.10.

It issues errors about "cxa-at-exit" if you try to use --gc-sections. I
guess it is some fault in std-c++ or something like that...

Mirek

[alex.gman]

al*******@gmail.com wrote:

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?

s/better/faster

Sorry, I didn't notice the ambiguity.

Funny, I think Fortran77 programmers will see significant improvement
by just f2c'ing their code and compiling it with the free express
edition MSVC++2005. Intel compilers produce code that is about as fast
(read "slow") as GCC.

[Calum Grant]

Michael Schuster wrote:

Evgenii Rudnyi wrote:

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.
Well in my view: Better VC++ or gcc is a highly religious question, if you
refer to the optimization issues. MS is of course highly interested to sell
a compiler with good results and will pump money into the development. On
the other hand gcc is open, a lot of people look into the details, so this
compiler will produce good (=fast) code, too. You won't find a final
answer. My expierience (writing a simulation system) is, the most
performance gain is always in your own code, compilers may vary in speed
differences of smaller 3%.

I've noticed differences of more than 300% in extreme cases. But it
depends so much on what's being done. If your app is IO/network bound,
there will be almost no difference. If you are hitting memory hard,
there will be not so much difference. If you are doing lots of small
object/string allocation, you are mainly benchmarking the memory allocator.

I'm not that bothered about performance myself. I've never found gcc to
be lacking. It's got good standards conformance, fantastic
cross-platform support, and doesn't ICE quite so often as MSVC.
gcc which I'm using has the advantages:
+ It's available on nearly every platform
+ free

Michael