Hi,
thank you very much Simon & Don, for the answers.
The latest head gives great results on parallel programs. All cores are
now always at work as I hoped for. So, too, thanks to everybody involved
in the multicore improvements -- they should come very handy. :-)
Thanks again,
Christian
* Do
choener:
> Hi,
>
> having tried the 6.10.2rc1 release candidate, I still find that "parMap
> rnf xs" on a list of thunks xs does not optimally use all available
> processors. With N the number of cores, I still see that each block of N
> thunks (say: x_1 and x_2) has to be calculated before (x3
Hi,
having tried the 6.10.2rc1 release candidate, I still find that "parMap rnf xs" on a list of thunks
xs does not optimally use all available processors. With N the number of cores, I still see that
each block of N thunks (say: x_1 and x_2) has to be calculated before (x3 and x4) will be star
Simon Marlow wrote:
Christian Hoener zu Siederdissen wrote:
when using parMap (or parList and demanding) I see a curious pattern
in CPU usage.
Running "parMap rnf fib [1..100]" gives the following pattern of used
CPUs:
4,3,2,1,4,3,2,1,...
How did you find out which CPU is being used?
Sorr
Christian Hoener zu Siederdissen wrote:
when using parMap (or parList and demanding) I see a curious pattern in
CPU usage.
Running "parMap rnf fib [1..100]" gives the following pattern of used CPUs:
4,3,2,1,4,3,2,1,...
How did you find out which CPU is being used?
The fib function requires r
Greetings,
when using parMap (or parList and demanding) I see a curious pattern in CPU
usage.
Running "parMap rnf fib [1..100]" gives the following pattern of used CPUs:
4,3,2,1,4,3,2,1,...
The fib function requires roughly two times the time if we go from fib(n) to fib(n+1), meaning that
calcu
