[Haskell-cafe] Making new Unboxed Algebraic Types? (A Repa Problem)

[Carter Schonwald]

boxity has nothing to do with parallelism. none :)


On Mon, Jun 30, 2014 at 2:55 PM, Hans Georg Schaathun <
georg+haskell at schaathun.net> wrote:

> Hi,
>
> could someone offer som advice on handling composite types with
> the Repa library?  I can see a /long/ way around my problem, but
> I wonder what is the /best/ way ...
>
> The problem is that I am trying to parallellise a probabilistic
> algorithm using Repa.  To handle pseudo-randomness in parallel,
> I couple each data element with a generator state, in a tuple.
> The generator state is of type TFGen (tf-random package) or
> StdGen¹ (random package), neither of which is an Unbox instance.
> Hence, I have been using boxed repa arrays.
>
> The code does not execute in parallel, and if I understand correctly
> this is because of the Boxed type.  There is a workaround², but that
> requires an NFData instance.
>
> To make a NFData instance and work through the code to support it
> should be as simple as it is tedious, but it would still leave the
> other drawbacks of a boxed type.  (In particular, I do sequential
> fold because the Repa fold function did not support boxed types.)
>
> I could of course rewrite the published libraries to use tuples instead
> of algebraic types, and benefit from the pre-made Unbox instances, but
> sounds messy and error-prone (as well as boring).  If I have to I have
> to.
>
> Is there a quick and robust way to make Unbox instances from composite
> datatypes?  Or any other advice on how to approach the matter?
> Both random ideas, references, and concrete solutions are welcome.
>
> [The other element of the tuple is an vector of unboxed constituent
> type.  I am not sure how that's going to work, but I'll cross that
> bridge when I get there.  For the time being it is the generator that
> stops type checking.]
>
> TIA
>
>
> ¹ Yes, I know that StdGen is statistically unsound.
> ²
> http://stackoverflow.com/questions/16097418/parallel-repa-code-doesnt-create-sparks
>
>
> --
> :-- Hans Georg
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140630/63086378/attachment.html>