MinGW vs Cygwin

[Sirber]

Which one provide fastest binary?

[Episode]

Hmm, aren't they both using GCC for compiling? Iirc only difference between those two is that Cygwin is complete GNU toolset for windows and programs compiled with it always need cygwin.dll for running. Minigw on the other hand is just minimalistic set of compiling tools to make native Win32 programs by using microsoft's own libraries, so they work as they are without any extra dll's. I don't think that these two have any difference in binary speed. Only compiler version and optimization flags should affect on that one. But then again, I'm just a n00b, so please feel free to correct me :D

But what does this have to do with Linux and Mac OS? :confused:

[Sirber]

GCC is linux compiler. People using it have more chances to know the answer than native Windows users. :)

[d'Oursse]

even if gcc is a linux compiler, it exists for cygwin and mingw
gcc does not provide the fastest builds, compared to icc, for example

[Kurosu]

Originally posted by Sirber
GCC is linux compiler. People using it have more chances to know the answer than native Windows users. :)

GCC is the GNU Compiler Collection (aka GNU Crap Compiler). It is not only "linux compiler":
http://gcc.gnu.org/install/specific.html

As for your answer, cygwin implements a layer (dunno if it POSIX or whatever standard) that is indeed compatible with linux (Cygwin is AFAIK maintained by RedHat). MinGW relies on Win32 API. Consequently:
- MinGW directly calls win32 API, and only offer it, so many "linux" programs may not compile
- cygwin for Window uses a compatibility layer that was reimplemented in a way or another. Probably to translate some calls to the Win32 API. You have to include shared libs to make it work. But it has a MinGW compatibility mode (-mno-cygwin), and basically, it won't make much difference with MinGW.

Draw your own conclusions, I'd tend to prefer MinGW over Cygwin, but not for performance reasons. Given that the flags to gcc and the gcc version tend to produce impredictible results, I wouldn't even dare compare the compilers provided with each environment if they use the same version. Otherwise, your question amounts to "what is the best version of gcc"? I even think you won't see much difference (<2%).

[Sirber]

Thanks!

[Joe Fenton]

GCC might not generate the fastest code, but it can hardly be called crap. GCC is THE industry standard. All UNIX, BSD, and linux distros use it, both for development on the OS, AND development OF the OS.

[Kurosu]

Originally posted by Joe Fenton
GCC might not generate the fastest code, but it can hardly be called crap.
I should have written "that some people refer to as the [...]". I wasn't stating my opinion, although I agree I was letting way to one. As for the reasons I allowed such thing is that Sirber was expecting some performance increases while there are often no sure way to assess there will be with gcc. -O1 with some flags can be faster than -O3, for instance; gcc 2.95 has a better (compilation time*memory used)/binary performance ratio for some people than any of the newer with __GNUC__ >= 3

Now that is clear.

GCC is THE industry standard. All UNIX, BSD, and linux distros use it, both for development on the OS, AND development OF the OS.
Not all UNIX, which often have (had?) their own compiler. As for "THE industry standard", I guess it depends on your standard. But overall, yes, I agree.

[Joe Fenton]

Yeah, some UNIX does have their own compiler... SCO UNIX does, but the engineers tell their customers not to use it, to use GCC instead. But I'm quite sure AIX from IBM has a good compiler they recommend folks use. :D

The biggest area using gcc is video games. Everybody but MS uses gcc, and has for the last decade. SEGA started using gcc about the time the 32X was released. Sony has used gcc on all their machines (PS1, PS2, and PSP). All indications are the PS3 will use gcc as well.

So while it's hard to say anything is THE standard, gcc has some points in its favor.

[Sirber]

Originally posted by Joe Fenton
The biggest area using gcc is video games. Everybody but MS uses gcc, and has for the last decade. SEGA started using gcc about the time the 32X was released. Sony has used gcc on all their machines (PS1, PS2, and PSP). All indications are the PS3 will use gcc as well.
Any proof? Easy to say :)

[Joe Fenton]

Of course not! There's no proof of anything related to the PS3 yet. We have a few pictures and vague description by Sony. No firm word even on the CPU other than it will be a Cell. The only info in that area is coming from IBM, not Sony.

Speculation is the name of the game right now, even for the XBox 360, and it's supposed to ship around Christmas!

So let's speculate and say IBM makes the compiler for the PS3. That would probably be better than gcc. I know all the homebrew people are rooting for gcc because that gives them more info on the system than a close-source proprietary compiler.

[Sirber]

Any proof about the other console? :)

[Episode]

Hmm, where should I start..

It has been said that IBM will indeed provide compiler for PS3 since they are already part of STI group (Sony, Toshiba and IBM) which is making the Cell processor. Cell is based on POWER architecture and it shares many similarities with PowerPC architecture, but it also has some differences.

For example, PS3 will have one Cell processor which has 8 programmable virtual units similar to those that were also present on PS2 (there were two of them). While Cell's main core is running at 3,2Ghz clockspeed, many tasks that require high computing speed are done by using those virtual units, since they are specialized on those kind of tasks. I don't know about Cell's SIMD instructions, but I assume they are similar to PPC's Altivec. Using those with GCC is not possible at the moment and using GCC would be also pretty stupid too since it's pretty poorly optimized for PPC (or any platform other than x86 (and it still sucks on that one too)).

As for other consoles, I don't believe that most of them used GCC, since none of them was actually based on x86 hardware (except Xbox of course, but MS used their own compiler anyway). Using compiler that produces slow binaries on platform that actually needs to work as fast as possible is just not really smart thing to do.

I also don't know where did you heard that Sony used GCC on PS1 and PS2? I know that Sony has released Linux-kit for PS2, but that still doesn't mean that Sony is actually using Linux and GCC by themselves. Do you have any proof on this one?

Originally posted by Joe Fenton
So let's speculate and say IBM makes the compiler for the PS3. That would probably be better than gcc. I know all the homebrew people are rooting for gcc because that gives them more info on the system than a close-source proprietary compiler.
I don't understand how using closed-source compiler gives you less information about the system. It should give you more since it's developers have very likely had full specs on that system. That's usually the main reason why GCC is so slow; developers don't have full specs on hardware, so they can't optimize it well enough (x86 is pretty well-known architecture, so in that one it's not huge problem). Also remember that Cell is not intended to be used only on PS3. IBM has already plans to use it on their mainframe systems.

And of course, feel free to correct my views if you find something that sounds very wrong to you (and grammar too, since my English is so horrible :D).

[Joe Fenton]

They're vector units, not virtual units. :D

GCC has always been on and for multiple architectures since the get-go. That's why it was used by those other consoles. Where else where you going to get a mature and tested compiler for the SuperHitachi CPU? Or the MIPS? Or the 68000? GCC of course.

If you check the patch files released by Sony as required by the GPL for GCC, you'd see they cover the PS1 and PS2 and had nothing to do with linux. That leads to what I meant by gcc giving people more info about the systems - the PS2, for example, has three main components - the EE, the VUs, the IOP.

The IOP is mostly a straight MIPS 3000 32bit CPU. The EE is mostly a 64bit MIPS CPU. The VUs are simple vector processors. The changes Sony made to gcc to compile for those units tell folks how those chips vary from "standard" chips. What additional commands are in the EE - what commands AREN'T in the EE. That sort of thing.