Running Haskell on Xeon-Phi

Question

Is there a way to compile Haskell to run on the Xeon Phi coprocessor?

Some researchers at Intel have recently reported on the Haskell Research Compiler (that is not publicly available, which makes their results essentially irreproducible) and measured the Haskell Gap (showing that in some cases Haskell performance surpasses C). They describe a compilation route via an intermediate language called Pillar (similar to C--) and compile it to C so they then can use icc to create object code that is executable on a Phi.

GHC supports compilation to LLVM or generates native code directly (NCG). As far as I'm aware, neither is there a NCG targeting Phi available, nor an LLVM backend for the Phi. Having access to icc, a route via C seems possible, however I'm not sure how realistic it is at present (I think C code generator in GHC is no longer supported, the same is true for LLVM IR-to-C backend, correct me if I'm wrong).

So three routes come to mind:

1. Compile GHC in unregistered mode and compile with -fvia-c then with icc

2. Use older GHC version to generate C code and then use icc

3. Use older LLVM version to go via GHC LLVM then generate C from LLVM and then use icc

Which route is most viable (why/why not)? Are there are other possibilities (I dismissed the Pillar route since the tools such as pillar2c are not (yet?) publicly available).

A related question is about x86 compatibility of the Phi -- it seems like SSE/AVX instructions are not supported and some object code would fail to run if compiled with e.g. gcc or clang.

Update:

After chatting to some Intel folks at the LLVM conference, it seems unlikely that they will release their Phi LLVM backend. However, next generation of Xeon Phi will support AVX512.

Edme

Answer 1

If you compile your Haskell down via C, isn't the result constrained to be no faster than C as you could have written that C code directly? Your question notes that the project you're trying to reproduce is compiled via a different language.

So I'm not sure the available tooling is sufficiently advanced to do what you're wanting to do, sorry.

Juvenal

assembler generated from idiomatic C programs is potentially less well-optimised than one generated from Haskell (even via C) because of some optimisations that are possible due to some properties of functional languages (e.g. purity); the project I mentioned uses different intermediate language but still goes via C and icc; writing C doesn't seem to be viable for performance portability: architectures are highly diverse and evolve rapidly, so one would need to re-write adn re-tune a C program on each architecture, a job that (ideally) a sophisticated compiler should do – Edme