On 10/23/06, Taral <taralx@gmail.com> wrote:
On 10/23/06, Sebastian Sylvan <sylvan@student.chalmers.se> wrote:
I'm not so sure that a newArray is faster than N copies of newEmptyMVar, at any rate the [MVar] approach has *no* congestion points
They are congestion points because each thread could conceivably attempt to putMVar at the same time as the main thread tries to takeMVar.
That's not a congestion point at all! No more than I would call it congestion if one thread reads a channel and the other writes to it. It's just a straight consumer/producer relationship. The consumer blocks until the producer is done. With a congestion point (like a shared semaphore, depending on implementation of course) the independent producers interfere with each other because one thread can't signal the semaphore at the same time as another thread so they will have to wait until they can get access to the semaphore.
You could try having an array of MVars to get rid of the extra space that the list takes, and use unsafeWrite etc. to get faster writes back to the result array. Then do takeMVar on each item in the array to get "block for N resources" behaviour without having a single resource semaphore that could (profile!) suffer from congestion.
Meh, it seems like a lot of work for little.
How many elements were in the benchmark list? I notice that the original benchmark ran for 5 seconds or so, what happens if the work per element is increased? If the length is increased? It's possible that the array approach wins when you try to process 100,000 elements.
Perhaps. Depends on if congestion is indeed the bottle neck. If not, and if non-overlapping array access is indeed thread safe, then using unsafeRead etc. to use your original approach would surely be beneficial in this case. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862