GCC (cygwin) much faster than MSVC, Borland?

I've tried lots of performance options for MSVC 6 and Borland 5.5 on Windows 2000 (Celeron Tualatin), but the speed of my program did not change significantly! The GCC 3.2.x (cygwin) compiled version finishes it's calculations in about 8.7 sec, but the MSVC and Borland versions need about 20 to 21 sec.
What is wrong with MSVC and Borland? Did I make a mistake?
Or will I have to buy Intel's compiler to get the same or better performance than GCC?

compiler flags:
MSVC: -Ox -G6
Borland: -6 -O2 -O
GCC: -O2

Thank you for your help. :)

> What is wrong with MSVC and Borland?
Probably their age - MSVC 6 is about 5 years old now, so the latest gcc probably knows a few more tricks.

You can't really tell much from optimising just one program - sure gcc wins this round, but with another program, the results could be different.

> Or will I have to buy Intel's compiler to get the same or better performance than GCC?
Why?
Is there a problem using gcc?

>Probably their age
Okay, that's a good point! I didn't think about it. Five years are almost an eternity for compilers.

>Why?
>Is there a problem using gcc?
Well, I don't have a problem with gcc, but the people I work with don't know much about computers and handling dlls (cygwin1.dll). Giving them a pure exe file is much safer. ;)
I guess I will check out Intel's compiler.

Thank you for your help, Salem! :)

You could always use dev-c++ to compile something more 'win32' oriented, and still have the benefit of a gcc based compiler.

Or there's DJGPP

That's sounds nice. And it will save me a couple of bucks, too - I will check it out!
Thanks again. :)

There are tricks with executables that require DLL files. You can auctually write a kinda-sorta-almost wrapper executable that when run drops the DLL onto their computer, executes the program compiled with cygwin's GCC and then delete the DLL. There are dozens of tricks to combining alot of extra garbage necessary for program execution (Mostly pioneered by virus writers, imagine that) that can moron-proof your programs instaliation. Lots of malware has silent execution and instaliation. You could easily use some of those techniques to make your software more bullet-proof for the lusers.

Wohoo! Some good ideas. But I think I will keep it simple for me as well. I am happy that I can let the computer do some massive calculations for me. ;)
I think I will just make the group I work with at my university buy Intel's compiler and that's it. :D

@Salem:
I've just tested dev-C++. My program runs even slower (30 secs). ;) And I thought I had turned optimizations on ...
I don't know what's wrong. One reason might be that I am using the dev-C++ 5 beta.
Anyway, I like the IDE. I will stick to it.

> I don't know what's wrong. One reason might be that I am using the dev-C++ 5 beta.
Try and find out what the underlying version of the compiler is.

gcc --version

I know dev-c++ uses the mingw compiler, so there are a couple of steps between you and the latest version of the compiler.

gcc 3.2 (mingw special 20020817-1)
Dev-C++ 5.0 beta 8 (4.9.8.0)

I downloaded the package with the IDE and compiler. The only optimization option I used is -O2.

Don't forget that both MSVC++ and Borland support "debug" and "release" modes, which GCC does not.

"debug" adds lots of code to your application for constantly checking the stack, checking referenced pointers, checking that variables are assigned values before being used, etc, which will slow them down a good deal. So make sure to run both of these compilers in "release" mode for best performance.

Quote:

---

Originally posted by _Elixia_
Don't forget that both MSVC++ and Borland support "debug" and "release" modes, which GCC does not.

"debug" adds lots of code to your application for constantly checking the stack, checking referenced pointers, checking that variables are assigned values before being used, etc, which will slow them down a good deal. So make sure to run both of these compilers in "release" mode for best performance.

---

Good point. I've compiled my program via the command line and not the IDE. So, I guess/hope that no debug options were enabled. I've checked the settings again and couldn't find any debug options that are enabled by default, but I may be wrong.

With gcc, debug and optimisation are not exclusive options
manual
From your original post, you seem to be enabling optimisations for each compiler

Quote:

---

Originally posted by Salem
With gcc, debug and optimisation are not exclusive options
manual
From your original post, you seem to be enabling optimisations for each compiler

---

Thanks for pointing that out. The manual was a good read! I didn't think about the miracles of compiler optimizations causing problems with debugging.

I've tested dev-c++ a little more and found out that it is not sufficient to enable some menu settings, e.g. "Code profiling". I also have to manually enter the command line options (e.g. -pg) in the project settings for the compiler and linker. Why do the menu settings not work? Is that a bug? Is it the beta? Or is it "normal"?

Profiling will significantly slow down your program, since it adds code to count how often each block of code is executed, and has to write all that information to disk when the program ends.

> Why do the menu settings not work? Is that a bug? Is it the beta? Or is it "normal"?
Pass - though I would say it is not normal

Quote:

---

Originally posted by Salem
Profiling will significantly slow down your program, since it adds code to count how often each block of code is executed, and has to write all that information to disk when the program ends.

---

Yes, I do know that it slows down my program. I just wanted to find out where the performance is lost. But for a detailed analysis it is too late. Its about 2 o'clock in the morning and I need some sleep.
I'll be back. ;)

P.S.: I can't post the source code because my (scientific) program has not yet been published.