Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Haskell Research Compiler

github.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Intel Haskell Research Compiler

#21

Post by dbcurtis »

amelius wrote: post #2

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

Indeed. Fire and forget. Sad.

Some number of years ago I worked in Intel's software labs. It really drove home to me the point that software development is a long attention span activity, and chip development is a short attention span activity. Mixing both at the same company is difficult. A chip design has a short shelf life, and zero field upgradability, so to be successful building chips you drive hard to tape out, and then move on to the next iteration as soon as possible. Software, OTOH, is a many-years-long process of incremental improvement and field updates.

Trying to do software development in a company where much of the management are "sand heads" (physical chemists that came up through the chip world) requires dealing with a huge cultural communication gap.

Re: Intel Haskell Research Compiler

#22

Post by jl6 »

tikhonj wrote: post #13
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."

Think of this as closer to an optimizing backend for GHC than a completely brand-new compiler. It uses GHC to parse, typecheck and desugar Haskell to an intermediate form called Core and uses that to do its own optimization and code generation. A core design principle of Haskell is that while the whole language has gotten relatively complex thanks to all its language features and extensions, almost everything can be…

Is there any chance they might miss an opportunity for optimisation by throwing out the sugar, thereby discarding information about the prgrammer's intent?

Or does the sugar carry no such information?

Re: Intel Haskell Research Compiler

#23

Post by mrkgnao »

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."

GHC is an entire library too. It has parsers, AST datatypes, desugarers, typecheckers for both Haskell and Core, multiple intermediate representation libraries, ... and the actual compiler is "just" an application that uses that library.

An excellent overview: http://www.aosabook.org/en/ghc.html

Re: Intel Haskell Research Compiler

#24

Post by mrkgnao »

smitherfield wrote: post #17
tikhonj wrote: post #13

Earlier quoted context omitted.

Think of this as closer to an optimizing backend for GHC than a completely brand-new compiler. It uses GHC to parse, typecheck and desugar Haskell to an intermediate form called Core and uses that to do its own optimization and code generation. A core design principle of Haskell is that while the whole language has gotten relatively complex thanks to all its language features and extensions, almost everything can be…

Core, C--, LLVM… — how many intermediate languages is it going through?!

Also something called STG.

Re: Intel Haskell Research Compiler

#25

Post by mturmon »

dbcurtis wrote: post #21
amelius wrote: post #2

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

Indeed. Fire and forget. Sad. Some number of years ago I worked in Intel's software labs. It really drove home to me the point that software development is a long attention span activity, and chip development is a short attention span activity. Mixing both at the same company is difficult. A chip design has a short shelf life, and zero field upgradability, so to be successful building chips you drive hard to tape out…

This is a good summary of the situation of software divisions within hardware-dominated enterprises.

There's a lot of patience for building labs and improving physical infrastructure (which is carried from one activity to the next activity), but much less patience for iterative development of non-physical infrastructure. As an experienced software person told me, "they really want something they can kick" to show the point of making an investment.

If the hardware design is dictated by computer modeling, this can be a point of overlap, in which everyone can agree that patient investment in software is a competitive advantage.

Re: Intel Haskell Research Compiler

#26

Post by dllthomas »

pdpi wrote: post #9
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.

Not just parsing - also type checking. And it means free support for all the various GHC language extensions that only change what Core is generated.

Re: Intel Haskell Research Compiler

#28

Post by tikhonj »

jl6 wrote: post #22
tikhonj wrote: post #13

Earlier quoted context omitted.

Think of this as closer to an optimizing backend for GHC than a completely brand-new compiler. It uses GHC to parse, typecheck and desugar Haskell to an intermediate form called Core and uses that to do its own optimization and code generation. A core design principle of Haskell is that while the whole language has gotten relatively complex thanks to all its language features and extensions, almost everything can be…

Is there any chance they might miss an opportunity for optimisation by throwing out the sugar, thereby discarding information about the prgrammer's intent? Or does the sugar carry no such information?

There is, but it's pretty low because language extensions are designed with Core in mind and the desugaring tends to be relatively straightforward. In most cases, the semantics of the "sugar" is defined in terms of a simpler subset of the language, so there is very little the compiler could do differently.

More importantly, any modern compiler is very far from the producing the most optimal possible programs. Overall performance could be improved pretty much anywhere, and the tradeoffs involved make operating on the "whole" language a far lower priority than pretty much anything else.

Re: Intel Haskell Research Compiler

#29

Post by DigitalJack »

dbcurtis wrote: post #21
amelius wrote: post #2

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

Indeed. Fire and forget. Sad. Some number of years ago I worked in Intel's software labs. It really drove home to me the point that software development is a long attention span activity, and chip development is a short attention span activity. Mixing both at the same company is difficult. A chip design has a short shelf life, and zero field upgradability, so to be successful building chips you drive hard to tape out…

The chips I build are in the field for decades. Compare that to the JavaScript flavor of the hour. Seems more like ADD.

Common Lisp is about the only software I would consider declaring long attention span.

The fixed nature of a chip requires far more attention than something you can push an update to.

"Ship it and fix it later" was pioneered by the software industry. That is the essence of short attention span, unconcern about details.

Maybe we mean different things by that.

Re: Intel Haskell Research Compiler

#30

Post by kazinator »

DigitalJack wrote: post #29
dbcurtis wrote: post #21

Earlier quoted context omitted.

Indeed. Fire and forget. Sad. Some number of years ago I worked in Intel's software labs. It really drove home to me the point that software development is a long attention span activity, and chip development is a short attention span activity. Mixing both at the same company is difficult. A chip design has a short shelf life, and zero field upgradability, so to be successful building chips you drive hard to tape out…

The chips I build are in the field for decades. Compare that to the JavaScript flavor of the hour. Seems more like ADD. Common Lisp is about the only software I would consider declaring long attention span. The fixed nature of a chip requires far more attention than something you can push an update to. "Ship it and fix it later" was pioneered by the software industry. That is the essence of short attention span, unco…

Chips can be socketed for easy removal. Of course, it's more costly to issue thousands or millions of new chips compared to a software patch, but "oh shit" fixing is possible.

The act of actually swapping a chip is easier for the end user than software patching. Open the case, pull this out, put this in its place, done.

Not to mention that it can be reverted. Something wrong? Pop the old one back in. Not always possible with software updates; that has to be designed in.

Less can go wrong. You're not going to half-install a chip, leaving everything corrupt with no way to revert. Unless you damage the old and new.

You can always swap in a good chip from a spare donor device. Doesn't always work that way with software. There may be no easy access to get to the piece you need in the donor device. The device which needs it could be so bricked that you can't run the procedure to put it in.

Overall, I'd say that in the area of aftermarket patching, hardware basically wins.

:)

Post reply on HN