GPGPUs

[luminousone]

On Sunday, 18 August 2013 at 05:05:48 UTC, Atash wrote:
> On Sunday, 18 August 2013 at 03:55:58 UTC, luminousone wrote:
>> You do have limited Atomics, but you don't really have any 
>> sort of complex messages, or anything like that.
>
> I said 'point 11', not 'point 10'. You also dodged points 1 and 
> 3...
>
>> Intel doesn't have a dog in this race, so their is no way to 
>> know what they plan on doing if anything at all.
>
> http://software.intel.com/en-us/vcsource/tools/opencl-sdk
> http://www.intel.com/content/www/us/en/processors/xeon/xeon-phi-detail.html
>
> Just based on those, I'm pretty certain they 'have a dog in 
> this race'. The dog happens to be running with MPI and OpenCL 
> across a bridge made of PCIe.

The Xeon Phi is interesting in so far as taking generic 
programming to a more parallel environment. However it has some 
serious limitations that will heavily damage its potential 
performance.

AVX2 is completely the wrong path to go about improving 
performance in parallel computing, The SIMD nature of this 
instruction set means that scalar operations, or even just not 
being able to fill the giant 256/512bit register wastes huge 
chunks of this things peak theoretical performance, and if any 
rules apply to instruction pairing on this multi issue pipeline 
you have yet more potential for wasted cycles.

I haven't seen anything about intels, micro thread scheduler, or 
how these chips handle mass context switching natural of micro 
threaded environments, These two items make a huge difference in 
performance, comparing radeon VLIW5/4 to radeon GCN is a good 
example, most of the performance benefit of GCN is from easy of 
scheduling scalar pipelines over more complex pipes with 
instruction pairing rules etc.

Frankly Intel, has some cool stuff, but they have been caught 
with their pants down, they have depended on their large fab 
advantage to carry them over and got lazy.

We likely are watching AMD64 all over again.

>> The reason to point out HSA, is because it is really easy add 
>> support for, it is not a giant task like opencl would be. A 
>> few changes to the front end compiler is all that is needed, 
>> LLVM's backend does the rest.
>
> H'okay. I can accept that.
>
>> OpenCL isn't just a library, it is a language extension, that 
>> is ran through a preprocessor that compiles the embedded 
>> __KERNEL and __DEVICE functions, into usable code, and then 
>> outputs .c/.cpp files for the c compiler to deal with.
>
> But all those extra bits are part of the computing 
> *environment*. Is there something wrong with requiring the 
> proper environment for an executable?
>
> A more objective question: which devices are you trying to 
> target here?

A first, simply a different way of approaching std.parallel like 
functionality, with an eye gpgpu in the future when easy 
integration solutions popup(such as HSA).

>> Those are all platform specific, they change based on the whim 
>> and fancy of NVIDIA and AMD with each and every new chip 
>> released, The size and configuration of CUDA clusters, or 
>> compute clusters, or EU's, or whatever the hell x chip maker 
>> feels like using at the moment.
>>
>> Long term this will all be managed by the underlying support 
>> software in the video drivers, and operating system kernel. 
>> Putting any effort into this is a waste of time.
>
> Yes. And the only way to optimize around them is to *know 
> them*, otherwise you're pinning the developer down the same way 
> OpenMP does. Actually, even worse than the way OpenMP does - at 
> least OpenMP lets you set some hints about how many threads you 
> want.

It would be best to wait for a more generic software platform, to 
find out how this is handled by the next generation of micro 
threading tools.

The way openCL/CUDA work reminds me to much of someone setting up 
tomcat to have java code generate php that runs on their apache 
server, just because they can. I would rather tighter integration 
with the core language, then having a language in language.

>> void example( aggregate in float a[] ; key , in float b[], out
>>   float c[]) {
>> 	c[key] = a[key] + b[key];
>> }
>>
>> example(a,b,c);
>>
>> in the function declaration you can think of the aggregate 
>> basically having the reserve order of the items in a foreach 
>> statement.
>>
>> int a[100] = [ ... ];
>> int b[100];
>> foreach( v, k ; a ) { b = a[k]; }
>>
>> int a[100] = [ ... ];
>> int b[100];
>>
>> void example2( aggregate in float A[] ; k, out float B[] ) { 
>> B[k] = A[k]; }
>>
>> example2(a,b);
>
> Contextually solid. Read my response to the next bit.
>
>> I am pretty sure they are simply multiplying the index value 
>> by the unit size they desire to work on
>>
>> int a[100] = [ ... ];
>> int b[100];
>> void example3( aggregate in range r ; k, in float a[], float 
>> b[]){
>>   b[k]   = a[k];
>>   b[k+1] = a[k+1];
>> }
>>
>> example3( 0 .. 50 , a,b);
>>
>> Then likely they are simply executing multiple __KERNEL 
>> functions in sequence, would be my guess.
>
> I've implemented this algorithm before in OpenCL already, and 
> what you're saying so far doesn't rhyme with what's needed.
>
> There are at least two ranges, one keeping track of partial 
> summations, the other holding the partial sorts. Three separate 
> kernels are ran in cycles to reduce over and scatter the data. 
> The way early exit is implemented isn't mentioned as part of 
> the implementation details, but my implementation of the 
> strategy requires a third range to act as a flag array to be 
> reduced over and read in between kernel invocations.
>
> It isn't just unit size multiplication - there's communication 
> between work-items and *exquisitely* arranged local-group 
> reductions and scans (so-called 'warpscans') that take 
> advantage of the widely accepted concept of a local group of 
> work-items (a parameter you explicitly disregarded) and their 
> shared memory pool. The entire point of the paper is that it's 
> possible to come up with a general algorithm that can be 
> parameterized to fit individual GPU configurations if desired. 
> This kind of algorithm provides opportunities for tuning... 
> which seem to be lost, unnecessarily, in what I've read so far 
> in your descriptions.
>
> My point being, I don't like where this is going by treating 
> coprocessors, which have so far been very *very* different from 
> one another, as the same batch of *whatever*. I also don't like 
> that it's ignoring NVidia, and ignoring Intel's push for 
> general-purpose accelerators such as their Xeon Phi.
>
> But, meh, if HSA is so easy, then it's low-hanging fruit, so 
> whatever, go ahead and push for it.
>
> === REMINDER OF RELEVANT STUFF FURTHER UP IN THE POST:
>
> "A more objective question: which devices are you trying to 
> target here?"
>
> === AND SOMETHING ELSE:
>
> I feel like we're just on different wavelengths. At what level 
> do you imagine having this support, in terms of support for 
> doing low-level things? Is this something like OpenMP, where 
> threading and such are done at a really (really really 
> really...) high level, or what?

Low level optimization is a wonderful thing, But I almost wonder 
if this will always be something where in order todo the low 
level optimization you will be using the vendors provided 
platform for doing it, as no generic tool will be able to match 
the custom one.

Most of my interaction with the gpu is via shader programs for 
Opengl, I have only lightly used CUDA for some image processing 
software, So I am certainly not the one to give in depth detail 
to optimization strategies.

sorry on point 1, that was a typo, I meant

1. The range must be known prior to execution of a gpu code block.

as for

3. Code blocks can only receive a single range, it can however be 
multidimensional

int a[100] = [ ... ];
int b[100];
void example3( aggregate in range r ; k, in float a[], float
   b[]){
   b[k]   = a[k];
}
example3( 0 .. 100 , a,b);

This function would be executed 100 times.

int a[10_000] = [ ... ];
int b[10_000];
void example3( aggregate in range r ; kx,aggregate in range r2 ; 
ky, in float a[], float
   b[]){
   b[kx+(ky*100)]   = a[kx+(ky*100)];
}
example3( 0 .. 100 , 0 .. 100 , a,b);

this function would be executed 10,000 times. the two aggregate 
ranges being treated as a single 2 dimensional range.

Maybe a better description of the rule would be that multiple 
ranges are multiplicative, and functionally operate as a single 
range.