LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal) [LWN.net]

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 27, 2009 19:06 UTC (Fri) by jdahlin (subscriber, #14990) [Link] (4 responses)

In related news, expect clang to be able to compile Linux in the near future. Will be interesting to see the results, I doubt there will be a *big* difference in practice between different compilers. 8-9% seems like an exaggeration, but I'd love to be proved wrong.

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 27, 2009 19:08 UTC (Fri) by jdahlin (subscriber, #14990) [Link]

Make that clang link correct.

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 27, 2009 19:32 UTC (Fri) by ianw (guest, #20143) [Link] (1 responses)

I'm sure the IA-64 kernel (used to, at least) build with icc. I distinctly remember talking to someone from SGI at the LCA dinner in 2005 about using the Intel compiler for building the IA-64 kernel (where it would be a bigger win, if anything) - they had tried it and it didn't really make any difference as the bottlenecks were elsewhere.

So I'd also be dubious about 8-10% system-wide improvements.

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 27, 2009 21:43 UTC (Fri) by xorbe (guest, #3165) [Link]

That +40% peak, +8-9% average quote was from FIVE years ago...

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 28, 2009 0:09 UTC (Sat) by nix (subscriber, #2304) [Link]

I find it even less likely that a 9% difference in kernel speed is going
to make anything like as much of a difference to the performance of the
system as a whole. If the system is CPU-bound in the kernel, that is
usually a bug.

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 27, 2009 19:19 UTC (Fri) by jengelh (guest, #33263) [Link]

ICC seems to be supported well enough for long time already, so what's with this trivial news?

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 27, 2009 19:39 UTC (Fri) by SLi (subscriber, #53131) [Link] (13 responses)

Strange. In my experience GCC has surpassed ICC in code quality long
ago. It used to be true in the era of maybe gcc 2.95 and ~3.0 that ICC was
better, but those days are long gone.

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 27, 2009 21:27 UTC (Fri) by flewellyn (subscriber, #5047) [Link] (12 responses)

That's been my experience as well. The last comprehensive speed test between the two, which I read three years ago (can't remember the URL), had GCC outperforming ICC in terms of compiled code performance on some benchmarks, ICC showing better performance on others, and in the remainder, the difference was too small to be significant. In some cases, the difference depended on which compiler options were selected; using -fomit-frame-pointer gave GCC a significant boost, for instance.

Overall, there was no clear winner in terms of performance, and GCC has enough other advantages (portability, openness, compiles more languages) to make it an attractive solution.

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 27, 2009 21:38 UTC (Fri) by dlang (guest, #313) [Link]

not to mention that many aspects of the kernel are very carefully tuned to produce very good code.

as a result I wouldn't expect that big a difference compared to a tailored kernel with gcc. if you compare the generic disto kernels to one tailored you have a different story. just taloring the kernel and using gcc will make a significant difference (easily 10% or more depending on the cpu)

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 28, 2009 4:52 UTC (Sat) by dkite (guest, #4577) [Link] (8 responses)

Wasn't the advantage with icc that it could optimize code for the Intel
processor that for the life of me I can't remember the name of?

Derek

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 28, 2009 13:48 UTC (Sat) by nix (subscriber, #2304) [Link] (7 responses)

IA64?

Call me when you see one of them. It might be easier finding a working
crystal ball, or a gate to Fairyland. (I've never even sshed to one, or
been employed by anyone who has one.)

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 28, 2009 18:08 UTC (Sat) by Trelane (subscriber, #56877) [Link] (3 responses)

I have one of them that I'd rather like to use. It's getting a little old in the tooth, though. From what I understand, their floating-point performance is superb, which is critical for my uses.

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 28, 2009 18:11 UTC (Sat) by Trelane (subscriber, #56877) [Link] (2 responses)

I should also mention that the main IA64 use case anymore, i.e. floating point, makes the kernel more or less irrelevant. The main bottlenecks in heavy floating-point code aren't going to be in the kernel.

The other reason I'm interested in the intel compilers, mkl, and ipp is that they support the atom architecture, which gcc doesn't yet.

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Mar 1, 2009 9:57 UTC (Sun) by epa (subscriber, #39769) [Link] (1 responses)

Does anyone have meaningful performance comparisons of Itanic versus x86_64 for integer performance? (e.g. the classic Linux kernel compile benchmark - for a fair test, one of the two systems would have to cross-compile.)

IA-64 vs AMD64 integer performance

Posted Mar 6, 2009 17:54 UTC (Fri) by anton (subscriber, #25547) [Link]

SPECint is usually considered a good integer benchmark. Here are some results:

                                                   Result Baseline
HP Integrity rx2660 (1.66GHz/18MB Dual-Core Itanium) 17.0     15.7
ASUS P6T WS PRO (Intel Core i7-965)                  35.2     31.5

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Mar 1, 2009 15:46 UTC (Sun) by oseemann (guest, #6687) [Link]

I also was surprised when I learned last year that a customer of ours bought an Itanium machine as his OLTP host (POS terminal front end processor). Thought they were long dead. The Tandem OS running on the machine(s) had some peculiar limitations, e.g. only upper-case file names and max 8 chars. Who would have thought such systems are deployed in 2008!

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Mar 2, 2009 21:04 UTC (Mon) by dlapine (guest, #7358) [Link]

I have about 1800 Itaniums running in my linux cluster (dual socket). 1700 running user jobs and about 100 for filesystem serving.

http://www.ncsa.uiuc.edu/UserInfo/Resources/Hardware/TGIA...

We have over 1024 of them running on our SGI Altix machines.

http://www.ncsa.uiuc.edu/UserInfo/Resources/Hardware/SGIA...

The itaniums are good for scientific computing.

SDSC had some as did Caltech and Argonne Nat'l Labs.

Given that these were released as early as 2002, they don't have energy saving features.

As for performance, Our Mercury cluster was fairly comparable to our old Xeon cluster:

http://www.ncsa.uiuc.edu/UserInfo/Resources/Hardware/Xeon...

Given that they had about 1250 servers versus the 872 on Mercury and the
top500 numbers were about 10TF versus the 7.2TF Mercury had.

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Mar 3, 2009 16:09 UTC (Tue) by zlynx (guest, #2285) [Link]

I've got two.

GCC being superior?

Posted Feb 28, 2009 16:33 UTC (Sat) by ikm (guest, #493) [Link]

Are there any links to back this up? Would be wonderful news.

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Mar 2, 2009 6:44 UTC (Mon) by muwlgr (guest, #35359) [Link]

This one is a comparison I remember -

http://www.coyotegulch.com/reviews/linux_compilers/index....

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 27, 2009 19:44 UTC (Fri) by darthscsi (guest, #8111) [Link] (2 responses)

How is this news? ICC compiling linux was news in the late 90s. Several papers have used llvm to optimize or transform the linux kernel. I've run llvm optimized linux kernels (2.6.27).

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 27, 2009 20:45 UTC (Fri) by jdahlin (subscriber, #14990) [Link] (1 responses)

llvm-gcc and clang is not the quite the same thing. The former uses gcc to parse and generate the llvm intermediate form which is then transformed into binary form.

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Posted Feb 28, 2009 2:01 UTC (Sat) by darthscsi (guest, #8111) [Link]

Yes. llvm-gcc uses gcc as a parser and converts gimple to llvm. clang parses and transfroms its AST to llvm. Both go through roughly the same optimizations once you get into llvm. (I admit I wrote the llvm alpha backend and am one of the people with papers published using llvm to do things to the linux kernel, so I am not without bias).

having two compilers is good

Posted Feb 27, 2009 22:02 UTC (Fri) by Alterego (guest, #55989) [Link] (19 responses)

...for security:
http://www.schneier.com/blog/archives/2006/01/countering_...

And wrt performance, when SSE2/3 are used icc 9 is significantly faster than gcc 4.1 even on AMD cpu ! (tested in my previous lab were researchers did very heavy numerical computations)

having two compilers is good

Posted Feb 27, 2009 23:11 UTC (Fri) by dtlin (subscriber, #36537) [Link] (5 responses)

AFAIK the Linux kernel avoids using SSE just like it avoids the using the
x87 FPU.

The kernel's not supposed to be computation-heavy anyways, that's
userspace's job. I'm not convinced that the compiler matters much beyond
"correctness".

having two compilers is good

Posted Feb 28, 2009 0:15 UTC (Sat) by nix (subscriber, #2304) [Link] (4 responses)

Some particularly computation-heavy things use SSE or MMX as need be: if
the lumps of data being manipulated are large enough, the save/restore
overhead is worth it.

(The largest such component is md/raid6.)

having two compilers is good

Posted Mar 1, 2009 21:04 UTC (Sun) by mb (subscriber, #50428) [Link] (3 responses)

> (The largest such component is md/raid6.)

So well, but this is hand-tuned assembly code, right? So I think the type of C compiler still doesn't matter for this...

having two compilers is good

Posted Mar 1, 2009 22:44 UTC (Sun) by nix (subscriber, #2304) [Link] (2 responses)

Well, yes. The type of compiler only matters if the compiler knows enough
to translate loops directly into SSE instructions. Can any compiler do
that yet?

(I'm ignoring things like GCC's SEE intrinsics here, as they're only
useful if you only want a few of them: they're just too ugly to maintain
otherwise. I've seen codebases with hundreds of intrinsics in a row, and
they are *always* clearer when translated into a .S instead.)

having two compilers is good

Posted Mar 1, 2009 23:49 UTC (Sun) by nix (subscriber, #2304) [Link]

Obviously when I said 'SEE' there I meant 'SSE'. GCC hasn't defined a
whole new bizarrely-named instruction set of its very own. ;)

having two compilers is good

Posted Mar 2, 2009 8:03 UTC (Mon) by joib (subscriber, #8541) [Link]

Well, most production quality compilers, gcc included, are capable of vectorization these days. For gcc there is the -ftree-vectorize option (included in -O3 in newer versions), and -ftree-vectorizer-verbose= option for printing diagnostics.

For C and C++, you probably have to mark some of your argument pointers/references with __restrict.

Ken Thompson's Reflections on Trusting Trust

Posted Feb 27, 2009 23:18 UTC (Fri) by pr1268 (guest, #24648) [Link] (6 responses)

Just curious - Seeing how Ken Thompson's (in)famous "back door" in the old C compiler was discovered¹, doesn't it seem possible to discover such a Trojan Horse in ICC? If not, then is it possible that such a Trojan is lurking in GCC (or TCC, or any other open-source compiler)? If my question seems silly or excessively rhetorical, then I plead guilty to naïveté.

¹ I hazily recall a computer security professor mentioning that the Unix kernel enlarged by one byte each time it was compiled with Thompson's C compiler (without any source modifications)—this raised all sorts of suspicions until Thompson came clean with what he had done.

Ken Thompson's Reflections on Trusting Trust

Posted Feb 27, 2009 23:41 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] (4 responses)

Sigh. Not again.

GCC is built with a three-stage bootstrap procedure. First the compiler is built with some C compiler, that might be an older GCC, or might be a different compiler entirely. The result is "stage 1". Next, GCC is built again, by the "stage 1" compiler, to produce "stage 2". Finally, GCC is built with "stage 2" and the result is "stage 3". We then check to see whether "stage 2" is bit-for-bit identical (other than date stamps in object files) with "stage 3". If it isn't, we report a failure. The key is that this process is designed to remove any dependence in the final compiler from the initial compiler. This check is run every time gcc is built from source, and every developer must run this check before any patch is acceptable (plus all the other regressions, of course).

Now, suppose that you suspect that your GCC has a version of the Thompson hack installed. The check is simple: just do the three-stage bootstrap starting with a different compiler, and verify that you get an identical result. You've either proven that there's no hack, or that the other compiler has the hack too. You can repeat the process using cross-compilation. If you carry this out, you'll be forced to conclude that either there is no Thompson hack, or else that every C compiler you tried has the identical hack. Since I've used both Sun's proprietary compiler and GCC to build GCC on Solaris, I can confidently state that I proved that either GCC is clean or Sun's proprietary compiler is contaminated.

Ken Thompson's Reflections on Trusting Trust

Posted Feb 28, 2009 0:18 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

All this proves is that the GCC Cabal has sneaked appropriate patches into
every compiler capable of building GCC, even the proprietary ones.

(This is quite practical, using some of the money left over from the
construction of the secret Antarctic base. Rumours that the SC has orbital
compiler-control lasers are entirely without foundation.)

Ken Thompson's Reflections on Trusting Trust

Posted Feb 28, 2009 22:46 UTC (Sat) by JoeBuck (subscriber, #2330) [Link]

Shhh.

Ken Thompson's Reflections on Trusting Trust

Posted Feb 28, 2009 1:21 UTC (Sat) by pr1268 (guest, #24648) [Link]

Thank you, sir, for the description of how GCC is built. And my apologies for making you sigh. :)

Again, my question bordered somewhere between silly and rhetorical, but I was (and still am) fairly certain that the GCC devs considered the possibility of Thompson's hack when designing and implementing the compiler.

Ken Thompson's Reflections on Trusting Trust

Posted Mar 2, 2009 14:11 UTC (Mon) by forthy (guest, #1525) [Link]

This doesn't proof anything. If the compiler checks for duplicates (hack already there → don't install it again), then your stage 2 equals stage 3. Of course the hack in GCC would be in the source of GCC, sufficiently obfuscated ;-), so stage 1, 2, and 3 are functionally equivalent. The only suspicion could arise if you removed the hack from GCC's source (by wondering what said weird code does and commenting it out to try), and it would not disappear when recompiling. Doing such a check is obviously the first thing to do to avoid being discovered.

Ken Thompson's Reflections on Trusting Trust

Posted Feb 28, 2009 0:19 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

I think the story you've offered (with Unix growing by one byte) is apocryphal, but feel free to go find a source.

Ken Thompson's point is philosophical, more than practical. It tells us something about the nature of what we're doing, rather than having some immediate practical lesson like "fire anyone devious who works for your software company" or "always use two compilers".

The system is too complicated for us to understand from the ground up how it all works, so we trust some aspects of the system implicitly. Thompson's example is the compiler, but it could as easily be the CPU or any other sufficiently complicated component. Probably we have long since passed the point of no return. All we can do is be aware of the trap we have set ourselves.

having two compilers is good

Posted Feb 28, 2009 15:14 UTC (Sat) by joib (subscriber, #8541) [Link] (4 responses)

In my experience the difference between Intel and gcc compilers for numerical code is, as a rough rule of thumb, maybe 10% in favor of Intel. I.e. it doesn't really signify. The trick with gcc is that while for the intel compilers is suffices to use just "-fast", for gcc the equivalent optimizer options is something like the following:

-O3 -ffast-math -funroll-loops -ftree-vectorize -march=native -mfpmath=sse

having two compilers is good

Posted Feb 28, 2009 18:18 UTC (Sat) by Trelane (subscriber, #56877) [Link] (3 responses)

might also check out the profiling support in gcc (compile with profiling, run the program in a hopefully representative way, and then re-compile based upon the profiling information), and some things like dropping frame pointers. Oh, and -mfpmath=sse and -march=native (in latest stable gcc; you might need to actually specify your arch if you're on an earlier version)

Have you benchmarked on atom? I'd be interested in that; I've not benchmarked on atom yet. I can tell you for certain that the speed difference on a sample piece of code I ran (I think it was relaxation to solve electric potential) saw a significant boost when compiled with intel's compiler vs gcc on ia64.

I'd expect atom's performance to be sensitive to scheduling, due to the in-order execution. You might overcome some of the limitations by explicitly marking hot and cold sections (latest stable gcc) and especially by marking probable/improbable branches (likely/unlikely attributes in gcc 4 and later (?))

having two compilers is good

Posted Feb 28, 2009 18:19 UTC (Sat) by Trelane (subscriber, #56877) [Link]

oh, you already have native and sse, nm. ;) Couldn't see your post while writing. Sorry.

having two compilers is good

Posted Mar 1, 2009 0:21 UTC (Sun) by joib (subscriber, #8541) [Link] (1 responses)

No, I haven't tested atom. There are a few people working on atom specific optimization for the gcc backend, see

http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00923.html

These improvements will likely make it into 4.5, maybe a year or so from now. I agree that as atom is in-order it's more sensitive to compiler scheduling. Perhaps that will widen the gap between gcc and the Intel compilers, I don't know.

As for IA-64, that is such an oddball architecture with a very small user base that it's not exactly surprising that gcc developers haven't spent that much time on it. Intel obviously has the motivation to make IA-64 look good compared to other architectures.

having two compilers is good

Posted Mar 1, 2009 4:17 UTC (Sun) by Trelane (subscriber, #56877) [Link]

Looking forward to seeing those patches land. I use atom on my main laptop (eee 901), and I'd love to have good performance on it. I wonder how it fares in flops/watt and flops/USD to other chips. If it's good, I might have money for an atom cluster in a few years.

having two compilers is good

Posted Mar 1, 2009 8:24 UTC (Sun) by Trou.fr (subscriber, #26289) [Link]

I also discovered that GCC's handling of SSE intrinsics is (was?) absolutely terrible, at least in 4.3.
The assembly code for each operation looked like -O0 output, with loads and stores from memory at EACH step.
By hacking the original source code it was possible to trick GCC into generating better code but the register allocation still looked poor.

ICC (v10) by comparison, managed to be 3 times faster vs non hacked GCC code and still 2 times faster after hacking.