Slashdot Mirror
An Open Source Compiler From CUDA To X86-Multicore
Gregory Diamos writes "An open source project, Ocelot, has recently released a just-in-time compiler for CUDA, allowing the same programs to be run on NVIDIA GPUs or x86 CPUs and providing an alternative to OpenCL. A description of the compiler was recently posted on the NVIDIA forums. The compiler works by translating GPU instructions to LLVM and then generating native code for any LLVM target. It has been validated against over 100 CUDA applications. All of the code is available under the New BSD license."
This isn't an alternative to CUDA; it lets CUDA code run on x86, but still doesn't do anything for AMD graphics cards. In other words, your choices as a developer are to use OpenCL and have your code run everywhere (AMD, nVidia, x86 slowly), or use CUDA and have your code run on nVidia or x86 slowly.
What possible reason could you have to want to be locked into one GPU vendor?
I wonder how the performance of the open source solution is compared to the proprietary compiler by NVidia. If it's good enough, they might be scared.
To do list for Windows
Why would you go from CUDA(Fast Floating-points) to x86(slower Floating-points)?
Is there support yet for double-precision floating points yet on Nvidia cards?
This makes as much sense as a Wookiee on the planet Endor.
Unless the Point is portability but, then why write it in Cuda to begin with?
Seems to be just a front-end for LLVM. And if it is just a front-end for LLVM, then why doesn't it support ATI graphics cards? That would actually make it useful; there is no need for a second CUDA compiler for NVidia cards.
And if it is just a front-end for LLVM, then why doesn't it support ATI graphics cards?
That depends on whether LLVM has a back-end for ATI graphics cards. Is the Stream Computing SDK based on LLVM or something else?
Ocelot!
NVidia isn't real happy about this. No Christmas cards for those guys! In fact the developers should expect some insipid, obvious, and unfunny cartoons will be drawn about them.
Because if you don't have the right hardware, CUDA isn't fast floats. It's a program that doesn't run at all.
Doesn't that mean "not compiled at all"
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
A bit off topic, but since I'm seeing posts about OpenCL and portability...
OpenCL will indeed get you portability between processors, however OpenCL does not make any guarantees about how well that portable code will run. In the end, to get optimum performance you still have to code to the particular architecture on which that your code is going to run. For example, performance on Nvidia chips is extremely sensitive to memory access patterns. You could write OpenCL code that runs very well on Nvidia chips, but runs poorly on a different architecture.
Not saying that portability isn't a good thing, but a lot of people seem to be thinking that OpenCL will solve all your portability problems. It won't. It only will let code run on multiple architectures. You'll still have to more or less hand optimize to the architecture.
In the course of every project, it will become necessary to shoot the scientists and begin production.
Had Larrabee turned into a product this xmas, I think alot of people would have been interested in CUDA to x86.
I'm sure the people still working on it will be interested in it.
Next step CUDA to ATI...
"What possible reason could you have to want to be locked into one GPU vendor?"
Perhaps because you are sick and tired of GPUs that don't die an early death, and love sitting on the phone and being told that it isn't covered by warranty by HP, Dell, Apple, Sony, and the rest.
-Charlie
An (Open Source) Compiler From X86-Multicore To CUDA.... This way, the ION3 could completely miss the Atom part of the equation, and we would get one more player in the x86 field.
So there seem to be several questions as to why people would want to use CUDA when an open standard exists for the same thing (OpenCL).
Well, honestly, the reason why I wrote this was because when I started, OpenCL did not exist.
I have heard the following reasons why some people prefer CUDA over OpenCL:
Additionally I would like to see a programming model like CUDA or OpenCL replace the most widespread models in industry (threads, openmp, mpi, etc...). CUDA and OpenCL are each examples of Bulk Synchronous Parallel models, which explicitly are designed with the idea that communication latency and core count will increase over time. Although I think that it is a long shot, I would like to see more applications written in these languages so there is a migration path for developers who do not want to write specialized applications for GPUs, but can instead write an application for a CPU that can take advantage of future CPUs with multiple cores, or GPUs with a large degree of fine-grained parallelism.
Most of the codebase for Ocelot could be re-used for OpenCL. The intermediate representation for each language is very similar, with the main differences being in the runtime.
Please try to tear down these arguments, it really does help.
Q: How do you titilate an ocelot?
A: Oscillate it's tits a lot.
I thank you.
The more advanced the technology, the more open it is to primitive attack