Still, the point I want to make is, you need to determine your audience, but be cautious in your investigation methods and don't forget to do the general market watch.
Your point is taken. However we're a small efficient * company and as I've stated previously, porting to Linux would not represent a massive (additional) development outlay for us.
* On balance; perhaps it's not a good idea. When I yell at our developers for reading slashdot, they'll claim to be working:)
Simply put, we don't know yet. There is no reason why VectorC would have to be the same price as the Win32 versions (there's a Professional Edition and a much cheaper Standard Edition). I'm guessing it wouldn't be popular just to bundled a Linux version with the Win32 version...
Maybe it's just me, but if your specialty is high performance vector operations targeted specifically at graphic-intensive programs applications like games where vector operations are CPU-bound, then why would you not just code a superfast set of assembly routines for vector operations that are tuned for the various processors, and provide them as a C library that the world can use with their compiler of choice?
I think you'll find that games and graphics application developers really don't want to be told exactly how to code the operations at the heart of their games/apps. There's also too many of these types of operations to generalise until suddenly you find you're implementing an engine in a library. And some people do that of course...
What you describe is pretty close to the concept of intrinsics. You generally find things like matrix manipulation as intrinsics functions. You place those in your C and the compiler automatically in-lines some pre-written optimized code. The trouble is, it's limited, not very flexible and of course it's CPU specific.
We'd love to! Alti-Vec is seriously cool if you're in the business of getting excited about CPU vector units like we are.
We went to Apple and said "Guys, we'd really love to do a Mac version and you could really do with having a compiler that uses the cool bits in your CPUs. Wanna sling us a bit of cash?" The phones been strangely quiet. Oh well.
On the bright side, there's a games platform with a PPC processor. It doesn't have Alti-Vec (boo!) but it does have a basic vector unit. You can bet we're working on that pretty hard. So that'll have ramifications of moving to other platforms later on down the line when we have PPC code-generation going sweet.
Linux game developer unable to make money here and you are trying to sell compiler directed at game developers ?
It simply doesn't make any sense.
We're aware the Linux games market is non existant. Fortunately VectorC is still useful for multimedia processing (which is basically what games are!) and there's a bit of that going on under Linux, right?
Scientific applications usually need more than single-precision arithmetic... so it may be more useful on the Pentium4 for scientific applications:)
You're obviously quite right. We get a surprising amount of interest from the scientific/academic community. High tech compilers that vectorize are nothing new in this area, but generally they're Fortran compilers for mainframes etc.
I'm guessing that with the power of desktops these days and the prevalence of C/C++, micro based scientific computing is looking more attractive.
It's quite spooky to see all these high energy research labs (Eek!) in our web logs. I wonder how many of these people understand the precision issues with most vector units out there.
Perhaps the Pentium 4 will become a standard choice for scientific computing because of the double precision cable vector unit. Just as well we put a lot of effort into SSE2.
Yes, that's the idea. We accept broad compatibility is a requirement and we've done a lot of work on that sort of thing on several platforms.
A free version (free as a beer)
That's a possibility. However VectorC is something other than a general compiler, although that's ultimately the goal. My current thinking is that if you want a free general purpose compiler than there's nothing wrong with GCC. If you have a need to write high performance code, you're probably doing this because you have a serious application in mind. You're faced with hand coding assembly or... VectorC. If you don't enjoy hand-coding assembly then VectorC starts to look attractive (we hope).
Then again, plenty of programmers enjoy that, I don't quote understand them myself:)
3. Competition... do you really want to get in?
Of course, otherwise Codeplay never would have started! To be honest, our focus is still games and in that area (specifically vectorization) compiler technology hasn't really moved forward.
I briefly read over their specs on their website and it I find it quite humorous that all of the benchmark code is asm. So essentially, they have an assembler.
Err, I don't know how you got that impression. The benchmark code is in C. Just click on the tests on the left. If you click on the RIGHT you see the output assembly from the major compilers on Win32 platform.
And you're right, we haven't benchmarked against GCC because it's not a contender on Win32. Also your point on seeing benchmarks on large 'production quality program' is well taken and we're working on that. We've got some real-world games/engines compiling nicely but since we can't release the source for those it's of dubious use wouldn't you say?
Quake 1 is what a lot of people like to test us with, compiling it themselves.
No, it isn't. It's a high performance auto-vectorizing compiler. The only other auto-vectorizing compiler is Intel's and that's a) So limited in what it will vectorize so as to be of little practical use and b) only vectorizes for SSE oddly enough.
I have an idea, how about we just use GCC with the -mcpu=i686 and -march=i686 flags instead of paying for this.
All due respect but VectorC blows away highly optimizing compilers like MSVC and Intel C/C++ when it comes to vectorization, let alone GCC.
Now we're not saying you have to pay for this, it's most likely you do not have a need for what VectorC is good at. It most certainly is not aimed at general compiling ala GCC.
It's an alternative to hand-coding assembly language when high performance is necessary. Admittedly my story could have been a bit more descriptive here but I wanted to keep it short.
Shame on/. story posters, this "story" is just a shameless plug.
Or maybe it was actually gauging the waters exactly as I said!. We have no products under Linux so 'plugging' here under this topic would be fairly pointed.
So cynical some people!
Mat 'Lurks' Bettinson, Codeplay Ltd.
Slashdot Mirror
Mat 'Lurks' Bettinson, Codeplay Ltd.
I can't comment on what you're talking about without knowing what you're doing. Suffice to say those results aren't indicative of our performance.
So yes, you do have to say more or at least I'd like you to. Drop a mail to support@codeplay.com and we'll work out what's going on.
BTW we released 1.2 last week which is a substantial upgrade from 1.1. In particular Pentium 4 support in 1.1 was very limited.
Mat 'Lurks' Bettinson, Codeplay Ltd.
Your point is taken. However we're a small efficient * company and as I've stated previously, porting to Linux would not represent a massive (additional) development outlay for us.
* On balance; perhaps it's not a good idea. When I yell at our developers for reading slashdot, they'll claim to be working :)
Mat 'Lurks' Bettinson, Codeplay Ltd.
Appart from anything else, the approach of GCC and VectorC could not be more different.
Mat 'Lurks' Bettinson, Codeplay Ltd.
Simply put, we don't know yet. There is no reason why VectorC would have to be the same price as the Win32 versions (there's a Professional Edition and a much cheaper Standard Edition). I'm guessing it wouldn't be popular just to bundled a Linux version with the Win32 version...
Mat 'Lurks' Bettinson, Codeplay Ltd.
I think you'll find that games and graphics application developers really don't want to be told exactly how to code the operations at the heart of their games/apps. There's also too many of these types of operations to generalise until suddenly you find you're implementing an engine in a library. And some people do that of course...
What you describe is pretty close to the concept of intrinsics. You generally find things like matrix manipulation as intrinsics functions. You place those in your C and the compiler automatically in-lines some pre-written optimized code. The trouble is, it's limited, not very flexible and of course it's CPU specific.
Mat 'Lurks' Bettinson, Codeplay Ltd.
We'd love to! Alti-Vec is seriously cool if you're in the business of getting excited about CPU vector units like we are.
We went to Apple and said "Guys, we'd really love to do a Mac version and you could really do with having a compiler that uses the cool bits in your CPUs. Wanna sling us a bit of cash?" The phones been strangely quiet. Oh well.
On the bright side, there's a games platform with a PPC processor. It doesn't have Alti-Vec (boo!) but it does have a basic vector unit. You can bet we're working on that pretty hard. So that'll have ramifications of moving to other platforms later on down the line when we have PPC code-generation going sweet.
Mat 'Lurks' Bettinson, Codeplay Ltd.
We're aware the Linux games market is non existant. Fortunately VectorC is still useful for multimedia processing (which is basically what games are!) and there's a bit of that going on under Linux, right?
Mat 'Lurks' Bettinson, Codeplay Ltd.
You're obviously quite right. We get a surprising amount of interest from the scientific/academic community. High tech compilers that vectorize are nothing new in this area, but generally they're Fortran compilers for mainframes etc.
I'm guessing that with the power of desktops these days and the prevalence of C/C++, micro based scientific computing is looking more attractive.
It's quite spooky to see all these high energy research labs (Eek!) in our web logs. I wonder how many of these people understand the precision issues with most vector units out there.
Perhaps the Pentium 4 will become a standard choice for scientific computing because of the double precision cable vector unit. Just as well we put a lot of effort into SSE2.
Mat 'Lurks' Bettinson, Codeplay Ltd.
Yes, that's the idea. We accept broad compatibility is a requirement and we've done a lot of work on that sort of thing on several platforms.
That's a possibility. However VectorC is something other than a general compiler, although that's ultimately the goal. My current thinking is that if you want a free general purpose compiler than there's nothing wrong with GCC. If you have a need to write high performance code, you're probably doing this because you have a serious application in mind. You're faced with hand coding assembly or... VectorC. If you don't enjoy hand-coding assembly then VectorC starts to look attractive (we hope).
Then again, plenty of programmers enjoy that, I don't quote understand them myself :)
Of course, otherwise Codeplay never would have started! To be honest, our focus is still games and in that area (specifically vectorization) compiler technology hasn't really moved forward.
Mat 'Lurks' Bettinson, Codeplay Ltd.
Err, I don't know how you got that impression. The benchmark code is in C. Just click on the tests on the left. If you click on the RIGHT you see the output assembly from the major compilers on Win32 platform.
And you're right, we haven't benchmarked against GCC because it's not a contender on Win32. Also your point on seeing benchmarks on large 'production quality program' is well taken and we're working on that. We've got some real-world games/engines compiling nicely but since we can't release the source for those it's of dubious use wouldn't you say?
Quake 1 is what a lot of people like to test us with, compiling it themselves.
Mat 'Lurks' Bettinson, Codeplay Ltd.
If there was a torrent of 'How dare you!' type posts then that'd be telling us not to bother. :)
Mat 'Lurks' Bettinson, Codeplay Ltd.
Running on Linux to compile FOR Linux x86.