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

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.

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..