FW: [Haskell] parallel seq

[Phil Trinder]

Chad,

> I was thinking about the dynamic behavior of par, and there's something
> that's a little confusing to me. Am I right in understanding that (x
> `par` y) evaluates to y, and may or may not evaluate x along the way?

The reason that par doesn't necessarily evaluate it's 1st argument is that
typical parallel Haskell programs contain vast amounts of potential
parallelism. So rather than create a relatively heavyweight thread and be
forced to administer it, e.g. schedule it for every possible expression
that could be evaluated in parallel, the expression is 'sparked', i.e. a
lightweight action that simply notes that the expression *could* be
evaluated in parallel.

> I think it would be easier to reason about if we knew that x would be
> evaluated, either by a newly-spawned thread or by the parent thread.

Yes, although we usually reason by saying trhat the 'potential
parallelism' in two expressions is the same, i.e. making the assumption
that all sparked expressions become threads.

> If
> I'm understanding this correctly, this could be done by defining
>
> x `pSeq` y = x `par` y `seq` x `seq` y

This seems plausible.

All the best,

Phil

> From: haskell-bounces at haskell.org [mailto:haskell-bounces at haskell.org]
> On Behalf Of Scherrer, Chad
> Sent: 25 April 2006 21:35
> To: haskell at haskell.org
> Subject: [Haskell] parallel seq
>
> I was thinking about the dynamic behavior of par, and there's something
> that's a little confusing to me. Am I right in understanding that (x
> `par` y) evaluates to y, and may or may not evaluate x along the way?
>
> I think it would be easier to reason about if we knew that x would be
> evaluated, either by a newly-spawned thread or by the parent thread. If
> I'm understanding this correctly, this could be done by defining
>
> x `pSeq` y = x `par` y `seq` x `seq` y
> (seq has higher precedence than par)
>
> When (x `pSeq` y) is evaluated, x may or may not be evaluated by a new
> thread. The parent thread continues along evaluating y. Then the parent
> makes sure x was evaluated before finally returning y.
>
> I've not seen this approach used before -- Is there something I'm
> missing that makes using pSeq as above just silly?
>
> Thanks!
>
> Chad Scherrer
> Computational Mathematics Group
> Pacific Northwest National Laboratory
>
> "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>


--------------------------------------------------
Phil Trinder
School of Mathematical and Computer Sciences
Heriot-Watt University
Edinburgh, EH14 4AS

E-mail: trinder at macs.hw.ac.uk
Teleph: +44 (0)131 451 3435
Depart: +44 (0)131 451 3328
Fasmly: +44 (0)131 451 3327
Intrnt: http://www.macs.hw.ac.uk/~trinder