
The essence of mergeIO is to merge the _lists_ that are produced by independent threads. As far as Haskell is concerned, the elements in the list are another matter, as is the evaluation of those elements. So the merge functions force the evaluation of their arguments to a certain extent. It's up to the program to determine how much more is done in the thread. Your program can be modified to have the effect you wish by defining the two lists so that evaluating each list forces the evaluation of its element. < [res0, res1] <- mergeIO [sum0] [sum1] ---
sum0s = sum0 `seq` [sum0] sum1s = sum1 `seq` [sum1] [res0, res1] <- mergeIO sum0s sum1s
On Sunday 14 March 2010 19:26:02 Brock Peabody wrote:
OK, I think I figured it out. If I understand correctly, I was just computing the input lists in parallel. The actual values were computed in the main thread lazily, later. This seems unintuitive to me. Shouldn't the merge functions force the evaluation of their arguments? Surely one wouldn't be calling them if they wanted to compute the results lazily.
On Sun, Mar 14, 2010 at 6:25 PM, Brock Peabody
wrote: Hi, I've been trying to use Control.Concurrent.mergeIO to parallelize computation, and can't make it work. In the sample program below, I expect the function 'parallelTest' to be almost twice as fast as 'sequentialTest', and to compute its results in two threads, as implied by the documentation for mergeIO. This is not what happens. If I link my program with the option '-threaded', the running process does have three threads. If I run with the option "+RTS -N2", the process will have 5 threads. In no case does the process appear to be using more than one CPU, and in fact it is slower with the threading options turned on.