Does Linux Need Another Commercial Compiler?

Lurks asks: "My company, Codeplay, is set up to develop new and innovative compiler technology for the games industry. Our C compiler, VectorC, is a cutting edge vectorizing compiler aimed at games and multimedia applications that demand high performance generally through hand-optimized assembly. I'm writing to ask the burning question on our minds, is it worth porting VectorC to Linux? In fact, we're already targeting Linux as part of the PlayStation 2 version albeit not generating x86 code of course. A Linux port would see us converge this work with our Win32 compiler and such an undertaking would certainly be popular with our Linux loving techies! One caveat worth mentioning now is that the current version of VectorC is plain C only. 2.0 with full C++ compatibility is due early next year."

"Of course, commercial realities will rear their ugly head and we must consider that Linux isn't perhaps an obvious choice for a compiler aimed at games and multimedia applications. Given the certain degree of hostility towards commercial closed-source products of this nature, perhaps the idea should be consigned to the pet-project back burner for the future rather than rolled out as a commercial product?"

Comments

Intended Audience

[MaestroSartori]

For those who don't know much about it, VectorC is a compiler for targetting fairly specific types of system. Namely those with a bit of SIMD like your P3/P4/etc ,or small-scale parallelism like the PS2 (is there an XBox-specific version to help with shaders yet? dunno).

Anyway, I can see this not going down hugely well on Linux. Apart from the commercial thing, which is a big turnoff to many of the free-as-in-beer users ;o) Why? Well, I just don't see a huge market of Linux users with the type of processors which get the advantage from that kind of compiling. Cross-compiling for PS2 yeah, we do that in my office (though not from Linux). But one of the big selling points of Linux is that it works on lower-end processors, which don't have SIMD.

Anyway, its a good compiler, if you need it. Just think about whether you do or not...

You'll need to do the thinking..

[HeUnique]

Today, there are 2 compilers that are well known - GCC which is the default and most used on Linux, and Intel's ICC which is a commercial, but there is a free non-commercial version available from Intel. So far I have heard mixed reports from people about ICC effiency in terms of code generated, speed of binaries, size of binaries etc (slashdot users who use ICC - please post your conclusions).

Now - the next big compiler that will come out (commercially) is from Borland. Early reports from various testers suggest their C/C++ compiler is kicking both ICC and GCC in the ass, but again - I belive it when I see the numbers, although Borland got a reputation of isssuing quite fast compilers..

So - if you decide to release a compiler, you'll need to think about 3 points:

1. GCC compatible - you'll need it if you want to be used by open source users OR to allow developers to move their apps which used GCC to your compiler.

2. A free version (free as a beer) - in order to be really accepted and widely used by Linux users, you'll need to issue a free version for the developers to use. Intel learned this quite since the beginning that if they want their compiler to be accepted by the Linux users - they'll need to release a free version. Borland is rumored to release a free version also with their upcoming C/C++ compiler (command line version, not the GUI)

3. Competition - well, not much to say here, but you got companies like: Borland, Intel, and the GNU GCC, along with the Portland group's compiler, code warrior (Metrowerks) - plenty of competition. do you really want to get in?

Re:You'll need to do the thinking..

[be-fan]

I've been checking ICC out for awhile (both on Linux and on Windows) and its a dream to use. Its quite fast, generates nice code (20% or so faster than GCC on most things I've tried with it, like ByteMark) and has really, really nice error messages. It isn't as complient with C++ as GCC 3.0, but its really good nonetheless, its just missing some of the eosteric parts of the standard.

Maybe, but...

[Snowfox]

Hi, I'm a game developer. I looked at your compiler at Siggraph and GDC.

...when I spoke to your sales rep at GDC and Siggraph, he indicated that C++ wasn't ready, as you said. He also didn't think your symbol information would be compatible with VTune or the other standard Windows profilers and couldn't tell me of any test suites that your compiler had passed, though he named a couple which were "close." I wouldn't use a compiler which doesn't pass basic conformance testing, and I certainly wouldn't take on a new compiler if I don't know that I can profile its output to prove that its working.

When I tried creating some simple code and looking at the disassembly on the sample machine at Siggraph, the compiler choked on some valid code (it seemed confused by the critical 'volatile' keyword), and the assembly generated was extremely naive about cache use and couldn't even hoist redundant operations out of loop operations.

So far as I can see, I'm supposed to dump my compiler for something that lets me use half a dozen instructions I can get with inline assembly or Intel's _free_ compiler, where Windows is concerned.

Shouldn't you finish your tools and make them work on one platform before you go trying to pitch them on others? Have your tools really advanced so far in the last few months that you're ready to split resources?

Re:Maybe, but...

[Lurks]

He also didn't think your symbol information would be compatible with VTune or the other standard Windows profilers

That is not correct, you can use VTune just fine. That's exactly how we see people using VectorC today. Your points on conformance testing are well taken. That is being done with the C++ version and obviously well announce results when we release that compiler.

... the compiler choked on some valid code ...

Quite possible you ran into a 1.0 bug. There's a dramatic difference with the recent 1.2 release. VectorC can now compile entire games and middleware engines and demonstrate a boost in performance in many cases. That's not something I would have said at the beginning of this year.

So far as I can see, I'm supposed to dump my compiler for something that lets me use half a dozen instructions I can get with inline assembly or Intel's _free_ compiler, where Windows is concerned.

Well clearly I can't agree with your viewpoint on what a proper vectorizing compiler is capable of doing. Now if you're prepared to go do all the inline assembly for the various SIMD implementations on x86 CPUs then indeed, you have no use for VectorC. However that's pretty rare for game developers working to deadlines in my experience.

Shouldn't you finish your tools and make them work on one platform before you go trying to pitch them on others?

VectorC works marvellously on Win32 and is already being used by game and middleware developers to good effect. However I like your tone, you think you could come over and whip me with an apple in my mouth? :)