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