Slashdot Mirror
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.
...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.
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.
Intel's compiler can compile both C and C++.
Exactly. One benefit of x86 instructions (the only benefit? ;-)) is that they are pretty compact. And that wouldn't be such a big deal except that it means more of them fit in cache, you can fetch more instructions in one memory cycle, and that sort of thing. So using native transmeta instructions across the bus could easily slow things down (kind of a thought experiment, since as far as I know they haven't done it even for testing purposes).
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.
Sun's compilers cost $2000 if you want C++...
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
Transmeta is NOT RISC, it is VLIW with a x86 to VLIW optimizing translator.
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?
Sig? What sig?
According to the ansi standard all c++ compilers must compile c code.
http://saveie6.com/
Well, code morphing itself does not worth the performance. For example, let's compare Intel Celeron vs Crusoe with the same speed. I doubt that Crusoe can even beat Celeron, even with the super-optimized morphing that has run for months.
The problem here is that no matter how good is the morphing, it is still "emulation". You can do morphing or maybe mixed with dynamic recompilation, you cannot beat the real stuff that run natively. There are lots of examples.
The real power of Crusoe processor is that it is a VLIW processor, which can jam-pack several instructions into one. *This* is the real power. Notice that P4 adopt this solution too (3 instr to 1). Intelligent compiler can arrange the machine code so that the instruction bundles are used very efficiently. Now, let's say that Crusoe has 32-bit instruction wide and it has 128-bit. Theoretically, you can jam-pack 4 instruction at once, thus yielding 4 times the MHz rate. *This* is what I really want to see.
About the power problem: I really pessimistic about processor power that can prolong battery life n times (with n > 2), as claimed by Transmeta. IIRC, *the* major power drain is at LCD and hard drive. If those bogger are attacked, I wouldn't have been surprised that the battery life would be prolonged. But, let's recall that before Crusoe came, P3 processor only consumes about 2W. How many portions was that to the total laptop consumption? Now, Crusoe reduce that into a mere 1W -- and *that* was claimed as *the* dramatic power saver. I smelled rat.
I don't want to attack your "belief" as Crusoe adherents, but please understand the underlying problem before you answer.
--
Error 500: Internal sig error
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.
A deep unwavering belief is a sure sign you're missing something...
That thread is from May. In the meanwhile, it seems that almost all the new KDE tree is compilable with the intel compiler (at least based on the cvs logs, I didn't check it myself).
Now, for the expected performance increases. If I am correct, the intel compiler is the old KAI C++ compiler, which was highly regarded in number crunching circles as the best optimizing, more standard compliant compiler around.
Still, the spectacular increases occur only in very specific cases which are amenable to optimization. Number crunching (big math computations) are the best example, and this applies probably to mp3 encoding, divx playback and compression, image processing and other stuff like this, too. But for your average, highly heterogenous code which goes into your typical desktop apps, the increase is significatly smaller.
Lotzi
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
I find it hard to believe an optimizing emulator would run faster than native instructions (and I'm well aware of HP's optimizing run-time work).
Java's HotSpot compiler beats out traditional C/C++ code on a number of benchmarks.
ZFS: because love is never having to say fsck
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.