GPGPUs

[luminousone]

> The core (!) point here is that processor chips are rapidly 
> becoming a
> collection of heterogeneous cores. Any programming language 
> that assumes
> a single CPU or a collection of homogeneous CPUs has built-in
> obsolescence.
>
> So the question I am interested in is whether D is the language 
> that can
> allow me to express in a single codebase a program in which 
> parts will
> be executed on one or more GPGPUs and parts on multiple CPUs. D 
> has
> support for the latter, std.parallelism and std.concurrency.
>
> I guess my question is whether people are interested in 
> std.gpgpu (or
> some more sane name).

CUDA, works as a preprocessor pass that generates c files from 
.cu extension files.

In effect, to create a sensible environment for microthreaded 
programming, they extend the language.

a basic CUDA function looking something like...

__global__ void add( float * a, float * b, float * c) {
    int i = threadIdx.x;
    c[i] = a[i] + b[i];
}

add<<< 1, 10 >>>( ptrA, ptrB, ptrC );

Their is the buildin variables to handle the index location 
threadIdx.x in the above example, this is something generated by 
the thread scheduler in the video card/apu device.

Generally calls to this setup has a very high latency, so using 
this for a small handful of items as in the above example makes 
no sense. In the above example that would end up using a single 
execution cluster, and leave you prey to the latency of the pcie 
bus, execution time, and latency costs of the video memory.

it doesn't get effective until you are working with large data 
sets, that can take advantage of a massive number of threads 
where the latency problems would be secondary to the sheer 
calculations done.

as far as D goes, we really only have one build in microthreading 
capable language construct, foreach.

However I don't think a library extension similar to 
std.parallelism would work gpu based microthreading.

foreach would need to have something to tell the compiler to 
generate gpu bytecode for the code block it uses, and would need 
instructions on when to use said code block based on dataset size.

while it is completely possible to have very little change with 
function just add new property @microthreaded and the build in 
variables for the index position/s, the calling syntax would need 
changes to support a work range or multidimensional range of some 
sort.

perhaps looking something like....

add$(1 .. 10)(ptrA,ptrB,ptrC);

a templated function looking similar

add!(float)$(1 .. 10)(ptrA,ptrB,ptrC);