Chad Scherrer wrote:
> The new Cray XMT seems to target exactly the same kind of analytic
> problems where Haskell excels:
>>http://www.cray.com/products/xmt/>> I'm not a hardware guy, but this seems like a natural fit with the
> recent advances in SMP Haskell. I know some compiler experts, but none
> of them have experience with Haskell.
>> Can anyone tell me how big an undertaking it would this be to get GHC
> going on one of these? It seems to me like the fact that the absence
> of cache on XMT processors should simplify things, since there are
> less issues reasoning about locality.
Porting GHC to a new architecture may be easy or very involved. See
http://hackage.haskell.org/trac/ghc/wiki/Building/Porting. Porting
to the Cray XMT would appear to be very difficult but a real Plum!.
I am not sure how close its UNICOS operating system is to BSD (GHC
has ports to FreeBSD and OpenBSD)--that is just the main programming
environment; working with the processors may require a smaller
microkernel environment. According to the XMT Datasheet the main
programming is done on Linux-based nodes. Linux is GHC's "home" OS,
so that would seem to make it a little easier.
For an experience porting Glasgow Parallel Haskell (GPH) to an MPP,
you might want look at the work of Kei Davis (http://www.c3.lanl.gov/
~kei/), who ported an older version of GHC to the Thinking Machines
CM-5 SPMD (http://www.c3.lanl.gov/~kei/lanlwork.html and especially,
"MPP Parallel Haskell (Preliminary Draft)", 1996, at http://
www.c3.lanl.gov/~kei/ifl96.ps). Kei Davis's work is also referenced
on the Glasgow Parallel Haskell site, under "PORTS" (http://
www.macs.hw.ac.uk/~dsg/gph/). I mention his work in particular
because the CM-5 port involved a slightly new (Solaris-like) OS and a
specialised message passing system, CMMD, instead of PVM used by
Glasgow Parallel Haskell. That would be quit a lot of work since you
would have to modify the RTS--the old GUM (Parallel Haskell support)
stuff is still in there but it is somewhat bit-rotted.
The amount of work required might get worse or better as GHC's future
is native assembly output--worse, because you would have to work
through the assembly code and efficient C-code generation would
require more work with a nasty Perl script called the Mangler;
better, depending on whether someone essentially rewrites the ugly
spider-web of code in GHC's Native Code Generator (NCG). But all
this stuff is for a "native" port: if you have access to an XMT, you
might want to simply follow the directions on Porting GHC to a new
platform (http://hackage.haskell.org/trac/ghc/wiki/Building/
Porting#PortingGHCtoanewplatform) and see what problems you run into.
Cheers,
Peter Tanski