Phil, thanks for the response.
> 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 guess this comes down to how par is used. If par is used where
evaluation would otherwise be entirely lazy, I wouldn't worry too much
about reasoning about whether the sparked thread actually starts or
not. But it would be nice to take code that has had seq introduced in
some places to avoid stack overflows from excessive laziness and be
able to replace seq with something else that would keep the same
strictness, but evaluate in parallel. Of course, this could be done at
a higher level than the cut-and-paste approach.
While I've got you're attention, I wonder if you could help me
understand the current state of GPH, and how it relates to recently
available shared-memory parallelism available in GHC. It seems to me
the ease of parallelism in Haskell could be its "killer app", at least
for the folks I interact with. It would be nice if the same code could
be used on GPH and parallel GHC, but I'm not sure whether that's the
case. Having GHC run in parallel out of the box is great, but if it's
moved to a distributed-memory system, I'm also not sure to what extent
increased latency is taken into account.
Thanks,
Chad Scherrer
"Time flies like an arrow; fruit flies like a banana" -- Groucho Marx
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell