How to parallelise symmetric workers?

Question

If I have an async value work which I want duplicated and executed in parallel so that hardware capabilities for thread execution are exhausted, how would I do that?

E.g., for a short specific example, consider the following silly program, which searches for a random number less than 1001:

let bound = ref System.Int32.MaxValue
let work = 
  async {
    let rand = new System.Random () 
    while !bound > 1000 do
      let x = rand.Next ()
      if x < !bound then
        bound := x
  }

[| work; work; work |] 
|> Async.Parallel
|> Async.RunSynchronously

(Ignore synchronisation issues for bound.)

Here, I run three workers; the program would be correct for any non-zero number; and presumably more efficient when the number of workers is exactly the number of available cores. How do I change this program so that the number of workers is chosen automatically depending on the number of available cores?

Update. Is using Async.Parallel and manually indicating the number of threads the right way to parallelise a CPU-bound computation like the above? If not, what is?

[How to find the Number of CPU Cores via .NET/C#?](http://stackoverflow.com/q/1542213/126014) — Mark Seemann, Mar 27 '15 at 15:13
...so would, `Seq.init (fun _ -> work) processorCount |> Async.Parallel` etc... work for you? — Mark Seemann, Mar 27 '15 at 15:17
Duh. Thanks. I was all caught up in thinking there should be some API for replicating an async (or function) on the maximal number of available threads. — Søren Debois, Mar 27 '15 at 20:09

Just another metaprogrammer · Answer 1 · 2015-03-28T14:21:37.977

One way to determine the number of available cores for a Process is something like this:

let numberOfAvailableCores () : int =
    let p = System.Diagnostics.Process.GetCurrentProcess().ProcessorAffinity

    let rec countOnes acc = function
        | 0un -> acc
        | n -> 
            let i = int (n &&& 1un)
            countOnes (acc + i) (n >>> 1)

    countOnes 0 (unativeint p)

I find this more exact than System.Environment.ProcessorCount as AFAIK fails it to take ProcessorAffinity into account.

Update: As Parallel doesn't expose a function to invoke an action "in parallel" a possible solution could be something like this:

let numberOfAvailableCores () : int =
    let p = System.Diagnostics.Process.GetCurrentProcess().ProcessorAffinity

    let rec countOnes acc = function
        | 0un -> acc
        | n -> 
            let i = int (n &&& 1un)
            countOnes (acc + i) (n >>> 1)

    countOnes 0 (unativeint p)

let executeInParallel (a : unit->unit) : unit =
    let cores = numberOfAvailableCores ()

    let actions = 
        [|
            for x in 1..(cores * 2) -> Action a
        |]

    Parallel.Invoke actions

A tip when trying to estimate if you have any contention between cores it can be useful to just run on 1 core and compare the result with the "full" core solution. If you have good solution you should see a linear improvement when enabling more cores. A simple way to run on just 1 core is to set the ProcessorAffinity flag

let p = System.Diagnostics.Process.GetCurrentProcess ()
p.ProcessorAffinity <- 1n // Makes this process "single-core"

(I am trying my hardest to resist answering questions you didn't ask but I am still weak from the flu)

PS. F# Async are great in many ways but they are primarily aimed at solving the Responsiveness problem not the Scalability problem. That means if you are using a lot of composing of Async workflows you will probably lose valuable clock cycles. The example you posted wouldn't suffer though. For CPU bound problems I tend to go for Parallel as it employs auto scaling and work stealing to utilize all CPU resources while having low overhead. Task or hopac are also good alternatives.

PS. If you want to managing the scaling yourself I believe the rule of thumb is twice the number of cores.

PS. You said ignore the synchronization issues for bound and that's fair but I just want to point out that if one has a shared resources frequently accessed by all cores one probably won't see much performance gain.

Thanks for the very informative answer. I'd love it if you took a look at my updated question—your first PS seems it could be very helpful if expanded? — Søren Debois, Mar 27 '15 at 20:14
IMO using `Parallel` is generally better for CPU bound problems. `Parallel.For` IIRC scales automatically according to the number of cores available, has a cool work-stealing algorithm and uses `User-mode threads` which are more efficient. — Just another metaprogrammer, Mar 27 '15 at 21:26
Also it important to measure the performance gain of going multicore compared to singlecore. It's quite easy to end up with very poor efficiency and the only real way to detect it is to measure. — Just another metaprogrammer, Mar 27 '15 at 21:30
I looked at Parallel, but it seems to apply only when I know the number of iterations upfront. In the random number example (and in my real problem) I don't know how many times I need to run the body of the while-loop? — Søren Debois, Mar 28 '15 at 09:26

How to parallelise symmetric workers?

1 Answers1