[Haskell] Re: Haskell Digest, Vol 33, Issue 3

[Chad Scherrer]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/haskell/attachments/20060509/0da23a85/attachment.htm