3 ms·

Haskell Primitives

72 points by LukeHoersten 12y ago

wyager 12y ago
Cool article! Very in-depth.
LukeHoersten 12y ago
This is one of my favorite innards-of-Haskell articles. It's such an intuitive way to look at how a super high level language like Haskell gets down to machine primitives. So important for optimization too. I've been in HFT for a while and what strikes me is the performance optimizations you make in C++, Java, and Haskell are actually so so similar. Get down to the primitives. Avoid boxing. Avoid memory allocation at run time. Makes me think any language can be performant if you know what you're doing.
- zura 12y ago
  Exactly. And optimized Haskell doesn't quite look to "that beautiful FP language" anymore, but becomes more imperative.
  - Dewie 12y ago
    Is this where someone points out the more functional intermediate SSA that imperative languages often get translated into at some point during the compilation?
  - deleted 12y ago
    [deleted]
  - LukeHoersten 12y ago
    I was thinking more stream fusion and rewrite rules etc. GHC is a lot more powerful in that sense than the other language compilers I mentioned. A lot of it in Haskell just boils down to bang patterns on data types. And where it does get messy as you suggest (yeah it does), you can nicely abstract it away behind a pure library interface. That way the mess is encapsulated.
  - codygman 12y ago
    You know how people use Python for most of their code and write c bindings for performance intensive parts? Idiomatic Haskell for most of my code and imperative Haskell for performance achieves something similar without having to switch languages. If you really need C, Haskell also makes it pretty easy as well.
FullyFunctional 12y ago
Why this intentional misleading title?
- chowells 12y ago
  What's misleading? It's an article about primitive operations and types in GHC Haskell.
  - tome 12y ago
    The actual title is "Primitive Haskell" which certainly confused me when I first saw it (some weeks ago).
LukeHoersten 12y ago
SPJ, co-author of GHC, added this awesome comment: ""Look at the implementation of other functions in GHC.Prim;they're all defined as let x = x in x." This begs the question of why this strange code exists at all. Answer: the sole reason is to give Haddock documentation for the primops a place to live. GHC.Prim is processed by Haddock more or less like any other module; but is effectively ignored by GHC itself. Worth saying this. Simon"
- tome 12y ago
  I never understood why these weren't primop = let x = x in x (+#) = primop or something else at least somewhat meaningful.
  - pash 12y ago
    I don't know the answer to that, but I suspect it might be because there is some reason for the code in GHC.Prim to be monomorphic. There is a Stack Overflow discussion about this that gives a bit more background, by the way. (The answer needlessly digressing into the lambda calculus is mine.) 0. http://stackoverflow.com/questions/15893524/what-is-the-meaning-of-let-x-x-in-x-and-data-float-in-ghc-prim-in-haskell http://stackoverflow.com/questions/15893524/what-is-the-mean...
fspeech 12y ago
Since Haskell is lazy, how does packaging io into a chain of function calls guarantee ordering? Does it depend on some primitives being strict?
- tome 12y ago
  There's an internal representation which ensure than IO actions are evaluated in the correct order.
jpt4 12y ago
"When GHC reaches a call to one of these primops, it automatically replaces it with the real implementation for you, which will be some assembly code, LLVM code, or something similar." This, plus the "magic hashes" reminds me a great deal of Urbit's hinting syntax for jet propulsion (associating a body of high-level code in Hoon with an alternative (presumably low-level) implementation).

72 points by LukeHoersten 12y ago

Cool article! Very in-depth.

This is one of my favorite innards-of-Haskell articles. It's such an intuitive way to look at how a super high level language like Haskell gets down to machine primitives. So important for optimization too. I've been in HFT for a while and what strikes me is the performance optimizations you make in C++, Java, and Haskell are actually so so similar. Get down to the primitives. Avoid boxing. Avoid memory allocation at run time. Makes me think any language can be performant if you know what you're doing.

zura 12y ago
Exactly. And optimized Haskell doesn't quite look to "that beautiful FP language" anymore, but becomes more imperative.
- Dewie 12y ago
  Is this where someone points out the more functional intermediate SSA that imperative languages often get translated into at some point during the compilation?
- deleted 12y ago
  [deleted]
- LukeHoersten 12y ago
  I was thinking more stream fusion and rewrite rules etc. GHC is a lot more powerful in that sense than the other language compilers I mentioned. A lot of it in Haskell just boils down to bang patterns on data types. And where it does get messy as you suggest (yeah it does), you can nicely abstract it away behind a pure library interface. That way the mess is encapsulated.
- codygman 12y ago
  You know how people use Python for most of their code and write c bindings for performance intensive parts? Idiomatic Haskell for most of my code and imperative Haskell for performance achieves something similar without having to switch languages. If you really need C, Haskell also makes it pretty easy as well.

FullyFunctional 12y ago

Why this intentional misleading title?

chowells 12y ago
What's misleading? It's an article about primitive operations and types in GHC Haskell.
- tome 12y ago
  The actual title is "Primitive Haskell" which certainly confused me when I first saw it (some weeks ago).

LukeHoersten 12y ago

SPJ, co-author of GHC, added this awesome comment: ""Look at the implementation of other functions in GHC.Prim;they're all defined as let x = x in x." This begs the question of why this strange code exists at all. Answer: the sole reason is to give Haddock documentation for the primops a place to live. GHC.Prim is processed by Haddock more or less like any other module; but is effectively ignored by GHC itself. Worth saying this. Simon"

tome 12y ago
I never understood why these weren't primop = let x = x in x (+#) = primop or something else at least somewhat meaningful.
- pash 12y ago
  I don't know the answer to that, but I suspect it might be because there is some reason for the code in GHC.Prim to be monomorphic. There is a Stack Overflow discussion about this that gives a bit more background, by the way. (The answer needlessly digressing into the lambda calculus is mine.) 0. http://stackoverflow.com/questions/15893524/what-is-the-meaning-of-let-x-x-in-x-and-data-float-in-ghc-prim-in-haskell http://stackoverflow.com/questions/15893524/what-is-the-mean...

fspeech 12y ago

Since Haskell is lazy, how does packaging io into a chain of function calls guarantee ordering? Does it depend on some primitives being strict?

tome 12y ago
There's an internal representation which ensure than IO actions are evaluated in the correct order.

jpt4 12y ago

"When GHC reaches a call to one of these primops, it automatically replaces it with the real implementation for you, which will be some assembly code, LLVM code, or something similar." This, plus the "magic hashes" reminds me a great deal of Urbit's hinting syntax for jet propulsion (associating a body of high-level code in Hoon with an alternative (presumably low-level) implementation).