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.
Is this where someone points out the more functional intermediate SSA that imperative languages often get translated into at some point during the compilation?
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.
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.
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.)
"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).
16 comments
[ 3.6 ms ] story [ 55.2 ms ] threadI'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.
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.
""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"
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-mean...
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).