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?"
Running on Linux to compile FOR Linux x86.
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).
;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, 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
Anyway, its a good compiler, if you need it. Just think about whether you do or not...
Game dev and music blog
Scientific applications usually need more than single-precision arithmetic, while the vector instructions available in 3D-Now! and SSE are only single-precision. SSE2 has double-precision as well, so it may be more useful on the Pentium4 for scientific applications
Games generally aren't so picky about the precision, and so more can be done to optimize without breaking the code.
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?
Hetz (Heunique)
I guess you misunderstood the way vectorc works. You can just compile the code usual way, or as a preferred alternative you can start interactive optimizer which allows you to see what asm code C code produces with various optimization options while editing C code. The interactive optimizer (at least my demo version) do not allow you to edit asm, it just helps you to see where suboptimal code is produced and why, so you can change either C code or compiler options to produce faster code. gcc is very slow on intel/amd. It is pointless to even compare (nevertheless, I did. gcc 2.95 is sloooow. gcc 3.x is even slower on my matrix multiplication function.) The real competition is between intel compiler and vectorc.
Gentlemen, you can't fight in here, this is the War Room!
you are right on double precision thing, but that is not all vectorc does. scheulding is much better than alternatives (remider: I haven't yet tested intel's compiler) and software prefetching, cpu dependent cache management etc. are also important factors. I experienced huge speedups with double precision x87 code on my benchmarks too. Actually if you are not using the same values over and over such that you can keep them in registers for a long time, 3dnow! is only a bit faster than x87 code on athlon. Cache managment and instruction scheulding is all that counts under moderate data loads.
Gentlemen, you can't fight in here, this is the War Room!
That's not really our philosophy. We want to provide a high performance compiler which you plug into the development environment of your choice. We're not an IDE developer, we a compiler developer.
Mat 'Lurks' Bettinson, Codeplay Ltd.
It's still pretty early days for us, it could well be something broken! Showing your code to our lads could either a) point out something you need to do to make things faster or b) point out something we need to fix/improve. The only thing that makes me think something is wrong with your values is that we just don't see that sort of lackluster performance in our tests. If we did, we'd fix the compiler! Mat 'Lurks' Bettinson, Codeplay Ltd.
...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?
There is nothing wrong with gcc basic design.
I could turn your argument in the other side, and explain that there is something wrtong with vectorC, because its internal structure make it difficult to port to a new platform.
The goal of gcc was to provide a free(dom) C compiler for every architecture, and its basic design seems correct for that. Now gcc is expanding on other language as well, like ObjC, java, fortran or java (hence the name change: now gcc means Gnu Compiler Collection)
Good code is not even a primary goal of gcc. Freedom, Correctness and portability are.
Cheers,
--fred