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
Chad Scherrer wrote: 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