How does gcc compare to other C++ compilers

[cpp4ever]

As a Linux user, I rarely ever really get to try other compilers.
Personally I find gcc does the job, probably not as good as some for
optimisation, but I have no need to be that bleeding edge. More to the
point I like the freeware community out there, the support may not be
quite as direct, but I find it excellent, (once found).

cpp4ever

 

[Jonathan Lee]

As a Linux user, I rarely ever really get to try other compilers.

Just a heads up: Both the Intel and Sun compilers are available for
free on Linux. They might be restricted to non-commercial use, or
something, but you can certainly try them out.

--Jonathan

 

[Juha Nieminen]

As a Linux user, I rarely ever really get to try other compilers.
Personally I find gcc does the job, probably not as good as some for
optimisation, but I have no need to be that bleeding edge. More to the
point I like the freeware community out there, the support may not be
quite as direct, but I find it excellent, (once found).

I hear that gcc is one of the slowest compilers in existence. (Which
doesn't mean it generates slow code. It means that it takes a long amount
of time to compile a program.) And this even *without* any optimizations
or such heavy options turned on. This is a pretty common complaint.

With a program of a couple of thousands of lines you won't notice.
However, with a program with a couple millions of lines of code you
will certainly start to notice whether compiling it takes a half hour
or two minutes.

When you are compiling a debug version of your program, you don't want
to wait a half hour for the compiler to get finished. With a debug version
you *don't care* what the quality (in terms of efficiency) of the resulting
binary is, as long as you get it fast. (Compiling with full optimizations
is a different story.)

On other fronts (quality of the generated binary executable, support for
the C++ standard) it's one of the top tiers, so not many worries there.

 

[Öö Tiib]

Do people really find gcc slow? *expresses surprise* When I compile my
current project using gcc it's substantially faster than MSVC. Perhaps
they're both slow in comparison to something else...?

MSVC is quicker compiler than g++. MSVC is slow when using templates
massively and having wrong options. These two (wrong options here) i
think ... Debug Information Format: "Program database for edit and
Continue" (that does not work anyway) and Enable Incremental Linking:
"Yes". Fixing these two should give noticeable speed up.

 

[Ian Collins]

Do people really find gcc slow? *expresses surprise* When I compile my
current project using gcc it's substantially faster than MSVC. Perhaps
they're both slow in comparison to something else...?

Yes and No.

Unlike some other compilers, gcc takes a kitchen sink approach, with
lots of checking other compilers delegate to their companion tools like
lint. So it may compile slower, but compared to a compile and lint pass
with other tools, it may save time overall.

 

[Thomas Jollans]

As a Linux user, I rarely ever really get to try other compilers.

Well, you could. There are one or two compilers available on Windows
that aren't available on Linux, of course, but there are still plenty to
chose from.

GCC is the one compiler to rule them all: everybody uses gcc (well, not
quite) because everybody can - it runs on every system ever conceived,
and even if it doesn't, you can still use it to cross compile to
anywhere. Also, it's free software. Immensely portable, and popular,
free software.

Anyway, a recent new star is: LLVM's clang
I think I read somewhere that clang had Apple's blessing, not too sure
about that, but FreeBSD recently decided to use clang instead of gcc to
build their system, or at least to make that possible.
It's a decent compiler, I don't know how good it is at C++ myself
though. You could have a go at it.

Then there's OpenWatcom. No idea if it's any good, but it is old.

And, of course, the Intel compiler, the AMD compiler, the Sun compiler,
etc etc etc.

 

[robertwessel2]

Well, you could. There are one or two compilers available on Windows
that aren't available on Linux, of course, but there are still plenty to
chose from.

GCC is the one compiler to rule them all: everybody uses gcc (well, not
quite) because everybody can - it runs on every system ever conceived,
and even if it doesn't, you can still use it to cross compile to
anywhere. Also, it's free software. Immensely portable, and popular,
free software.

While mostly true, it's likely that MSVC has a larger user base than
GCC does. Nor is GCC a great compiler for Windows, although it can
certainly be made to work.

 

[James Kanze]

MSVC is quicker compiler than g++.

It depends on the program, but for most real programs, MSVC 8.0
under Windows is significantly slower the g++ under Linux,
because VC++ actually opens and reads headers multiple times.
(Also probably because the Windows file system is significantly
slower than that of Linux.)

MSVC is slow when using templates massively and having wrong
options. These two (wrong options here) i think ... Debug
Information Format: "Program database for edit and Continue"
(that does not work anyway) and Enable Incremental Linking:
"Yes". Fixing these two should give noticeable speed up.

We have both incremental link and edit and continue turned off,
and VC++ is still significantly slower that g++. (If I do
a rebuild of our solution, it easily takes more than a half an
hour with VC++, less than 5 minutes with g++.)

 

[James Kanze]

I wouldn't be so sure of this. The preferred flavor on
MS-Windows platforms seems to be Dâ™­. That's what Microsoft is
pushing furiously -- a language that they fully control, and
away from a language they do not control.

They're pushing it so furiously that no one here has ever heard
of it (although we're a mainly Windows shop). Microsoft
continues to chair the C++ standards committee.

gcc rules on non MS-Windows platforms.

The "native" compiler rules on any platform, for a number of
reasons: Sun CC under Solaris, g++ under Linux, VC++ under
Windows, etc. G++ has two advantages with respect to the
others: it is widely ported to machines which wouldn't otherwise
have a C++ compiler, and it is present everywhere---*if* you can
get away without using the native compiler, using g++ will
reduce your portability problems. You usually don't have that
option, however: the third party libraries you're using are
usually only available for the native compiler.

 

[Ron AF Greve]

.....
|| Anyway, a recent new star is: LLVM's clang
....
| >
| > cpp4ever
| >
|

Yes, LLVM is really great especially you can write your own front end for
it. Its is now extremely easy to create your own language and have it
compile to optimized ML. Have been rewriting my scripting VM into something
that uses LLVM and it really works like a charm.


Regards, Ron AF Greve

http://informationsuperhighway.eu

 

[Öö Tiib]

I'm linking incrementally in debug mode but not in release (the default,
AFAIK). I thought the idea was that linking incrementally speeded up
linking though (because it's linking less)? Or (as is likely!) am I
missing something obvious?

Linker does some sort of duplicate code elimination about templates.
Seems that when it is incremental linking then there is some sort of
inefficient algorithm ... or other difficulty.

 

[Öö Tiib]

It depends on the program, but for most real programs, MSVC 8.0
under Windows is significantly slower the g++ under Linux,
because VC++ actually opens and reads headers multiple times.
(Also probably because the Windows file system is significantly
slower than that of Linux.)

This is perhaps about that "#pragma once" thing. MSVC does parse
headers several times when there are usual (#ifndef) multiple
inclusion guards but does not even open the files second time when
there is "#pragma once" somewhere in it. g++ does also respect that
#pragma once as multiple inclusion guard, but this indeed is not in
current standard yet. If to use both include guards then it is fine i
think.

We have both incremental link and edit and continue turned off,
and VC++ is still significantly slower that g++.  (If I do
a rebuild of our solution, it easily takes more than a half an
hour with VC++, less than 5 minutes with g++.)

There may be other tricks as well. Like for example the precompiled
headers that may speed MSVC up considerably when using massive
frameworks.

I do not know the size of your project but half an hour on average
modern pc sounds like several millions of lines with liberal usage of
templates. Then again i haven't seen it ever compiling on g++ 5
minutes when size is that large. Grid based building may be one
solution if project size is causing it. For example one team uses some
sort of "incredibuild" product since building times started to affect
performance of people.

 

[Bo Persson]

He means C#, it would seem (which I'm sure you did actually
realise) And it's neither surprising nor lamentable that they
push that - they invested a lot of time and money in developing it,
and they'd like people to use it. As long as they don't arbitrarily
stop supporting C++ (and chairing the C++ standards committee
doesn't sound like stopping supporting C++ AFAICS), I don't see
what the problem is personally...

They can't stop supporting C++, because that would leave a lot of the
server app business to gcc/Linux. This is a somewhat resent
realization that gave us VC++ 2010.



Bo Persson

 

[Bo Persson]

Anyway, a recent new star is: LLVM's clang
I think I read somewhere that clang had Apple's blessing, not too
sure about that, but FreeBSD recently decided to use clang instead
of gcc to build their system, or at least to make that possible.
It's a decent compiler, I don't know how good it is at C++ myself
though. You could have a go at it.

There are some politics involved in these choices. Apple seems to
avoid anything released under GPL v3, which inludes later versions of
gcc. I guess there might be similar reasons for BSD.


Bo Persson

 

[James Kanze]

On 23 juuli, 11:51, James Kanze <[email protected]> wrote:

[...]

This is perhaps about that "#pragma once" thing. MSVC does parse
headers several times when there are usual (#ifndef) multiple
inclusion guards but does not even open the files second time when
there is "#pragma once" somewhere in it. g++ does also respect that
#pragma once as multiple inclusion guard, but this indeed is not in
current standard yet. If to use both include guards then it is fine i
think.

That's an idea. It probably would be a better solution for us
to use #pragma once, and drop the Lakos convention. (I'd
forgotten about #pragma once, since none of the compilers I'd
used before this job needed it.)

[...]

I do not know the size of your project but half an hour on
average modern pc sounds like several millions of lines with
liberal usage of templates.

It's certainly not the largest project I've worked on. But it
is fairly big.

Then again i haven't seen it ever compiling on g++ 5
minutes when size is that large. Grid based building may be one
solution if project size is causing it. For example one team uses some
sort of "incredibuild" product since building times started to affect
performance of people.

We actually use IncrediBuild, so the build times we observe
aren't that bad. IncrediBuild has its problems (particularly
in terms of dependency analysis, but Visual Studios is pretty
bad there too), but all in all, it's a nice tool, and well worth
using if you're developing under Windows.

 

[Jerry Coffin]

[ ... ]

Anyway, a recent new star is: LLVM's clang
I think I read somewhere that clang had Apple's blessing, not too sure
about that, but FreeBSD recently decided to use clang instead of gcc to
build their system, or at least to make that possible.
It's a decent compiler, I don't know how good it is at C++ myself
though. You could have a go at it.

clang handles C quite well, but for C++ it's still at a _purely_
experimental stage. Just for an obvious example, it doesn't yet
handle access specifiers ("private:", "public:", or "protected:") at
all.

Then there's OpenWatcom. No idea if it's any good, but it is old.

It has a good code generator, but its C++ support is badly dated.

 

[Jerry Coffin]

I wouldn't be so sure of this. The preferred flavor on MS-Windows platforms
seems to be D?. That's what Microsoft is pushing furiously -- a language
that they fully control, and away from a language they do not control.

No -- D is Walter Bright's project, with (at most) minimal influence
by MS. Microsoft's currently pushes C#. Whether that's fully under
their control is open to some question -- they published its
specification as an ECMA and (I believe) ISO standard. If the
standards body started to develop the language in a direction MS
didn't like and the two diverged, it's an open question what would
happen.

 

[Lynn McGuire]

Then there's OpenWatcom. No idea if it's any good, but it is old.

It has a good code generator, but its C++ support is badly dated.

Have you tried the OW 1.9 release ? The template support is
improving but is not quite up to date yet.
http://openwatcom.org/index.php/C_Compilers_Release_Changes

Thanks,
Lynn

 

[robertwessel2]

No -- D is Walter Bright's project, with (at most) minimal influence
by MS. Microsoft's currently pushes C#. Whether that's fully under
their control is open to some question -- they published its
specification as an ECMA and (I believe) ISO standard. If the
standards body started to develop the language in a direction MS
didn't like and the two diverged, it's an open question what would
happen.

Actually he said D-flat. Which is a (rather obvious) pun on C-sharp.

 

[Maxim Yegorushkin]

I hear that gcc is one of the slowest compilers in existence. (Which
doesn't mean it generates slow code. It means that it takes a long amount
of time to compile a program.) And this even *without* any optimizations
or such heavy options turned on. This is a pretty common complaint.

Have you ever tried Sun C++ compiler? I haven't seen a compiler slower
than that.