g++ is very slow when compared to cl

[manav]

when i compile my .cpp files i feel that g++ is very slow.
i thought it was natural since C++ is very complex to compile.
but when i run cl on same files it compiles much faster.

are there any options to make g++ run faster. or may be my g++ version is old. although i am using latest MinGW package.

cl is the name of Microsoft Compiler. I have MSVC .Net 2003 but I use it from command line only!

[Bubba]

Moved to Tech board.

[CornedBee]

The Microsoft compiler is indeed considerably faster than GCC. Since its source is not available, we don't know why that is.

[brewbuck]

The Microsoft compiler is indeed considerably faster than GCC. Since its source is not available, we don't know why that is.

The usual reason for g++ slowness is the speed of parsing the STL code, which is included pretty much everywhere. I'd guess that Visual Studio has precompiled headers for most things, which makes a huge difference. g++ supports them now, sort of...

[CornedBee]

I believe even VS doesn't use precompiled headers for the STL unless you tell it to. Besides, VC++ is faster at compiling complicated Boost stuff, too, and that far exceeds the STL in size.

[maxorator]

The only thing that interests me is which one of them optimizes better. :D

[CornedBee]

In general, that prize goes to MS's compiler as well. Though the 4.x series of GCC is considerably better than the 3.x series and is very close, sometimes better.

[maxorator]

In general, that prize goes to MS's compiler as well. Though the 4.x series of GCC is considerably better than the 3.x series and is very close, sometimes better.
Well, I work on a reverse engineering project of an application compiled with GCC and one other guy I know works on the next version of it, which is compiled with MSVC. He said that version had alot worse assembly than the GCC one had... also, there weren't too many new features but the size of the executable grew about 8 times.

The games are GTA:Vice City and GTA:San Andreas and the reversing projects are VC:MP and SA:MP.

[CornedBee]

*shrug*
That's the thing about generalizations. :)

[manav]

CornedBee: I did not understand that.

My g++ was so slow that it took the whole night to compile Qt.
I left the PC on for the night. And by the morning it was almost done :)

[Mario F.]

Hmm... that must be some other problem then. I compiled Qt before on my aged laptop, and while trying to decide between it and wxWidgets, and it took me... 30 minutes? Yes, g++.

I can tell you however mingw's g++ is indeed slower and produces more bloated code than VC++. This became very obvious to me when I started using the wxWidgets framework. However under Linux, the same library compiles considerably faster and with less code bloat. So, it must probably a port thing.

Regardless I used to use g++ extensively on windows. It's a great compiler, has a good debugger and goes along just fine with all the IDEs we like. I used VC++ specifically only for my wxWidgets project. But now I migrated to Linux, and am considering moving the wxWidgets project too, since my preliminary observations revealed g++ there to be as good as VC++ is on windows.

[maxorator]

I can tell you however mingw's g++ is indeed slower and produces more bloated code than VC++. This became very obvious to me when I started using the wxWidgets framework. However under Linux, the same library compiles considerably faster and with less code bloat. So, it must probably a port thing.
How can you tell that? Have you examined some disassembly?

[manav]

Mario: I have also compiled some plain C++ programs with g++. Even the simplest "Hello, World" type takes so much time, that i can more than just notice the time taken.

[laserlight]

Mario: I have also compiled some plain C++ programs with g++. Even the simplest "Hello, World" type takes so much time, that i can more than just notice the time taken.
That is definitely unusual. What are your system specs, and what version of g++ are you running?

[Elysia]

But Visual Studio 2003 is quite outdated. The least you should be using is 2005, since it's considerably more standards compliant. Best use 2008, though. It's even more standards compliant.

[manav]

laserlight: i will post the info when i go home, the MinGW is in my home computer.
although outdated (per se Elysia) in office i use MSVS 2003 .Net.

[Elysia]

although outdated (per se Elysia) in office i use MSVS 2003 .Net.

In other words: they force you to use it? :)

[manav]

Yeah. You are right Elysia.
My job requirements make me use Qt 4.1 when there is 4.3, SCons 0.96 (Yuck!) MSVS 2003 etc. etc.

[Mario F.]

How can you tell that? Have you examined some disassembly?

No. I just look at the resulting executable sizes. Duh! ;)

[laserlight]

In other words: they force you to use it?
At least it is reasonably standards compliant, unlike MSVC6 or MSVC7.

SCons 0.96 (Yuck!)
Hehe, I noticed that SCons 0.98 was released on 31 March.

[Elysia]

At least it is reasonably standards compliant, unlike MSVC6 or MSVC7.

Better than nothing, at least. Unlike someone else's job who still uses the old MSVC6 compiler :p

[manav]

laserlight this is for you:

g++:
Reading specs from C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as -
-host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --
enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar
ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena
ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync
hronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw special)

my system:
OS Name Microsoft Windows XP Professional
Version 5.1.2600 Service Pack 2 Build 2600
OS Manufacturer Microsoft Corporation
System Name INTEL
System Manufacturer INTEL_
System Model D845GBV2
System Type X86-based PC
Processor x86 Family 15 Model 2 Stepping 7 GenuineIntel ~1799 Mhz
BIOS Version/Date Intel Corp. RG84510A.86A.0028.P15.0302260937, 2/26/2003
SMBIOS Version 2.3
Windows Directory C:\WINDOWS
System Directory C:\WINDOWS\system32
Boot Device \Device\HarddiskVolume1
Locale United States
Hardware Abstraction Layer Version = "5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)"
User Name INTEL\Administrator
Time Zone Pacific Standard Time
Total Physical Memory 512.00 MB
Available Physical Memory 236.27 MB
Total Virtual Memory 2.00 GB
Available Virtual Memory 1.96 GB
Page File Space 864.94 MB
Page File C:\pagefile.sys

[matsp]

With 512MB of RAM and built-in graphics, you may not have enough memory to compile large projects. gcc and g++ are pretty memory hungry at times.

If anything else, a bit more memory will allow the system to cache more of the include files and such.

--
Mats

[manav]

thanks. actually maybe it depends on system load.
this program compiled in 2 seconds only:

#include <iostream>
using namespace std;

int main()
{
cout << "Hello G++!\n";
return 0;
}

[Mario F.]

With 512MB of RAM and built-in graphics, you may not have enough memory to compile large projects. gcc and g++ are pretty memory hungry at times.

If anything else, a bit more memory will allow the system to cache more of the include files and such.

--
Mats

I have 512MB of RAM and I'm no where close to experience manav's problems and never was. Granted, if all of those MBs are being used, I probably would. So maybe that's it. Too many things opened?

[matsp]

I have 512MB of RAM and I'm no where close to experience manav's problems and never was. Granted, if all of those MBs are being used, I probably would. So maybe that's it. Too many things opened?

Yes, I agree, that 512MB should be enough, but you don't need much of antivirus software, graphics frame buffer and other such stuff to eat up enough that it starts swapping. And gcc is definitely not "lean" on memory usage.

--
Mats

[mike_g]

Surely 512mb RAM is plenty.

Manav: maybe theres somethin eating up all your resources, either that or you have a very old pc.

My laptop specs are:
512mb ram.
Celeron underclocked @ 630mhz
280mhz bus.
No GPU: leeches off ram instead.
OS: Xubuntu

But g++ will still compile pretty much any small project for me in less time than is noticable.

[Elysia]

512 MB is not plenty :p
It's pretty poor these days. You can't have much running with 512 MB and expect a fast system...

[mike_g]

Don't Insult my new laptop Elysia :devil:

On the plus side its only about 9" big and has a solid state HD that boots into xfce in around 30 seconds.

Tbh I find 512mb ram more than enough for most of the things I do with a computer. I can still run FF with a load of tabs open, pidgin, the terminal, and gedit all at once with no paging. What more should I need?

[Mario F.]

LOL. We had this discussion before Elysia. Let it go. I think you were proved wrong back then. It's a matter of what you do with your computer. 512MB Ram can be plenty, yes. It IS plenty on my case. I honestly don't feel at all the need to put in some more.

[matsp]

Surely 512mb RAM is plenty.

Manav: maybe theres somethin eating up all your resources, either that or you have a very old pc.

My laptop specs are:
512mb ram.
Celeron underclocked @ 630mhz
280mhz bus.
No GPU: leeches off ram instead.
OS: Xubuntu

But g++ will still compile pretty much any small project for me in less time than is noticable.

But we have already established that gcc for Linux is much faster than gcc on Windows, so comparing your Linux machine to a Windows system is unfair.

--
Mats

[Elysia]

Well, doesn't matter anyway... 512 MB or 512 TB... Heh.
But I do find it a little stretch to say it's plenty. Enough perhaps. But not plenty.

[matsp]

LOL. We had this discussion before Elysia. Let it go. I think you were proved wrong back then. It's a matter of what you do with your computer. 512MB Ram can be plenty, yes. It IS plenty on my case. I honestly don't feel at all the need to put in some more.

I agree with that - having more memory in the machine than what you can actually use makes no sense at all.

But 512MB is not "much" in todays terms - which was my original point. The processor in manav's system is fast enough [assuming it's not also busy doing something else, so that's not the source of slow compiles]. Antivirus software and/or lack of memory comes up next on the list.

--
Mats

[Mario F.]

But 512MB is not "much" in todays terms - which was my original point. The processor in manav's system is fast enough [assuming it's not also busy doing something else, so that's not the source of slow compiles]. Antivirus software and/or lack of memory comes up next on the list.

Absolutely. My answer to Elysia was however a generalization, since that is how it was put by her. And in general terms it simply depends on what one does with their computer and what OS & software is installed.

Make no mistake, my wxWidgets project will eventually grow enough my current system is no longer able to be so productive, even on Linux. At that time 512MB will no longer be plenty, but... not enough anymore.

However, what I always experienced all my life is that before I felt the need to upgrade memory, I always felt the need to upgrade the whole damn computer
anyways. I feel that processors are in more demand as far as upgrades are concerned than memory.

[Elysia]

That's funny. The processor is the least I've felt needing upgrading.
Still using my old Athlon64 X2 3800+. It's done good work so far.
Eventually, I'll get quad core, but then the whole mainboard needs to go out the window.
Even graphics card are more plenty upgraded than the processor...

[laserlight]

When I had 512 MB of memory, I could never finish compiling the Fox Toolkit using the MinGW port of g++ 3.4.2 on MSYS. I added another 512 MB of memory and could compile without problems.

I suspect that one will get the most out of a memory upgrade by upping it to 1 GB to 2 GB. Beyond 2 GB the law of diminishing returns may set in, and upgrading the processor and motherboard could be more effective.

[brewbuck]

That is definitely unusual. What are your system specs, and what version of g++ are you running?

It's sad but true... iostream seems to be a very heavy header these days.

I am also disappointed at how much code the standard library drags in when you try to do even very simple stuff. A statically linked "hello world" on my system is about 400k. A link dependency map shows that it all traces back to internal calls to vsprintf(), which amazingly, causes memory to be allocated with malloc(), which drags in other runtime components, which drag in yet more... Until you're at 400 kilobytes.

[Elysia]

I find that another reason to use redistribute runtime instead of static. So long as the runtime will function correctly, that is, when installed in the system folder (not messing up other programs).

[brewbuck]

I find that another reason to use redistribute runtime instead of static. So long as the runtime will function correctly, that is, when installed in the system folder (not messing up other programs).

Do you know how much I wish we could distribute our products in dynamic form? We do on Windows, but our Linux customers have such a variety of old glibc versions that dynamic linking just isn't an option. I wish the glibc designers were not so nonchalant about binary-breaking changes. "Oh, the user can just recompile..." Yeah right.

[Elysia]

I feel hatred towards library designers expressing themselves through a heated post :)

[brewbuck]

I feel hatred towards library designers expressing themselves through a heated post :)

Okay, it took me a while to parse that. I thought you mean that you, personally, felt hatred toward library designers, designers who express themselves through heated posts.

But what you mean is, You feel, that somebody (me) has hatred for library designers, and that person (me) is expressing himself in a heated post. Right?

I guess you're not far from the mark. "Hatred" is a strong word though :)

[Elysia]

Maybe hatred is a bad word...
I meant, frustration :)
Yep, you feel frustration for library designers...

[laserlight]

Yep, you feel frustration for library designers...
Stroustrup claims that it is not the library designers fault, but the library implementors fault (http://www.research.att.com/~bs/bs_faq.html#Hello-world).

[brewbuck]

Stroustrup claims that it is not the library designers fault, but the library implementors fault (http://www.research.att.com/~bs/bs_faq.html#Hello-world).

Well, I wasn't griping about the executable size (large size is expected when linking statically), but the fact that they almost deliberately go out of their way to make it impossible to link dynamically if you actually want to target a wide variety of systems.

It's understandable (GNU is all about free software after all, and doesn't really care too much about the problems of commercial closed source vendors) but annoying.

[Mario F.]

I think Elysia meant that. It's still annoying though because you might as well ask your grocery store owner to better implement libraries. His "uh" and "whatcha talking about?" will be more than the almost guaranteed lack of response from a library implementor.

[CornedBee]

glibc actually has some good guidelines on binary compatibility. If only I could find them right now ...

[brewbuck]

glibc actually has some good guidelines on binary compatibility. If only I could find them right now ...

Do the guidelines apply to ancient versions of glibc? As in, 12 years old? Many of our customers are still running Red Hat 4.

[CornedBee]

They apply, but they don't dictate compatibility. Wasn't 12 years ago still glibc1?

[brewbuck]

They apply, but they don't dictate compatibility. Wasn't 12 years ago still glibc1?

Ugh. Yes.

[Elysia]

I think Elysia meant that. It's still annoying though because you might as well ask your grocery store owner to better implement libraries. His "uh" and "whatcha talking about?" will be more than the almost guaranteed lack of response from a library implementor.

Yeah, obviously those who build the libraries, the ones in charge who are at fault for the big code, which is of course what I meant.