GHC on Cray XMT?

[Peter Tanski]

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