On 11.04.2012 0:31, Josh Klontz wrote:
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?
From the looks of it this kind of stuff should be easy with tokenzied
strings ( q{ code } )+ mixins + some "auto-magic" helpers being run for
OpenCL behind the covers. The problematic part is checking that the
fragment is using the correct subset of both languages.
Ideally API should work along the lines of this:
float[] arr1, arr2;
//init arr1 & arr2
assert(arr1.length == arr2.length);
length = arr1.length;
compute!q{
for(int i=0;i<length; i++)
arr1[i] += arr2[i];
}(arr1, arr2);
where compute works both with plain CPU and even without OpenCL (by
simply mixin stuff in) and for OpenCL with a bit of extra binding magic
inside compute template.
(compute is an eponymous template that alied to static function inside,
that in turn is generated by mixin, for concrete example - take a look
on how ctRegex template in std.regex does it)
Of course, there are some painful details when you go for deeper things
and error messages but it should be perfectly doable in normal D even
w/o say CTFE parser.
--
Dmitry Olshansky
