Making new Unboxed Algebraic Types? (A Repa Problem)

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... -- :-- Hans Georg

boxity has nothing to do with parallelism. none :) On Mon, Jun 30, 2014 at 2:55 PM, Hans Georg Schaathun < georg+haskell@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...
-- :-- Hans Georg _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mon, Jun 30, 2014 at 03:53:55PM -0400, Carter Schonwald wrote:
boxity has nothing to do with parallelism. none :)
No, but it may affect /when/ haskell computes a value, and if the computation is delayed until the value is requested, then --hey-- we just missed the parallel opportunity. Quite simply, Repa's computeP does not work as expected out of the box when it is applied to a boxed return type. If that amounts to «nothing to do with» in your book, that's ok; it is still a problem which requires a solution. BTW, I thought a bit more and the solution using NFData suggested in http://stackoverflow.com/questions/16097418/parallel-repa-code-doesnt-create... was easier to implement than I feared, and more importantly, it works. I don't find it entirely satisfactory though, so any hints on how to use unboxed arrays with composite constituent types are still very welcome. -- :-- Hans Georg

Hans Georg Schaathun
Is there a quick and robust way to make Unbox instances from composite datatypes?
You will probably want to look at the vector-th-unbox package[1]. Cheers, - Ben [1] http://hackage.haskell.org/package/vector-th-unbox

vector-th-unbox describes one way to make an Unbox instance, but this StackOverflow answer goes into much more detail: http://stackoverflow.com/questions/22882228/how-to-store-a-haskell-data-type... On 30/06/14 23:40, Ben Gamari wrote:
Hans Georg Schaathun
writes: Is there a quick and robust way to make Unbox instances from composite datatypes?
You will probably want to look at the vector-th-unbox package[1].
Cheers,
- Ben
[1] http://hackage.haskell.org/package/vector-th-unbox
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (4)
-
Ben Gamari
-
Carter Schonwald
-
Hans Georg Schaathun
-
Niklas Hambüchen