Petr P | 20 Jan 00:56 2013
Picon

Why should we write "a `par` b `pseq` (f a b)" instead of "a `par` b `par` (f a b)"?

  Dear Haskellers,

I've been playing with par and pseq, and I wonder: Is there any reason to use
  a `par` b `pseq` (a + b)
instead of
  a `par` b `par` (a + b)
except that the second version sparks twice instead of just once (which probably degrades performance a bit)? It seems to me that the second variant would work as well: The main thread would block on one of the sparked computations, but the other one would still be evaluated in parallel.

The second variant seems to have one additional advantage: If the function that combines 'a' and 'b' isn't strict (and perhaps we don't know that in advance), the main thread won't be blocked by evaluating the computation it doesn't need. Like
    a `par` b `pseq` (const a b)
will block until both 'a' and 'b' are evaluated, but
  a `par` b `par` (const a b)
will finish as soon as 'a' is evaluated.

I found this link on SO:
Why do we need 'seq' or 'pseq' with 'par' in Haskell? <http://stackoverflow.com/q/4576734/1333025>
but it doesn't really solve this objection.

  Thanks for help,
  Petr Pudlak
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Johannes Waldmann | 20 Jan 14:34 2013
Picon

Re: Why should we write "a `par` b `pseq` (f a b)" instead of "a `par` b `par` (f a b)"?

Petr P <petr.mvd <at> gmail.com> writes:

> Is there any reason to use
>   a `par` b `pseq` (a + b)
> instead of
>   a `par` b `par` (a + b)

(better ask this on parallel-haskell?)

> It seems to me that the second variant would work as well: 
> The main thread would block on one of the sparked computations,

I think the main thread would not block at all.
Instead, it would start to evaluate  a  (or  b) right away, 
since (+) is strict, thus duplicating the work of
a spark, and causing the spark to fizzle.

Why does it work in   a `par` b `pseq` a+b ?
I am not even sure - there might be a race condition:
assume that evaluation (to WHNF) of  b (and of  a)  takes a long time,
but  b  (in the main thread) finishes shortly 
before  a  does (in the spark), 
then the spark still fizzles and its work was in vain?

J.W.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane