Slashdot Mirror

There also is/was:

• KAI C++
• Compaq's Alpha compiler
• SGI pro64

KAI C++ is basically dead (Intel bought them a couple years back, which sucks, as KAI was about the best C++ compiler I have seen), and I'm not totally sure about Compaq's Alpha compiler, but it looks like the SGI Pro64 compiler is still alive (and GPL'ed now... interesting).

Some stats? Just by knowing how much more well-defined C++'s type-system is compared to C is enough to get an intuitive sense that there will be cases where C++ will out-perform it. As for a specific example, type-based alias analysis is one that seems to have been getting attention lately. C++'s templates, are probably the most remarkable example, as they can permit optimizations beyond the ability of current Fortran compilers.

Both of them are so fast already though that comparing them for the most part isn't all that interesting. Awhile back, Alexander Stepanov created the Abstraction Penalty benchmark to test the effect of using abstraction features in C++ like the STL. Over the past several years I've noticed that the penalty is usually close to nothing, if not sometimes less than -- indicating a speedup.

They didn't produce the compiler - Kuck and Associates did. Intel bought them out. The guy who invented it has been around for a while - here is a short bio on him.

We use Kai (or KCC) at work, and it is truely a remarkable product. It's a two-stage compiler - it generates C code native to the platform your working on, then calls the compiler/linker for that platform to compile it. The idea here is that the native compilers for any given platform will be able to optimize for that platform. So Kai just optimizes what it can and dumps it out into C code, then calls the native compiler/linker with optimizations on to recompile that code into the executable. The Kai C++ compiler was ported to Windows, Solaris, Linux, IRIX, etc., so there was the added benefit that any code written with Kai in mind would compile easily across other machines.

Kai and GCC are very similar in concept, except that Kai was a bit of a "higher end" compiler. Think of GCC being the Toyota of compilers, and KCC being the Lexus of compilers. You may pay the extra bucks just for the optimization/cross-platform abilities that Kai has - but most normal folk don't need it.

Unfortunately, Kai got purchased by Intel, and (from what I see on their site) they seem to be dropping the other platforms to support only intel. Really, the Intel compiler is really the Kai compiler, but only for Intel. In fact, Kai (Kuck and Associates Inc.), is now part of Intel. Personally, I think this sucks, since Kai really is a superior product compared to any other C++ compiler out there, if you will to pay the extra $$$...

GCC can definitely be considered the success story of the Free Software movement.

Agreed.

In terms of C++ standards compliance GCC is believed to be the first compiler to achieve full ISO compliance. No other compiler (commercial or otherwise) can make the same claim.

As others have pointed out, it's not. It's good, though. However, the following compilers are also pretty good, comparable to GCC 3.0: KAI C++: runs on everything from Linux/x86 to Crays (also has a kick-ass optimizer); MIPSPro C++ (ok it's actually a bit less good than GCC 3.0, but I'm not sure I'm comparing the most recent version here); Compaq's C++ compiler: very good. I was impressed by that one.

Sun's C++ compiler is the worst Unix-vendor C++ compiler I've used (haven't tried IBM's or HP's, though). And BTW, VC++ runs/ran on Alpha, MIPS, and PowerPC. I have a CD of it. :)

Right now the only real compiler on Linux is GNU C

Actually that isn't true. There are already a couple of (albiet lesser known) commercial compilers for Linux:

KAI C++ -- Commercial C++ compiler for Linux.
Portland Group -- Commercial C, C++ and Fortran compilers for Linux.

Oh, to reply to my own message, here are some interesting and worthwhile links related to GCC performance:

• NullStone compiler optimization benchmarks. On this page, they give some comparisons between GCC and some other compilers.
• The Stepanov Benchmark page at KAI. The Stepanov Benchmark measures C++ abstraction penalty. GCC sucks wind on this one (as do most C++ compilers), whereas Apples MrC compiler slices through the abstraction and gets a "perfect score" (eg. no penalty).
• The GCC site contains many interesting tidbits, some of which I mentioned above. For instance, news on the Sparc backend details some of the issues I described above. Note, although that rewrite occurred in late 1998, I still see the older backend's behavior in gcc 2.8.1, which is what we have at work.
• Slashdot's story on the Compaq Alpha compiler. Some good data down in the comments.

Given, a lot of work has been done on gcc, but Borland's compiler is faster, produces smaller code, and produces faster code. (I have seen benchmarks in windows that prove this, but cannot remember where they are right now.)

With Borland's new compiler, gcc will have some more competition, and I *hope* that means more people working on it, or a new wave of development going into it.

I love Borland's IDEs, and if this one is like Borland 5 I'll probably buy it just for that (I'm currently using VMware/NT4/Borland 5 for my C++ editing, then compiling with gcc on Linux). I also used VCL on C++Builder3 and it was _much_ nicer to use than MFC (IMHO). But Borlands C++ compiler is a bit buggy. Good overall, but there are a few problems. Hopefully those will be fixed in the new version, however.

BTW, there are other compilers available. KAI C++ is a very nice compiler (no IDE or anything, just command line), runs on Linux, NT, HP-UX, Solaris, Tru64, AIX, Cray Unicos, and Hitachi machines. They also make Fortran compilers, IIRC. The Porland Group also makes F77, F90, C, and C++ compilers for Win32, Linux/x86 and Solaris/x86. I'm a bit suspicious of their ISO C++ compliance (they say they're compliant with cfront 2 and 3, which are ancient), but it's hard to say. Both of these have limited-time trials available (I've tried KCC and it's great, Portland's looks interesting anyway (automatic threading for up to 4 CPUs, automatic SIMD use on P-III, etc))

They have ported their C, C++, Fortran compilers; math libraries; debuggers; spike optimizing tool and other stuff too...

Comments also seem to indicate that they'd like to, if they could.


I'd like them to do so, too. Not only do they have good Alpha optimizations, but apperantly a lot of stuff that can be applied to any CPU. That would either make nice additions to gcc, or maybe a completely new compiler (based on DECs code, with enhancements taken from gcc, rather than the reverse).

Now that Intel has bought Kuck & Associates (makers of very fast optimizing compliers for C, C++, and Fortran), it would be great to see them open source at least parts of the technology. The standard library they use is proprietary to another company, though I suppose it could be replaced with libstdc++ (for instance, KAI could spend time completing and optimizing that code instead ot the propritetary ones). The basis behind KCC is a bit more anemable to creating front ends for other languages too, I think.

What a great article! There's a lot to get through there, so I thought I'd add a bit of extra info about one bit I know well.

Tim mentions how much more clear it is to use direct assignment (A=B+C) for all types (including lists) than having to worry about the details of the specific classes. This issue is part of the study of generic programming. This is generally quite easy to do with functional languages (e.g. have a look at some Mathematica programs to see what I mean).

A lot of effort is going into making this available in C++, with a particularly success being achieved by the STL. The STL gets over the problem of speed through using templates, which (as Tim mentions) are dealt with at compile time rather than run time. Although Tim apparently has no time for templates, they certainly achieve good results in the STL.

Those of you with their thinking hats on will be wondering "but what happens if I write A=B+C+D?". The STL would create two loops and two memory copies, since it thinks of it as ((B+C)+D). Some very interesting work to avoid this problem is being implemented in class libraries such as POOMA and Blitz++ which implement the fiendishly clever concept of expression templates to actually create and traverse a parse tree of the expression at compile time. Of course, this can lead to very long compilation times. An amazing side effect of this approach is that if you never actually use a value in A (having assigned B+C to it), then it will never get evaluated (e.g. the classes use 'lazy evaluation').

If you're interested in trying out some of these ideas in a strongly typed language, it's worth looking at C++. You'll need a good compiler though--if you're using GCC make sure it's the latest version, or for better results still try KAI C++. If you're a complete newcomer try out a functional language--I particularly recommend Mathematica, although you can use the functional concepts in Python (e.g. Map()) and Perl to make a start.

I have to admit that I am biased (in large part due to my employer). I would not consider a dual PII generally a good multiprocessor for numerically intensive codes. This has nothing to do with Intel or Linux, or g77/pgf77/absoft, etc.

What I have found on my codes is that small (actually tiny) problems run well on pentia. But reasonable research sized problems cause it to huff and puff. Machines like the alpha or the R10k (and R12k) kick serious butt on the larger problem sizes. What is just insanely cool is to watch your code (efficiently) use all 32 processors, and get something like a 28-30x speedup.

But, as I said, I am biased.

Back to fortran. Jeff Templon has an excellent page on Linux and Fortran. Better is the big fortran link page. This is really a nice resource and is a nice intro to the general Fortran Market setup by Walt Brainerd. I strongly advise visiting this site if you need to think Fortran.

Ok, now some thoughts. Craig Burley and crew have done a positively bang up job on g77. It is IMO a useful productive research tool... with a caveat or two.

First, it really is just a front end to the gcc back end, so there are many... gcc-isms... floating about.

Second, while optimization is OK, it is generally tied to the gcc optimization, which has traditionally not been very good. The egcs project has had a much better track record on getting real optimization into the compiler. Folks, if your runs can take years, 5% DOES matter. Optimization on pentia is not just -O, you need things like

-O3 -malign-double -malign-functions=2 -funroll-loops -ffast-math

among others for decent performance.

Third, and most important for me, it (nor egcs) knows nothing whatsoever about multiprocessing.

In short, g77 and egcs in general are awesome tools. But unless you work on small problems, they are not suitable. You will need some better tools, and that involves passing over some money in this case.

I like the Portland Group tools, though the KAI tools are effectively identical to what you use on big supers like Origins. Unfortunately, I do not think KAI supports Linux any longer. Maybe we can all write them a nice letter on how they could drop support for some underused platform for computation (some come to mind here :-) ) in favor of Linux. Market size and all that.

As the author of the referant article wrote, most fortran users want all the speed they can get, so you need to look at what your code spends the most time doing, and figure out if it is doing it the right and most efficient way, or if your system is correctly designed for speed, or if you are hitting one area of your system really hard, and thus causing a bottleneck. In short, if you need to design for speed, start out with a workstation design, and not a PC design. You likely will need massive memory and IO bandwidth to complement an insanely fast CPU. Putting an Alpha into a PC architecture should be considered a capital crime. It makes much more sense to put it into something like a DS20, a T3E or some other design (I can fantasize about an Alpha in an Octane or an Origin, that would be a complete screamer... a memory and IO bus capable of feeding the processor at its full speed... shudder).

The language and its implementation are important, but so is the fundamental system design. You need to avoid bottlenecks everywhere.

Joe