Slashdot Mirror
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?"
Porting this to linux seems to be a good idea, but the inherent problem is your business model. Who is your target audience? Are you targeting corporations such as lokisoft who will use your compiler to port/create games for linux?
(side note- the lokisoft page is down, i dunno if that is a fluke, if i have the wrong URL, or if they've packed up and left)
The problem is that if you target corp.'s like loki, you may not be able to sell enough units, or whatever, to justify the cost of porting. These linux gaming companies seem to fold faster than omlettes at waffle house.
If on the other hand, you just ported it and released it at random into the linux/OSS community, you would be doing the community a favor, and independant cells of programmers could attempt to port/write games for linux.
The problem with this solution is also the cost: If you release it open source for linux, you would be somewhat of a hero, or philanthropist, to the OSS community; however, you may not be able to justify the cost of porting it, if your idea is to make money by porting to linux.
I guess it depends on what time frame you think you can port it to linux in - if it would take you and your team an extra two days of programming, it may be worth it, as both a PR move and a gift to the OSS community. However, if it will take extra months of coding, just bear in mind that philanthropy doesn't pay bills.
Don't mean to be cynical, but you have to consider each decision as it relates to the almighty dollar.
It sounds as if you're doing fantastic work, though, keep it up.
sig?
I do high-performance computing, and I'd love to be able to try out Vector-C on some of our P-4 and Alpha Linux clusters, if I could. Right now, we use Intel's icc or gcc on x86 and Compaq's ccc or gcc on alpha, respectively. Pretty soon we are going to be looking at Itanium as well. Some of the time we are hand-hacking assembly just like the game programmers are, which is kind of sad; we would rather be compiling C. What Mat Bettinson said is definitely the case: "micro based scientific computing is looking more attractive."
Despite what some ppl here are saying, it's not an issue if it can't compile the kernel, or if it's not 100% gcc compatible, because most of the things the high-performance computing applications I've seen don't need to spend a whole lot of time in the kernel. However, you do have to make it work with both 2.1 and 2.2 glibc (please please please). The hacks we came up with to make icc work on our glibc-2.2 RH7 boxes are ugly and fragile.
Language issues: C++ is almost never a big deal in HPC, but C/FORTRAN support is great. Having at least partial C99 support is best because then you get float *restrict foo, et al. Also, remember that not all HPC codes are fp. Some of us write integer intensive codes and/or memory intensive codes.
It's not an issue if it's not free-beer or free-software, because research grants will probably be happy to pay reasonable amounts for it -- maybe a couple hundred bucks, say -- but you have to remember that Intel is giving icc betas away for basically nothing, so you can't charge too much. This is not a troll, just trying to be realistic here.
Disclaimer: I am not speaking for my employers. I am not a person who gets to decide how grant money is spent (yet). These are just my opinions.