Visual C++ vs GCC

[Christopher Hulbert]

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.

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.

x86 assembly and optimization guides are freely available online.

Again I have meant Win32 API.

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]

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

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


x86 assembly and optimization guides are freely available online.


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

 

[Michael Schuster]

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

 

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

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

Regards, Stephan

 

[Gabriel]

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

 

[Mirek Fidler]

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

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]

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.