D and Heterogeneous Computing

[Josh Klontz]

On Saturday, 7 April 2012 at 18:47:21 UTC, Robert Jacques wrote:
> On Sat, 07 Apr 2012 11:38:15 -0500, Josh Klontz 
> <josh.klontz at gmail.com> wrote:
>
>> Greetings! As someone with a research interest in software
>> abstractions for image processing, the D programming language
>> appears to offer unsurpassed language features for constructing
>> beautiful and efficient programs. With that said, what would
>> really get me to abandon C++ is if D supported a heterogenous
>> programming model.
>>
>> My personal inclination would be something closer to OpenACC 
>> than
>> anything else I've seen available. Though only in the sense 
>> that
>> I like the idea of writing code once and being able to
>> compile/run/debug it with or without automatic
>> vectorization/kernelization. Presumably we could achieve more
>> elegant syntax with tighter integration into the language. Has
>> anyone been working on anything like this? Is this something 
>> the
>> community would be interested in seeing? What should the 
>> solution
>> look like?
>>
>> One path forward could be a patch to the compiler to generate 
>> and
>> execute OpenCL kernels for appropriately marked-up D code. 
>> While
>> I'm new the the D language, I'd be happy to work on a proof of
>> concept of this if it is something the community thinks would 
>> be
>> valuable and I could get specific feedback about the right way 
>> to
>> approach it.
>>
>
> I've been using D with CUDA via a high-level wrapper around the 
> driver API. It works very nicely, but it doesn't address the 
> language integration issues. Might I recommend looking into 
> hooking up LDC to the PTX LLVM back-end. That would seem much 
> faster than writing your own back-end.

Yes, I certainly don't want to be in the business of writing 
back-ends. Another idea that came to mind recently was 
implementing a keyword similar in spirit to "asm":

opencl {
  // Valid opencl code here
}

And have the compiler automatically handle memory copying of D 
variables referenced in the kernel code. Would be entirely 
back-end independent and perhaps pleasant to implement?