Mac with Intel C++

Mike Davis only_mortal at mac.com
Tue Jun 20 21:09:51 EDT 2006


I have the trial version of the Intel C++ compiler (ICC) for OSX and  
have it working with XCode and the command line (xcodebuild of  
course!). I've been using it to try and squeeze some more performance  
out of a math intensive application (specifically ICC device link  
profile generation using spectral measurements) and building it as a  
universal binary (GCC for PPC) both sides for 10.4. It's a mixed C++  
(x-platform) and Obj-C/Obj-C++ (UI) app so it has to be a mix of ICC  
and GCC which is supposed to be safe to do. I've been using -O3,  
parallelize, auto-inline and use stack frames (for backtraces with a  
crash) with ICC. Had to add a few architecture specific settings  
(linking -lguide with i386 and optimizing for GCC on PPC -falign- 
loops=32). Debugging ICC code doesn't seem to work inside XCode, even  
with -gfull. I don't mind printfs anyway and've been doing NeXTSTEP  
since 3.1 so I know my way around the K&R world.

To cut a long story short (two days of swearing), I discovered that  
it's not the most reliable compiler in compiling some of the  
"extreme" code we have (from physicist Windows VC6 programmers) and  
have had the compiler itself crash with optimization on when GCC,  
CodeWarrior and the MS compilers (VC6 and .Net) just sailed through.

If you try the Intel compiler out yourself, turn off dead code  
stripping, don't use "@executable_path" for frameworks/dylibs (yes  
you're stuck AFIAK) and link statically to the Intel libraries  
(delete libguide.dylib too!). It has picked up some code errors that  
didn't come up with GCC (-Wmost) or VC6 (probably no warnings!).  
Notably, it spotted logic errors referencing beyond the end of an  
array which was great (and annoying!) i.e.:

short theArray[ 2 ];
theArray[ 2 ] = 666;

You might try it out *just* to see if you spot similar errors in your  
own code! It mostly spits out warnings like GCC does. I was told  
Bounds Checker on Windows hadn't spotted the *two* errors icc  
discovered. Presumably a code path they'd never tried with BC and  
I've not checked all the output of the compiler for the half dozen  
bundles I built with ICC so there may be more. ICC also has a more  
pedantic warning level which reports poor programming style. I had to  
turn it off for the code I have to use!

Anyway, I'm planning to give ICC a twirl with the makefile(s) for  
Icculus Quake 3 to compare a GCC 4 optimized build (-Os, G5  
scheduling, G4 codegen, PIC for the app and auto-vectorization with  
deadstrip) against the Intel compiler. The Intel compiler has similar  
features *but* can also auto-parallelize the code, which is what got  
my initial interest since most modern Macs could leverage this. It's  
*very* aggressive, which is good and bad. I've had source files take  
an hour (I even went to lunch) to compile when they take a few  
seconds with GCC. Binaries also seem to end up a little larger  
(inline code I guess). Either way, for a release build on a dedicated  
build machine (Intel iMac with 1GB RAM) I don't mind waiting if the  
compiler makes my apps run faster than GCC. $600 is nothing compared  
to the cost of me sitting in Shark for a week optimizing code with  
SSE3 vectorization when I ought to be solving business problems.

If I can get it to work, I'll post some benchmarks, offer any source  
changes for Quake 3 (it's stricter than GCC 4) and the edited makefiles.

I seem to recall someone claiming some significant performance  
increases with icc (30-40%). Might have been the Mathematica guys. I  
think it was at an Apple Keynote or so.

In my particular case, I shaved a second off a twenty-three second  
process, which was hardly worth the two days effort. I then ran Shark  
against it and noted that twenty-five percent of the process' time  
was in a bundle I'd not compiled with icc. The metrics of a GCC only  
build (i.e. the released app) used to indicate another bundle...  so  
that's interesting in itself as it indicates the bottleneck moved. As  
it happens, the GCC based bundle was the one icc couldn't compile and  
crashed trying to. Ho hum.

M.

---
www.kohina.com



More information about the quake3 mailing list