Intel Haskell Research Compiler

#1

Post by mpweiher » Thu, Apr 13, 2017, 1:18 PM UTC

Intel Haskell Research Compiler
github.com

Re: Intel Haskell Research Compiler

#2

Post by amelius » Thu, Apr 13, 2017, 2:21 PM UTC

Note:

> FLRC is open sourced as is. We at Intel Labs are no longer actively working on this compiler.

Re: Intel Haskell Research Compiler

#3

Post by nitrix » Thu, Apr 13, 2017, 2:38 PM UTC

Wait... what? "To actually compile a Haskell program, we'll also need a patched version of GHC. See Building and Using GHC with HRC for more information."

Re: Intel Haskell Research Compiler

#4

Post by thu » Thu, Apr 13, 2017, 2:40 PM UTC

nitrix wrote: post #3

Wait... what? "To actually compile a Haskell program, we'll also need a patched version of GHC. See Building and Using GHC with HRC for more information."

I think they use GHC frontend to parse Haskell sources.

Re: Intel Haskell Research Compiler

#5

Post by framp » Thu, Apr 13, 2017, 2:40 PM UTC

This is the original paper from 2013: http://www.leafpetersen.com/leaf/publications/hs2013/hrc-pap...

GHC can use this intermediate code (a-la LLVM) to produce executable. The idea is to create an intermediate code which is better optimised for their CPU.

Re: Intel Haskell Research Compiler

#6

Post by larsberg » Thu, Apr 13, 2017, 2:41 PM UTC

It's wonderful to see this released! There was so much great research going on here that overlapped with work we were doing in Manticore and that was going on in other optimizing compilers for statically typed high-level languages, but the details always required talking to Neal or Leaf.

I can't wait to dig in and finally learn more than I could at after-conference drinks :-)

Re: Intel Haskell Research Compiler

#7

Post by georgewsinger » Thu, Apr 13, 2017, 2:42 PM UTC

For context, here's a quote from an abstract elsewhere on the web:

> The Intel Labs Haskell Research Compiler uses GHC as a frontend, but provides a new whole-program optimizing backend by compiling the GHC intermediate representation to a relatively generic functional language compilation platform.

and later:

> For certain classes of programs, our platform provides substantial performance benefits over GHC alone, performing 2x faster than GHC with the LLVM backend on selected modern performance-oriented benchmarks; for other classes of programs, the benefits of GHC's tuned virtual machine continue to outweigh the benefits of more aggressive whole program optimization. Overall we achieve parity with GHC with the LLVM backend.

Source: https://www.semanticscholar.org/paper/The-Intel-labs-Haskell...

Re: Intel Haskell Research Compiler

#8

Post by aurelius » Thu, Apr 13, 2017, 3:17 PM UTC

How ironic is it that the Haskell Research Compiler is written in Standard ML, and not Haskell? Joking aside, SML is a great language, and often overlooked, so this is good to see!

Re: Intel Haskell Research Compiler

#9

Post by pdpi » Thu, Apr 13, 2017, 3:36 PM UTC

nitrix wrote: post #3

Wait... what? "To actually compile a Haskell program, we'll also need a patched version of GHC. See Building and Using GHC with HRC for more information."

Haskell is a pretty large language, and (IIRC) the first step in GHC compilation is converting Haskell into Core, which is basically a tiny subset of the language.

Parsing the language isn't a very interesting research problem, and more work than it's worth, so Intel have chosen to instead use GHC's frontend to generate Core code, and then consume Core for their compiler backend.

Re: Intel Haskell Research Compiler

#10

Post by tetrep » Thu, Apr 13, 2017, 4:05 PM UTC

In essence, a big reason why the Intel team was able to do this was because they're getting optimized IR from GHC's front-end[0], and then applying further optimizations with their compiler (HRC) and then converting it into yet another IR (MIL) used by yet another compiler (FLRC), designed by Intel for arbitrary functional programming languages, for some further optimizations and ultimately into C where Intel's C compiler does the rest of the work.

It's interesting that HRC makes relatively significantly optimized programs (up to 2x), but that GHC's runtime (which HRC is not using) is so well optimized that the performance of HRC programs is roughly on par with those from GHC, despite the programs themselves being more performant.

I find stuff like this to be a testament to the practicality of great design in functional programming language ecosystems: Even the compilers are composable!

[0]: For those unfamiliar with what GHC does/how it's designed, this talk gives a great overview of the Core language that is the optimized IR of GHC: https://www.youtube.com/watch?v=uR_VzYxvbxg