Nice comment. Aaron Denney wrote: > On 2006-01-06, Chris Kuklewicz <[EMAIL PROTECTED]> wrote: > >>http://www.haskell.org/hawiki/ChameneosEntry > > > 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 > implementation). >
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. -- Chris _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe