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.
~wally
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.
Sometimes it's best to just let stupid people be stupid.
Uhh, just because you can't recompile the kernel doesn't mean you can't recompile your other programs. You can keep your gcc-compiled (slower) kernel and then recompile your other programs with the Intel compiler (faster). Just because only part of your system speeds up doesn't mean it's useless.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
What I think is being pointed out is that on-cpu time will be shorter. This has some nice pluses to it, even if the kernel doesn't get the nice optimizations of it all. I would love a faster apache server, even if my kernel is (reletivly speaking) more pokey. :-)
Sam
...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.
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.
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.
You're one of those people who just doesn't get the fact that the Crusoe gets speed gains by *not* using its native instruction set.
pooptruck
how is intel the 'archenemy' of us... just because Linus works at Transmeta? What chip are you running your OS on? I bet its an Intel chip, or an intel-clone (AMD)
/me is wintel-free, yay Mac
Just a thought: Might this compiler perhaps be different in a way that improves the situation regarding the C++ library relocation issues that bothers KDE?
- El riesgo siempre vive - Private J. Vasquez
Why don't they use ANSI C for the kernel?
Intel's compiler can compile both C and C++.
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.
Uh, are you trolling? The raytracer is a program that runs on a computer. Thus, the raytracing source *is* computer source code. They're not similar, but the same.
There are no trails. There are no trees out here.
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).
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?
Real men write machine code directly, in hexes. Who needs the pinko sissy commy fag Assembly Language?
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.
Crusoe does cool things because it runtime optimizes the code that it is morphing. If you were to run crusoe code natively, you'd no longer get the optimization benefits, and all you'd be left with is an even slower low-power chip.
Theoretically, you could write a Crusoe-to-Crusoe code morphing module, but that wouldn't buy you anything more than the X86-to-Crusoe morpher.
pooptruck
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
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
You're benchmarking an intel compiler which will generate optimized intel code, but telling gcc to use "-m386" ?
You have an 80386 machine here secretly? Why not use the optimized flags like "-mcpu=i686 -march=i686" and give a fair comparison?
Am I the only one to see this? C'mon people, wake up, read the manual.
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?
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.
According to the ansi standard all c++ compilers must compile c code.
http://saveie6.com/
As I type this, I'm downloading Intel's Linux Fortran compiler. While this is slightly off-topic, it will be interesting to see if this free (non-supported version) will compile some code I have that previously relied on Compaq/Digital Fortran's fort26.dll on the Win32 platform (not my code, honest :).
:)
If I can get it to compile on Linux, then I can do a whole host of things my employer previously thought impossible.
Praying for the end of your wide-awake nightmare.
Its really not that bad. Its free for non-commercial use, and $500 isn't much for a development tool in a pro shop. Perforce licenses, for example, cost $600 per developer. There is this guy who writes programming tips-type articles (look around on /., sorry I don't remember the name). He makes the very good point that good developer tools are a drop in the bucket for the return they give in productivity.
A deep unwavering belief is a sure sign you're missing something...
Umm, you don't even have to do that. You can download it from Intel.
A deep unwavering belief is a sure sign you're missing something...
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..
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
gcc has gotten so far behind the specialized instruction set curve that you're better off writing hardware descriptions for an FPGA using iverilog than spending $500 to write useful software for a modern instruction set.
Actually, having read the license, I found the following loophole:
. . . if you buy the compiler, you are allowed to distribute code that you compile with icc ;) Find someone who has paid for icc, and ask them nicely if they would compile something for you. No, it's not open-source, but you can distribute source code along with an optimized binary if you're so inclined.
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
Nah. Real men can write assembly in *any* language. :)
wow, the compiler fixes bloated design issues too?
Seriously though, any speed up with any program helps. Given that Mozilla's UI is in XUL and that's were a lot of the sluggish behavior seems to be, has anyone come up with a jit compiler for xul?
the good ground has been paved over by suicidal maniacs
Another one who learned the pronunciation of "Crusoe" from the Gilligan's Island theme song!
I realize you've got a smiley there, but I've got to say: Duh! Who would use/buy a compiler that didn't allow you to distribute your binaries? That would be like using a word processor where you didn't own the work you wrote.
Though it wouldn't surprise me if sooner or later the Microsoft C++ or Word license would claim that any work produced with the tools is property of MS.
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.
And Real Men rewrite the entire kernel when a new processor comes along.
A C++ compiler won't give anything approaching the same results as a C compiler.
Example:
sizeof('a')
is 4 on Intel/C, and 1 on Intel/C++. More generally, it's the same as sizeof(int) in C and it's sizeof(char) in C++.
Example:
char *a = malloc (10);
Should issue a diagnostic in any conforming C++ compiler, requiring a cast of the malloc() return value to (char *) to suppress the warning (which results in a lot of dangerous casts in C++ code that things like lclint will be confused by).
There are tons of such things, which make it nearly impossible to compile any reasonable large C project with a C++ compiler and get correct behavior. And that's assuming that you don't have variables named "new" or your own "bool" type or anything obvious like that.
Sumner
rage, rage against the dying of the light
I think the most dramatic demonstration of this was a test done by Tom's Hardware last year. He ran a test on a bunch of different processors doing MPEG-4 encoding using FlaskMPEG. The Pentium 4 performed abysmal, comming in behind a Pentium III 1ghz. Intel decided then to download the source code to FlaskMPEG and recompile it with their compiler. This moved the P4 up to the top of the heap, but also increased all the other scores. The P4 1.5 got the biggest boots, from 3.83fps to 14.03fps the PIII 1ghz also got a lesser boost from 4.39fps to 8.03fps. However the Intel compiler helped out the Athlon 1.2ghz too, boosting it from 6.43fps to 11.14fps. So it even gave their competitors' hardware a 60% speed boost.
Intel's compiler division isn't interested in trying to screw their competitiors and make Intel's chips look the best, they are interested in producing the most optimized x86 code possible. Now of course the Intel compiler supports all the special Intel extensions (MMX, SSE, SSE2) and I don't believe it supportins things like 3dnow, but that dones't mean they are going to screw up their code on purpose to make it run poorly on other chips.
You can also look at some rudimentary benchmarks comparing gcc 3.0.1 and Intel C++ 5.0.
All about me
You can download it from Intel
Reminder: This compiler includes no support and cannot be used to produce products for resale or commercial use.
And thus produces binaries incompatible with the GNU General Public License, which allows no such restrictions on distributed binaries.
Will I retire or break 10K?
Transmeta is NOT RISC, it is VLIW with a x86 to VLIW optimizing translator.
VLIW means "very long instruction word," and EPIC means "explicit parallel instruction computing," both of which in practice mean "architectures that combine several fixed-length instructions into one word." RISC means "reduced instruction set computing," which in practice means "architectures with fixed-length instructions." All important VLIW/EPIC instruction sets have fixed-length instructions (32-bit in a 256-bit word for TMS320C6K, 32-bit in a 128-bit word for Crusoe, or 41-bit in a 128-bit word for IA64), but MIPS, PPC, and Sparc disprove the converse; therefore, VLIW/EPIC RISC.
Will I retire or break 10K?
Only LONELY geeks program in Hex or assembly!
Real Men code in C++, Java, Fortran, or Objective C, get the necessary job done, then go home to f*ck the prom queen!
There is a sub-project for Mozilla called Rhino that implements the JavaScript interpreter in Java. It apparenlty can or did translate JavaScript into Java bytecode that could be processed by the JVM's jit. According to the history page, it doesn't sound like it worked all that great (leaked memory and the JavaScript->Java translation was slow).
the good ground has been paved over by suicidal maniacs
ICC doesn't even attempt SSE optimizations at the optimization level tested (-xMi; that's PPRO and MMX instructions; you need to -xMiKW to get SSE and SSE2 as well). The big wins that gcc could get would come from rewriting the scheduler and register allocator. The difference for gcc probably comes from extra loads and stores, and possibly more code in loop bodies. Function inlining may also play a part, as gcc doesn't do that very well.
You may also be right that gcc doesn't play with the x87 stack very well, but that is likely a minor difference in comparison.
Even Slashdot wants to hide some things
I tried Intel's C++ compiler on my own floating point heavy plasma simulation program. I tried some very high optimization flags, and that produced a binary which crashed.
Using -O1 produced a binary roughly 1/2 as fast as a -O3 g++-compiled binary.
Perhaps this compiler is a win on C code, but on C++ it sure looks like a dog to me.
Since when does the GPL not allow restrictions on distributing binaries? It only requires the ability to get the source for free.
A deep unwavering belief is a sure sign you're missing something...