GPUs and Array Operations

[Saaa]

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