SIMD support...

[Manu]

On 6 January 2012 17:01, Russel Winder <russel at russel.org.uk> wrote:

> On Fri, 2012-01-06 at 16:35 +0200, Manu wrote:
> [...]
> > I don't see any issue with this. An array of vectors makes perfect sense,
> > and I see no reason why arrays/slices/etc of hardware vectors should be
> any
> > sort of problem.
> > This particular expression should be just as efficient as if it were an
> > array of flat floats, especially if the compiler unrolls it.
> >
> > D's array/slice syntax is something I'm very excited about actually in
> > conjunction with hardware vectors. I could do some really elegant
> geometry
> > processing with slices from vertex streams.
>
> Excuse me for jumping in part way through, apologies if I have the
> "wrong end of the stick".
>
> As I understand it currently the debate to date has effectively revolved
> around how to have first class support in D for the SSE (vectorizing)
> capability of the x86 architecture.


No, I'm talking specifically about NOT making the type x86/SSE specific.
Hence all my ramblings about a 'generalised'/typeless v128 type which can
be used to express 128bit SIMD hardware of any architecture.


> This immediately raises the
> questions in my mind:
>
> 1.  Should x86 specific things be reified in the D language.  Given that
> ARM and other architectures are increasingly more important than x86, D
> should not tie itself to x86.
>

The opcodes intrinsics you use to interact with the generalised type will
be architecture specific, but this isn't the end point of my proposal. The
next step is to produce libraries which will use version() heavily behind
the API to collate different architectures into nice user-friendly vector
types.
Sadly vector units across architectures are too different to expose useful
vector types cleanly in the language directly, so libraries will do this,
making use of compiler defined architecture intrinsics behind lots of
version() statements.


> 2.  Is there a way of doing something in D so that GPGPU can be
> described?
>

I think this will map neatly to GPGPU. The vector types proposed will apply
to that hardware just fine.
This is a much bigger question though, the real problems are:
  * How to you compile/produce code that will run on the GPU? (do we have a
D->Cg compiler?)
  * How do you express the threading/concurrency aspects of GPGPU usage?
(this is way outside the scope of vector arithmetic)
  * How do you express the data sources available to GPU's? Constant files,
etc... (seems D actually had reasonably good language expressions for this
sort of thing)

Currently GPGPU is dominated by C and C++ using CUDA (for NVIDIA
> addicts) or OpenCL (for Apple addicts and others).  It would be good if
> D could just take over this market by being able to manage GPU kernels
> easily.  The risk is that PyCUDA and PyOpenCL beat D to market
> leadership.
>

As said, I think these questions are way outside the scope of SIMD vector
libraries ;)
Although this is a fundamental piece of the puzzle, since GPGPU is no use
without SIMD type expression... but I think everything we've discussed here
so far will map perfectly to GPGPU.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120106/571166ef/attachment-0001.html>