GPUs and Array Operations

[Craig Black]

You are quite right.  The compiler should never assume that the programmer 
wants GPU computation.  I was thinking of a feature that would do GPU 
computation optionally.  I don't know exactly how the syntax would be 
though.  It probably will end up being a library and not something supported 
directly by the compiler.

-Craig

"Saaa" <empty at needmail.com> wrote in message 
news:f6q4ac$h39$1 at digitalmars.com...
> GPGPU isn't generally something you want to compiler to handle. Well, at 
> least it should not be enabled by default. The first thing a GPU needs to 
> handle is the graphics and no program should be hogging up GPU resources 
> for anything else by default.
> I think its more worthwhile to let the compiler take as much advantage as 
> possible of all available instruction sets the CPUs have to offer. But 
> then again, I don't exactly know in what degree this already applies to 
> the D compiler.
> Of course everybody is free and encouraged to start a nice project  to 
> simplify the implementation of GPGPU in D :)
>
>
> "Craig Black" <craigblack2 at cox.net> wrote in message 
> news:f6p829$1l06$1 at digitalmars.com...
>> Lately I've been learning about GPU's, shaders, and general purpose GPU 
>> computation. I'm still just getting introduced to it and haven't gotten 
>> very deep yet, so there's probably a few of you out there who know a lot 
>> more than me about this subject.  It's probably  been discussed before in 
>> this news group, but I've been thinking about how important GPU's will be 
>> in the coming years.
>>
>> For those who may not know, GPU performance has been improving at a rate 
>> faster than Moore's Law.  Current high-end GPU's have many times more 
>> floating point performance than than high-end CPU's.  The latest GPU's 
>> from NVidia and AMD/ATI brag a massive 500 and 400 single-precision 
>> gigaflops respectively.  Traditionally GPU's were used for graphics only. 
>> But recently GPU's have been used for general purpose computation as 
>> well. The newer GPU's are including general purpose computation in design 
>> considerations.
>>
>> The problem with GPU programming is that computation is radically 
>> different from a conventional CPU.  Because of the way the hardware is 
>> designed, there are more restrictions for GPU programs.  For example, 
>> there are no function pointers, no virtual methods, and hence no OOP. 
>> There is no branching. Because of this conditional statements are highly 
>> inefficient and should be avoided.  Because of these constraints, special 
>> purpose programming languages are required to program natively on a GPU. 
>> These special purpose programming languages are called shading languages, 
>> and include Cg, HLSL and GLSL.
>>
>> GPU computation is performed on data streams in parallel, where 
>> operations on each item in the stream is independent.  GPU's work most 
>> effectively on large arrays of data.  The proposed "array operations" 
>> feature in D has been discussed a lot.  It is even mentioned in the 
>> "future directions" page on the D web site.  However, I don't remember 
>> the details of the array operations feature.  What are the design goals 
>> of the this feature? To leverage multi-cores and SSE?  Are GPU's also a 
>> consideration?
>>
>> There are already C++ libraries available that provide general purpose 
>> computation using GPU's without shader programming.  When it comes time 
>> to implement array operations in D, I feel that GPU's should be the 
>> primary focus.  (However, I'm not saying that multicore CPU's or SSE 
>> should be ignored.)  Design goals should be performance, simplicity, and 
>> flexibility.
>>
>> Thoughts?
>>
>> -Craig
>
>