Accelerate

[Manuel M T Chakravarty]

Ben,

I just pushed two patches, adding stencil2 and support for 9-tuples, respectively.  (BTW, we currently can only have up to 3-dimensional stencils.  There is no fundamental reason for that and copy-pasting of some class instances is all that is needed to extend this.  I might be able to change the implementation to work for arbitrary dimensions, without extra instances, but didn't want to hold up giving you something to work with just for that.)

This leaves the question of the format to reify stencils in.  The tricky bit is that (a) the format needs to work for all dimensions and (b) stencils can be irregular.  Here are two possible representations:

(A) Nested tuples (but using the ElemRepr representation of lists of pairs to represent n-tuples).  That is the representation the AST uses, so it is easy to realise, but I'm not sure whether it is convenient in the backend.

(B) Nested lists, but the nesting depth would depend on the dimension of the stencil — i.e., we would need to use a type family indexed by the stencil dimension to represent the type and hence the basic operations on those nested lists would need to be class methods (overloaded on the various nesting depths).

The big advantage of (A) is that with enough cleverness we should be able to make the code dimension-independent (and hence work for arbitrary dimensions), whereas (B) implies a fixed upper limit on stencil dimensions.

Trevor, what do you think?  Any preferences or any other ideas?

Manuel


Ben Lever:
> Hi Manuel,
> 
> I just pushed a patch with stencil support in the frontend and interpreter.  There are still three smaller items missing:
> 
> This is great! I've pulled the latest changes and have started using stencil in the algorithm we're currently porting.
> 
> 
> * Add 'stencil2' — Ben, do you need this at the moment? (should be easy to add)
> 
> I don't think I'll need stencil2 for the current algorithm, so there's no rush for it. It may be simple enough for us to have a go at implementing.
> 
> 
> * Add support for up to 9-tuples (currently, the maximum is 5-tuples) — trivial cut-copy-paste job
> 
> I will need 8-tuple support so I'll look at adding support for up to 9-tuples.
> 
> 
> * Add support to reify the stencil shape for the CUDA backend — should maybe go into a new module D.A.A.Analysis.Stencil (main question is what the nicest representation of the reified form is, remember that stencil can be irregular)
> 
> 
> I spoke with Trevor this morning about this and together we will work on the CUDA backed. Rami and I we be able to contribute the CUDA stencil skeleton and Trevor is going to take a look at what's required in the Haskell-portion of the backend.
> 
> 
> Regards,
> 
> Ben Lever
> Senior Researcher Engineer
> National ICT Australia
> 
> NICTA l Locked Bag 9013 l Alexandria NSW 1435
> T + 612 8306 0742 | F +612 9376 2027
> www.nicta.com.au<http://www.nicta.com.au/> l ben.lever at nicta.com.au<mailto:ben.lever at nicta.com.au>
> 
> From imagination to impact.
> 
> 
> 
> 
> 
> 
> ________________________________
> The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.