In yesterday's post, I mentioned how to tell the Xorg monolith which compiler to use, Sun Studio cc or GNU gcc. Figuring out which one you wanted to use used to be somewhat clear - if you had paid all that money for Sun Studio cc, you probably wanted to use it, otherwise gcc was free. Things got a bit murkier a few months ago, when Sun Studio compilers were made available for free to members of the OpenSolaris community, and now this week, Sun Studio 11 was released with a free-to-use license for everyone.
So now both compilers can be used without having to pay anyone - which one should you use to compile Xorg? First the easy one - though the Sun compilers now support Linux, neither the Xorg monolith or modular builds work with it yet on Linux. To get the 6.9 monolith working, much of the
#if HasSunCC bits from sun.cf would probably need to be replicated into the linux.cf Imake configuration and gcc-specific bits replaced in linux.cf and xorg.cf. For 7.0, I tried a couple of months ago with the Sun Studio cc beta and found that autoconf couldn't yet handle building with the Sun compilers - it was able to recognize that it wasn't gcc or any other known compiler, but couldn't quite get the options set right. This patch to autoconf's config.guess got me a little farther, but I still couldn't build it all:
--- config.guess.orig 2005-08-17 15:56:41.000000000 -0700 +++ config.guess 2005-08-17 15:57:31.000000000 -0700 @@ -964,7 +964,7 @@ LIBC=gnulibc1 # endif #else - #ifdef __INTEL_COMPILER + #if defined(__INTEL_COMPILER) || defined(__SUNPRO_C) LIBC=gnu #else LIBC=gnuaout
On Solaris though, both the Sun & GNU compilers should work well. As mentioned before, I build the Xorg CVS trees regularly with both and try to fix problems as I find them, but I haven't had a chance to do any comparative performance benchmarking yet. (I know conventional wisdom used to be that gcc had better performance than Sun compilers on x86, and Sun compilers made faster binaries than gcc on SPARC - but a lot of work has gone into the x86/x64 compilers in recent Sun Studio releases, and the Sun Studio team have posted a number of record benchmark scores with the Studio 11 version.)
gcc has an advantage in some areas because it's the compiler most of the Xorg developers use and most other vendors build with, so gcc extensions are commonly used - for instance, the MMX optimization code in libfb for accelerating alpha-blending and anti-aliasing in Xorg still requires gcc (the new MMX intrinsics support in Studio 11 comes close, but isn't completely compatible, though the code probably could be ported with a little effort). A number of areas use #ifdefs and support both Sun Studio cc & gcc - for instance, the new macros in Xfuncproto.h to control symbol visibility use gcc attributes and Sun Studio's __hidden/__global keywords. (There's basically three compilers we know of that are still used somewhat regularly and well supported in Xorg - in order of support/popularity, they'd be gcc, Sun Studio, and USLC for Unixware/OpenServer. There's support in the Imake configs for Intel's compiler, but there are reported bugs against it, and I don't know if it currently works.)
So which compiler should you use? I guess that depends on what you're trying to do. Of course, we use Sun Studio tools for the Solaris builds (though we're still on Studio 10 for the official Nevada builds, but are testing with Studio 11 and preparing to switch to those soon), so if you're trying to match our builds, that's the way to go. Otherwise, the best answer I can give is to try both out, play with the different optimization tuning flags, and see which works best for you.
On the other hand, for the rest of the toolchain, I definitely find I'm more productive with the Sun Studio tools - perhaps that's partially because I know Sun dbx much better than gdb, but dbx features like the integrated Korn shell and memory leak/access checking (though access checking works better on SPARC than on x86) are ones I miss when I have to use gdb. I haven't seen anything in the GNU toolchain to even compare to the Performance Analyzer.