[Haskell] Pugs gains SMP parallelism support.

[Sebastian Sylvan]

On 10/23/06, Taral <taralx at gmail.com> wrote:
> On 10/23/06, Sebastian Sylvan <sylvan at 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