On Friday, 16 August 2013 at 23:30:12 UTC, John Colvin wrote:
> On Friday, 16 August 2013 at 22:11:41 UTC, luminousone wrote:
>> On Friday, 16 August 2013 at 20:07:32 UTC, John Colvin wrote:
>>> We have a[] = b[] * c[] - 5; etc. which could work very
>>> neatly perhaps?
>>
>> While this in fact could work, given the nature of GPGPU it
>> would
>> not be very effective.
>>
>> In a non shared memory and non cache coherent setup, the
>> entirety
>> of all 3 arrays have to be copied into GPU memory, had that
>> statement ran as gpu bytecode, and then copied back to complete
>> the operation.
>>
>> GPGPU doesn't make sense on small code blocks, both in
>> instruction count, and by how memory bound a particular
>> statement
>> would be.
>>
>> The compiler needs to either be explicitly told what can/should
>> be ran as a GPU function, or have some intelligence about what
>> to
>> or not to run as a GPU function.
>>
>> This will get better in the future, APU's using the full HSA
>> implementation will drastically reduce the "buyin"
>> latency/cycle
>> cost of using a GPGPU function, and make them more practical
>> for
>> smaller(in instruction count/memory boundess) operations.
>
> I didn't literally mean automatically inserting GPU code.
>
> I was more imagining this:
>
> void foo(T)(T[] arr)
> {
> useArray(arr);
> }
>
> auto a = someLongArray;
> auto b = someOtherLongArray;
>
> gpu
> {
> auto aGPU = toGPUMem(a);
> auto bGPU = toGPUMem(b);
>
> auto c = GPUArr(a.length);
>
> c[] = a[] * b[];
>
> auto cCPU = toCPUMem(c);
> c.foo();
>
> dot(c, iota(c.length).array().toGPUMem())
> .foo();
> }
>
> gpu T dot(T)(T[] a, T[] b)
> {
> //gpu dot product
> }
>
>
> with cpu arrays and gpu arrays identified separately in the
> type system. Automatic conversions could be possible, but of
> course that would allow carelessness.
>
> Obviously there is some cpu code mixed in with the gpu code
> there, which should be executed asynchronously if possible. You
> could also have
> onlyGPU
> {
> //only code that can all be executed on the GPU.
> }
>
>
>
> Just ideas off the top of my head. Definitely full of holes and
> I haven't really considered the detail :)
You can't mix cpu and gpu code, they must be separate.
auto a = someLongArray;
auto b = someOtherLongArray;
auto aGPU = toGPUMem(a);
auto bGPU = toGPUMem(b);
auto c = GPUArr(a.length);
gpu
{
// this block is one gpu shader program
c[] = a[] * b[];
}
auto cCPU = toCPUMem(c);
cCPU.foo();
auto cGPU = toGPUMem(cCPU);
auto dGPU = iota(c.length).array().toGPUMem();
gpu{
// this block is another wholly separate shader program
auto resultGPU = dot(cGPU, dGPU);
}
auto resultCPU = toCPUMem(resultGPU);
resultCPU.foo();
gpu T dot(T)(T[] a, T[] b)
{
//gpu dot product
}
Your example rewritten to fit the gpu.
However this still has problems of the cpu having to generate CPU
code from the contents of gpu{} code blocks, as the GPU is unable
to allocate memory, so for example ,
gpu{
auto resultGPU = dot(c, cGPU);
}
likely either won't work, or generates an array allocation in cpu
code before the gpu block is otherwise ran.
Also how does that dot product function know the correct index
range to run on?, are we assuming it knows based on the length of
a?, while the syntax,
c[] = a[] * b[];
is safe for this sort of call, a function is less safe todo this
with, with function calls the range needs to be told to the
function, and you would call this function without the gpu{}
block as the function itself is marked.
auto resultGPU = dot$(0 ..
returnLesser(cGPU.length,dGPU.length))(cGPU, dGPU);
Remember with gpu's you don't send instructions, you send whole
programs, and the whole program must finish before you can move
onto the next cpu instruction.