D and Heterogeneous Computing

[Josh Klontz]

> IIRC, doesn't OpenCL support jit-ing ASCII source files? Then, 
> there wouldn't be a need for any language changes.

Correct, and that's the underlying power I'm proposing to
leverage.

IMO, writing OpenCL code involves (at least) the following
nuisances:
1) The kernel code needs to be written as a text string within
the native code base.
2) Various function calls to the OpenCL library need to be made
to manage the runtime, compile kernels, connect arguments to
kernels, execute the kernels, and retrieve the results.
3) If you want to build an application both with and without
OpenCL as the backend then you have to maintain two versions of
every algorithm, one as an OpenCL string and the other in the
native language of your program.

To me there seems to be a huge opportunity to obviate the above
issues and entice new developers to D via some careful
engineering at either the compiler or the standard library level
to support heterogeneous computing. Certainly technologies like
C++ AMP are a step in the right direction, but to my knowledge
there currently doesn't exist anything with the following
desirable principles:
1) Write the algorithm once, compile for both serial execution on
the CPU or massively parallel execution on an OpenCL enabled
device.
2) FOSS
3) Runs everywhere the underlying language runs.
4) The underlying language has a robust compiler, active and
growing community, solid standard library, elegant language
features, etc...

Perhaps I was wrong to suggest that this has to be solved at the
compiler level. The EPGPU library seems to tackle some of the
problems of mixing OpenCL kernels within C++, though the syntax
is far from ideal.

Thoughts?