>>> You could probably see exactly what's happening in >>> more detail by going through the Core output. >> >> Thank you, this advice helped. The Core output indicates >> that function `test' evaluates the arguments to >> `parallelize' before it calls it. In other words, the >> call to `parallelize' is optimized as a strict function >> call -- which it is. The problem is that this >> optimization evaluates the arguments sequentially. >> Compiling with optimizations turned off regains the >> parallel execution. >> >> I guess I will report this as a GHC bug. Or is it a >> feature request? > > As Duncan suggessted, try with GHC head (grab a snapshot). `par` et al > are much improved.
I already have, with the snapshot from 21st of April. It behaves the same as 6.8.2, except it runs for twice as long. I'd like to take back a part of what I said before, though: `parallelize' should be strict only in its second argument. Its strictness in the first argument should be the same as with `par`. Even though `parallelize x y' always evaluates both x and y, the following test works fine with optimizations even if `parallelize' is imported: main = putStrLn (snd $ parallelize undefined "Hello, World!") So the function is not strict, and I don't understand why GHC should evaluate the arguments before the call. Does anybody know of a pragma or another way to make a function *non-strict* even if it does always evaluate its argument? In other words, is there a way to selectively disable the strictness optimization? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
