Dean,
If the costs are the same, does that rely on there being no true concurrency in the current implementations?
It depends what you mean by true concurrency: from the point of view of the Haskell programmer, GHC's implementation of concurrency is "almost" preemptive, because we can context-switch at any allocation. Most computation does some allocation, but it's possible to write functions that don't (although these tend to be on the trivial side - an optimised nfib won't allocate, for example). We could artificially cause all computation to do some allocation to avoid this problem, but we haven't found it necessary so far.
But I suspect by "true concurrency" you're referring at the kind of concurrent processes that can be executed on multiple CPUs simultaneously. We did investigate doing this a while back, and found that the locking required on thunks was very expensive (slowed down the program by at least 2x on the bog-standard SMP machine we had here). However there are some clever techniques that can be used to reduce the cost - giving each process its own private allocation area and only degrading to full locking for access to the shared portion of the heap is one such technique we experimented with briefly but I don't have any concrete benchmarks I'm afraid. Also you really need a multithreaded garbage collector, which is a lot of work.
We've developed a Haskell extension that exhibit's "true concurrency" on multiple CPUs, it's called Glasgow distributed Haskell (GdH). It's primarily designed for distribution (i.e. multiple stateful threads on multiple processors), but can be used to build parallel programs too. For more info see http://www.cee.hw.ac.uk/~dsg/gdh/ Phil -------------------------------------------------- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: trinder@cee.hw.ac.uk Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder