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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
