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

Haskell Primitives

fpcomplete.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Haskell Primitives

#11

Post by Dewie »

zura wrote: post #10
LukeHoersten wrote: post #3

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…

Exactly. And optimized Haskell doesn't quite look to "that beautiful FP language" anymore, but becomes more imperative.

Is this where someone points out the more functional intermediate SSA that imperative languages often get translated into at some point during the compilation?

Re: Haskell Primitives

#12

Post by [deleted] »

zura wrote: post #10
LukeHoersten wrote: post #3

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…

Exactly. And optimized Haskell doesn't quite look to "that beautiful FP language" anymore, but becomes more imperative.

[deleted]

Re: Haskell Primitives

#14

Post by LukeHoersten »

zura wrote: post #10
LukeHoersten wrote: post #3

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…

Exactly. And optimized Haskell doesn't quite look to "that beautiful FP language" anymore, but becomes more imperative.

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.

Re: Haskell Primitives

#15

Post by jpt4 »

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

Re: Haskell Primitives

#16

Post by tome »

fspeech wrote: post #13

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

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

Re: Haskell Primitives

#17

Post by codygman »

zura wrote: post #10
LukeHoersten wrote: post #3

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…

Exactly. And optimized Haskell doesn't quite look to "that beautiful FP language" anymore, but becomes more imperative.

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.

Post reply on HN