static code generation and open Accs
Stephen Blackheath [to Accelerate]
lug.agonised.stephen at blacksapphire.com
Sun Aug 22 09:24:36 EDT 2010
Manuel & Trevor & all,
I mentioned to you at AusHac2010 that I've got some Haskell code in our
video game that needs speeding up, and accelerate is looking like an
attractive option to avoid having to write some C.
Since our platforms are mobile ones (and therefore no compiler at
runtime), I'm considering writing a static C back end for accelerate, so
I took a look at what would be needed.
The generated code would need to be a C function that takes arguments,
and so the accelerate AST would have to represent a lamba expression.
Assuming I'm reading the code right, it looks like I can do this easily
by adding the arguments to the environment, then binding an Avar to the
argument names at the Haskell level. Primitive values can be passed in
However, the accelerate language code could not have the current type of
Acc a ~ OpenAcc () a, because that doesn't allow the environment type
required by Avar. The obvious way to fix this is to change every
function in the accelerate language to have type OpenAcc aenv a instead
of Acc a. But - I can't imagine you would want to do this.
I tried to think of some type trickery to somehow 'bubble' the types of
the argument Avar values through the environment type up to the top
level after the fact. This would be the ideal solution, but at the
moment I can't see any way of doing it. What we'd like to do is take
some expression, for example, containing an Avar value of type Acc
(Array DIM1 Int) somewhere in the AST, and translate it internally to an
expression of type OpenAcc (Array DIM1 Int, ()) a.
If that doesn't work, then a solution that would work after a fashion is
to have a whole new public module, perhaps Data.Array.Accelerate.Open,
which duplicates the whole accelerate language, but uses OpenAcc aenv
types. There are several reasons why this is not nice, though.
So, my questions are:
1. Do I understand the code wrong, that is, is there some easier way of
achieving static compilation that I can't see?
2. If I have got it right, do you know of any way to achieve the type
trickery so we could introduce Avar values without having to expose the
OpenAcc types at the accelerate language level?
3. If you don't, then do you think the type trickery approach is valid?
If so, I'd be happy to spend some more time on it and try to figure
out a way to achieve it.
4. Failing the above, is there any other way we can do it? (Perhaps
static compilation is not something you want to do.)
More information about the Accelerate