Is there any tutorial or code for using CUDA with D?

Trass3r wrote:
> Is there any tutorial or code for using CUDA with D?

Short answer: no.

I looked into writing CUDA with D a while back.  The problem is that the CUDA C runtime and the D runtime are 100% incompatible.  CUDA works by taking C-like code and compiling it with a special NVCC compiler, which emits code that's specifically for NVIDIA GPUs.

I found that it would be *possible* to take NVCC and write a D-frontend for it (The MathWorks did it for their MATLAB language), but that was a lot more work that I was willing to do in order to do stupid things like see how fast my graphics card can count to a million.

I hope you have better luck!  Maybe something has changed... maybe an LLVM->NVCC bridge (so you could take the LDC frontend and plug it into NVCC and there you go?  I don't know, it'd be cool, but I *highly* doubt it exists).

Chris R Miller wrote:

> Trass3r wrote:
>> Is there any tutorial or code for using CUDA with D?
> 
> Short answer: no.
> 
> I looked into writing CUDA with D a while back.  The problem is that the CUDA C runtime and the D runtime are 100% incompatible.  CUDA works by taking C-like code and compiling it with a special NVCC compiler, which emits code that's specifically for NVIDIA GPUs.
> 
> I found that it would be *possible* to take NVCC and write a D-frontend for it (The MathWorks did it for their MATLAB language), but that was a lot more work that I was willing to do in order to do stupid things like see how fast my graphics card can count to a million.
> 
> I hope you have better luck!  Maybe something has changed... maybe an LLVM->NVCC bridge (so you could take the LDC frontend and plug it into NVCC and there you go?  I don't know, it'd be cool, but I *highly* doubt it exists).

I think OpenCL will be easier and work om AMD to boot.

Chris R Miller schrieb:
> Trass3r wrote:
>> Is there any tutorial or code for using CUDA with D?
> 
> Short answer: no.
> 
> I looked into writing CUDA with D a while back.  The problem is that the CUDA C runtime and the D runtime are 100% incompatible.  CUDA works by taking C-like code and compiling it with a special NVCC compiler, which emits code that's specifically for NVIDIA GPUs.
> 

What a pity, just read that article and thought it might be possible to get it to work:
http://www.ddj.com/architect/211800683

But thanks for your answer. Saves me some time ;)

Lutger schrieb:
> I think OpenCL will be easier and work om AMD to boot.
> 

If they ever release it in the next few months ;)

Trass3r wrote:
> Chris R Miller schrieb:
>> Trass3r wrote:
>>> Is there any tutorial or code for using CUDA with D?
>>
>> Short answer: no.
>>
>> I looked into writing CUDA with D a while back. The problem is that
>> the CUDA C runtime and the D runtime are 100% incompatible. CUDA works
>> by taking C-like code and compiling it with a special NVCC compiler,
>> which emits code that's specifically for NVIDIA GPUs.
>>
>
> What a pity, just read that article and thought it might be possible to
> get it to work:
> http://www.ddj.com/architect/211800683
>
> But thanks for your answer. Saves me some time ;)

And I quote:

# A more flexible and powerful capability lies in the ability of many
# languages -- such as Python, Perl, and Java -- to be extended through
# modules written in C, or CUDA when programming for GPU environments.

You're still writing in C, just using D to make an (extern) function call.  So it's not exactly D on the GPU, so I don't think it counts - plus the build sequence to build the C part with GCC->NVCC pass-through (or the MSVC->NVCC pass-through) would be a absolute nightmare to work with.

I looked into OpenCL, which appears (at first glance) to be a funky way of stringing together assembler instructions using C function calls. I'm sure it's fast, but it's not the most friendly looking code to me (then again, I don't know ASM, so what do I know?)

Chris R Miller wrote:
...
> 
> I looked into OpenCL, which appears (at first glance) to be a funky way of stringing together assembler instructions using C function calls. I'm sure it's fast, but it's not the most friendly looking code to me (then again, I don't know ASM, so what do I know?)

It's at a higher level than that, basically shaders for more general purpose parallel computation BUT: the OpenCL runtime is supposed to take that code and load balance it over whatever processors it can find in your system, GPU's, multiple cores with or without SIMD instructions, whatever.

Lutger wrote:
> Chris R Miller wrote:
> ...
>> I looked into OpenCL, which appears (at first glance) to be a funky way
>> of stringing together assembler instructions using C function calls.
>> I'm sure it's fast, but it's not the most friendly looking code to me
>> (then again, I don't know ASM, so what do I know?)
>
> It's at a higher level than that, basically shaders for more general purpose
> parallel computation BUT: the OpenCL runtime is supposed to take that code
> and load balance it over whatever processors it can find in your system,
> GPU's, multiple cores with or without SIMD instructions, whatever.

Hmm, clever.

Chris R Miller schrieb:
> You're still writing in C, just using D to make an (extern) function call.  So it's not exactly D on the GPU, so I don't think it counts - plus the build sequence to build the C part with GCC->NVCC pass-through (or the MSVC->NVCC pass-through) would be a absolute nightmare to work with.
> 

Well, that's what I thought about cause real D code on the GPU seems utopian.

> I looked into OpenCL, which appears (at first glance) to be a funky way of stringing together assembler instructions using C function calls. I'm sure it's fast, but it's not the most friendly looking code to me (then again, I don't know ASM, so what do I know?)

OpenCL is really similar to CUDA, in fact nvidia will support it using CUDA.
It also uses an extended subset of C99 which will be somehow compiled. Still wondering how it will work, hopefully it won't have that same problem with the incompatible runtime :(

Lutger schrieb:
> It's at a higher level than that, basically shaders for more general purpose parallel computation BUT: the OpenCL runtime is supposed to take that code and load balance it over whatever processors it can find in your system, GPU's, multiple cores with or without SIMD instructions, whatever. 
> 

I think that's not fully correct. You specify yourself which processor the code should run on.