Intel's New Compiler Boosts Transmeta's Crusoe

Bram Stolk writes: "Intel recently released its new C++ compiler for linux. I've been testing it on my TM5600 Crusoe. Ironically, it turns out that Transmeta's arch nemesis, Intel, provides the tools to really unlock Crusoe's full potential on linux." It doesn't support all of gcc's extensions, so Intel's compiler can't compile the Linux kernel yet, but choice is nice.

Comments

My results with Linux and NetBSD

[Walter Bell]

The Linux results were interesting, but rather flat: everything benefited from it on my system. However I rebooted into NetBSD and gave the compiler a shot at 'make sys' and 'make world'. Because the NetBSD kernel does not use any nonstandard gcc extensions, it compiled just fine with the new compiler. What I found was:

• The kernel showed a marked performance benefit on the TM5600. On my TM5400 the results were not noticable.
• Most userspace utilities appeared to be quite a bit faster on both CPUs. However, some (one notable example being /usr/local/bin/perl) were much slower with the new compiler. I verified that this was not the case on Linux, so it is unclear to me as to why this happens under NetBSD. Further investigation is needed.

~wally

GCC extensions??

[Reality Master 101]

Wait, the Kernel uses GCC extensions? I thought the Kernel was written in real C, not that bastard GCC version. I've never look at Kernel code, so I'm not sure. Is this really true?

If it's true, I think that's a huge mistake. The Kernel should not be at the mercy of one compiler.

Re:GCC extensions??

[wmshub]

Yes, the kernel uses enormous numbers of GCC extensions. It gets significant performance improvements this way. Perhaps you are willing to give up kernel performance for a portability, but from my experience as an instructor in a Linux device drivers class, you are in the vast minority. A kernel really needs assembly inlines (for example the sti and cli instructions are get inserted pretty frequently in critical code paths), and to do them well you have to use extensions to C.

There are even some places where GCC extensions make the code easier to maintain. For example, the way that device driver entry points are defined is much cleaner (using the "structure member : value" structure initialization syntax) and less error prone than using standard C.

Yes, it might have been helpful a few times to have been able to compile Linux on a non-GCC compiler, but not very often. And GCC runs almost everywhere, so limiting yourself to GCC doesn't limit the architectures you can port to. It really does seem that in this case the benefits outweigh the losses.

Re:GCC extensions??

[srvivn21]

It gets significant performance improvements this way.

But are these performance increases greater than what would be realized if the Kernel could be compiled using icc?

This doesn't address the maintainence issue, but it's something that I am looking forward to seeing in the near future. I figure someone has the time and drive to hack the Kernel source to the point that icc will compile it. Goodness knows, I don't.

Re:GCC extensions??

[rgmoore]

The Kernel should not be at the mercy of one compiler.

"At the mercy of" one compiler is a rather strange description, don't you think? After all, both Linux and gcc are released under the GPL, which means that anyone who wants to use Linux will already be willing to accept what many people view as the most obnoxious feature of gcc (the license). And it's not as though the gcc developers can yank the rug out from under Linux by making it proprietary, refusing to distribute old versions, etc. If anything it would be crazy to make serious modifications to Linux to take advantage of a compiler like Intel's that could be taken away at any minute.

next version will do the kernel

[grover]

...because this is the first question everyone asks as soon as they find out Intel's compiler works on Linux. ;-)

I'm not surprised the compiler helped Crusoe. GCC is a remarkable achievement in portability, but architecture-tailored compilers (MSVC, ICC) do better both in terms of code size and speed - like 30% better. But if you're going to PAY for your compiler, it better not be beaten by a free alternative.

I hope we see distros using icc, and I also hope it spurs further development in GCC.

screw the kernel, recompile the system libraries!

[brer_rabbit]

I wonder if Intel's compiler is binary compatible with gcc. While it's probably against the licensing to redistribute the compiler's math or C library, I wonder if you could compile the gnu math/C library with icc and produce a shared object? An optimized math or other system library would give some decent improvement in performance.

This is very interesting.

[Anton Anatopopov]

It seems as if Intel is playing a very clever game here. If Intel can unlock the true potential of the transmeta's code morphing architecture, then they are giving it a great deal of credibility in the industry.

Given that Intel makes a lot of its money from selling silicon, why on earth would it develop compiler technology which legitimized the approach of one of its major competitors ?

I can only assume that Intel has some fairly advanced code morphing technology of its own, and has been using the transmeta devices as a testbed.

I can just see it now, a 4GHz pentium with code morphing extensions.

I expect this one will be fought out in the patent arena. IBM and Intel are heavyweight players and I don't see either of them giving any ground willingly.

Re:This is very interesting.

[hexix]

I think you're reading more into this. I think it's more like intel released a compiler to generate better optimized x86 code for it's processors. And since transmeta does code morphing from x86 to whatever it's instruction set is, a side effect from better optimized x86 code would be faster code morphing of that better optimized code.

You make it sound like it only improves transmeta's chips and not others. I really doubt that's what's going on here.

Not surprising

[d5w]

This isn't a particularly startling result. Many of the things an x86 compiler has to optimize for these days are similar across all processors: e.g., regular branch patterns are faster than unpredictable ones; you have very few visible registers; it's helpful to have closely associated data in the same cache lines; you're usually better with the RISCy subsets of the ISA; etc. Intel would have had to go well out of its way to optimize for their own chips and pessimize for others, and I can't see Intel bothering.

Re:KDE performance

[hexix]

I was wondering the same type of thing. Is this going to be helpful to KDE in any way?

It's my understanding that the problem is with the gnu library linker, but I don't know much about compilers. Does this intel compiler have it's own library linker or does it still use the gnu one?

If it does use it's own can we expect to see dramatic speed increases if we were to compile KDE with this intel compiler?

Here's another news flash

[kijiki]

Intel's compiler boosts AMD Athlons too.

AMD uses (or at least, used to use, I haven't checked lately) Intel's compilers for their SPEC runs.

Intel's compiler is the best available for CPUs that implement the x86 ISA. Transmeta implements that ISA, so why does this news surprise people?

Re:Real Men

[porky_pig_jr]

Real men write machine code directly, in hexes. Who needs the pinko sissy commy fag Assembly Language?

probably binary compatible or close

[kingdon]

There shouldn't be a lot of problems for binary compatibility with C (e.g. glibc, libcurses, X libraries). (Famous last word is "should" so unless someone does some testing and reports the results, take with a grain of salt). For C++, it gets a bit murkier. The Intel page has a section called "Compatibility with the GNU Compilers". They refer to the C++ ABI that was developed for Itanium, which I believe is basically the same ABI as GCC 3.x (it has mangled names which start with _Z). When they say they aren't compatible with g++, I suspect they mean g++ 2.95.x and maybe even 3.0 or 3.0.1, I'm not sure that sentence applies to 3.0.2 or (certain unspecified) future releases of 3.x.

Re:probably binary compatible or close

[be-fan]

From what I've heard, yes it is 'C' compatible. Of course, you can't compile a lot of system libs with it anyway, because glibc, for example, uses GCC extensions. Generic stuff like math libs should be doable, but aren't very widely used in a system. X (since it is good about different compilers) would be the really interesting test case, maybe I'll try this weekend.

Re:Without the kernel, what good is it?

[Sentry21]

So, again, until you can actually compile the kernel, it's a fascinating breakthrough, but one with little utility to the real world.

So what you're saying is that the only really useful use of a compiler is to compile the Linux kernel?

That's quite possibly the silliest thing I've heard someone say. Try:

Son: "Look ma, I got the fastest engine in the world for my car! Now I can drive faster than anyone else!"

Ma: "Um, sonny, it can't play MIDI files or make julean fries, so it's totally useless."

Totally wrong. There are thousands of pieces of software out there. The Linux kernel is merely one.

--Dan

Wrong...

[Carnage4Life]

What if, besides caruso, Intel's compiler is actually a BETTER compiler than gcc on intel hardware? Then were stuck using gcc for compiling the kernel when something better is or might be some day available. . Locking the kernel to a compiler is a BAD THING[tm].

The Linux kernel is not only available on Intel chips. It is available on ARMs, DEC Alphas, SUN Sparcs, M68000 machines (like Atari and
& Amiga), MIPS and PowerPC, as well as IBM mainframes.

Which makes more sense? Targetting a cross plartform compiler like gcc are targetting individiual compilers for each platform Linux runs on?

Re:Uh...

[strangemoose]

hmmm... The reason Intel's compiler can't compile the kernel is that the kernel uses extentions that only gcc has. like __attibute__((packed)), ARGV style macros and embeded blocks:

#include useless_macro(a, b...) ({ printf(a, ##b); })

No kernel, so what?

[labradore]

It seems that nearly everyone has missed the point of this article. POVRay is a program that makes very heavy use of the FPU. ICC speeds up POVRay's performance by 16% to 28% in the x86 architecture compared to GCC. In other words x86 FPU's are faster executing code from programs built with ICC. The Linux kernel (and almost any kernel for that matter) has very little floating point code. Therefore one cannot assume that ICC would improve kernel performance, even if it could compile it.

The real story here is that the maintainers of GCC aught to look carefully at their optimization code for x86 FPUs.

I'm betting that Intel developers have done their best to make use of the P4 cache. Since Transmeta CPUs do work recompiling programs on the fly they have larger caches (128KB L1 + 512KB L2) than the Athlon (128KB L1 + 256KB L2) and the Pentium 4 (20? KB L1 and 256KB L2). ICC is probably also highly agressive in implimenting SSE and SSE2 instructions. Transmetal CPUs also use VLIW instructions in core wich are by their nature highly parallel (compared to native x86). Even if the Transmeta chips can't use SSE and SSE2 they may benefit from the parallel-oriented optimizations that ICC probably makes.

On a different note: in a program like POVRay that executes basically the same tight loop of instructions mega-gazillions of times during a scene the Transmeta chip's software can have the opportunity to highly optimize the program. I would like to see the stats on the second and third runs of that rendering to see how much the Transmeta "code morphing" improved the performance. It would be very interesting if the GCC and ICC built POVRays perfomed at almost the same speed after a few runs. It would obviously be a great proof of the value of Transmeta's design. I for one have always wondered what the code morphing stuff would be able to do if it were able to interface with the operating system and recompile and save the entire system back to the hard disk as it goes through the optimiztion processes. (I suppose that errors could be highly disasterous.)

That's just my $0.02 and I'm no expert so I could definately be wrong.

This is not a signature.

Re:Uh...

[Billly Gates]

According to the ansi standard all c++ compilers must compile c code.

Re:Kernel

[be-fan]

Because Linux is a real project and not some theoretical programming plaything. Kernels have all sorts of weird problems to deal with (passing parameters via registers, inline ASM, structure packing, alignment, etc) that normal application code doesn't have to bother with.

What about gcc 3.0 ?

[Stormie]

Interesting benchmark of Intel's compiler vs. gcc 2.95.4, but what about gcc 3.0? I'd love to see how that compared, given that I've heard such mixed opinions about whether it's optimisation tends to be better, worse, or the same as the 2.95 series..

Re:What about gcc 3.0 ?

[the Atomic Rabbit]

From what I gather reading the mailing lists, GCC 3.0 was a features release, and 3.0.x were bugfix releases. There is generally very little performance benefit over 2.9.x (and the occasional performance regression.)

GCC 3.1 will focus on optimization, building on the new infrastructure implemented with 3.0. If you're brave enough, you can pull from CVS and try it out for yourself.

Results not surprising

[jgarzik]

These are not surprising results. Even the gcc developers will admit that many general, not-architecture-specific optimizations done by commercial compilers are not performed in gcc. Most new CPUs, not just Intel CPUs, can benefit from a smarter compiler to take advantage of features like data prefetching, instruction bundling and pipelining, profile-based (feedback-based) optimization, data and control speculation, and much more.

The gcc "open projects" page gives people a good idea of what remains to be done on gcc. The minutes of the IA-64 GCC summit are especially interesting and informative, because it gives a good idea of the current state of GCC and also what GCC needs to be a competitive compiler in the future.

Bottom line: Do not be surprised when commercial compilers beat gcc performance. It's catching up, but it's still got a long way to go.

GCC Home Page

This is a FP-based test

[Florian Weimer]

Floating point performance doesn't tell much about integer performance and vice versa (remember the Itanium). It is well-known that GCC has got its problems with the stack-based x86 floating point unit (especially pre-3.0 versions; some people claim that 3.x is faster).

Since the kernel doesn't use floating point instructions, it's not such a big loss that you can't compile it with icc yet. In addition, compiling the kernel (which is not written in ISO C, let alone ISO C++) might uncover a few bugs in the kernel code and the compiler, and it's not very likely that the kernel folks are able or even willing to help you if you use a strange system configuration with a proprietary compiler.

About the Intel Compilers...

[ChaoticCoyote]

...I wrote up a short "First Look" regarding the "noncommercial" (i.e., no-cost) versions of Intel's C++ and Fortran 95 compilers for Linux. I look at licensing, too, and have Intel's comments posted as well.

You can also look at some rudimentary benchmarks comparing gcc 3.0.1 and Intel C++ 5.0.