Random questions after a long haskell coding day
Tue, 29 Jan 2002 11:06:26 -0000
> "Simon Marlow" <firstname.lastname@example.org> writes:
> >> Any thumb rule for using arrays? I'm expecting access to be=20
> >> O(1), it is right?
> > In GHC, yes.
> (Shouldn't this really be required? I mean, the whole=20
> *point* of using
> arrays is to have O(1) random access, isn't it?)
> Can we also rely on destructive updates for the monadic arrays?
In GHC, yes :-)
> On a different note, I have some nice SMP machinery here (eight CPU
> Sun, and possibly 192 CPU IBM :-). It appears from the documentation
> that Concurrent Haskell will only support one OS thread, and thus
> treat these machines as their one-CPU workstation equivalents.
> Parallell Haskell doesn't, but uses PVM, which seems like an
> unnecessary abstraction since I'm in a shared memory (even if
> non-uniformly so) setting. =20
> Is the cost of PVM insignificant enough to not care? Or are there
> plans or projects of which I need to be aware, that target Haskell for
> these kinds of architectures?
We had a project to run concurrent/parallel Haskell programs on an SMP
machine, but it is currently stalled. There are some significant
problems with sharing the heap between multiple running threads at the
same time as keeping the locking down to a minimum (locking and memory
barriers tend to be expensive). Furthermore you need a multi-threaded
garbage collector to really take advantage of an SMP system.
Anyway, if you're interested the code is in GHC's CVS repository, inside
The GPH (Glasgow Parallel Haskell) project is the implementation using
PVM, which runs with a distributed rather than shared heap. This means
garbage collection can be done separately on each portion of the heap,
so you don't need a multi-threaded garbage collector. On the other
hand, communication between the PEs is likely to be more expensive;
nevertheless, the GPH folks got some good speedups. Their
implementation is lagging a bit behind the current GHC release, however: