[Haskell-cafe] Re: Chameneos
haskell at list.mightyreason.com
Fri Jan 6 09:14:52 EST 2006
Aaron Denney wrote:
> On 2006-01-06, Chris Kuklewicz <haskell at list.mightyreason.com> wrote:
> I note that
> # Like the erlang entry, this uses a separate thread to match up two
> # chameneos in the meeting room.
> Which seems to me to be against the spirit of the benchmark, which
> describes itself as a "symmetrical thread rendez-vous". Having this
> manager thread makes it assymetrical. Yes, the Erlang entry does it
> (and it does appear to be the totally idiomatic way to do this, as one
> of the common things to do is model persistent objects as processes),
> but that doesn't necessarily mean that it is "right" to do so.
> I think the intent is to have something like the Java model where
> each thread calls some function to do the rendezvous and synchronize and
> do wakeups on shared data -- essentially move what the manager thread
> does into each color thread.
> Note: I'm not saying that the seperate thread handling the rendezvous
> data structure isn't a very good and clear approach to the problem, just
> that it doesn't seem to be what the benchmark intended (unless built-in
> to the concurrency primitives provided by the language or language
One could make an MVar version which did not use a meeting thread, and I
welcome someone to do that. I have no proof that the current solution
is really the fastest architecture.
When I started writing solutions, I made an STM based version without
the separate meeting place thread . This is posted on the wiki (scroll
down to the bottom two pieces) in a normal and over-annotated form. So
it is possible to use idiomatic Haskell (STM) to create a solution. But
some of the entries used a manager thread, so I wrote an MVar + Chan
version which instantly was faster than the STM one. Since then I
focused on speeding up the MVar version, till not it is the winning
version. If I can use Simon Marlow's UNBOXED ideas, then I may submit
an ever faster version.
It is possible to submit the STM version as well and they will include
it as a demonstration, but I have not bothered. Someone else could
submit it if they cared to.
If you think about it, you will realize that if inter-process
synchronization is a bottleneck then STM will be slower. By definition
STM aborts and throws away work if a commit fails. Also, MVars have
wake-only-one-waiting-thread (FIFO) semantics whereas TVars and TMVars
and TChans (and all STM constructs) have wake-all-waiting-thread
semantics, even if only one can proceed.
More information about the Haskell-Cafe