It looks like the author of this (Stephen Diehl) is looking for a job in Boston. Maybe HN can help him out?

https://twitter.com/smdiehl/status/538494839189700608

Huh, I just realized I inherited a JS codebase from him in a previous job. The code was ingenious, perhaps too ingenious to maintain.

He surely must be getting headhunted a lot.

If this guy isn't getting headhunted, I have no idea what headhunting is. It's pretty rare for people to be able to write correct and easy-to-read guides to such low level concepts.

Finding a job is easy, finding the right job is hard for people like this.

Part and parcel of "There are not enough programmers [willing to work long hours for low pay]!"

For that talent, it might even be that the work is too boring regardless of the hours or pay.

Very true. I'm running into that right now: humdrum legacy CRUD apps, where the only challenge lies in being allowed* to refactor the code into decent shape.

*I wish I could put that in sarcastic quotes.

It appears to be twice as long as the old 2.0 version, and a lot of the latest GHC 7.8 topics which wasn't released before the last version.

That's helpful, thanks

There's also a very detailed tutorial on writing a toy compiler with Haskell and LLVM on this site:

http://www.stephendiehl.com/llvm/

> The moment you start trying to compete against hand written assembly, any high level lang gets a bit quirky.

Yes, which is why I wonder why GHC went with it's own code generator instead of using LLVM? It seems like a lot of the outputted assembly would be coalesced with LLVM's optimizer passes. Is there work on this problem within the Haskell world?

GHC has an llvm backend.

If you read the blog post, you'll see Neil mentions " tried the LLVM backend, but it generated significantly worse assembly code https://github.com/ndmitchell/blogs/blob/master/inner-loop/I...

@tenslsi : theres certainly room for improving llvm, the ghc native code gen, and pretty much any compiler generally (ghc is no different). I'm actively involved in GHC dev, and i've somewhat committed to spending some volunteer time this year improving the NCG and various backend optimization tooling.

anyways, the reddit discussion of the blog post is also pretty interesting

> ... tried the LLVM backend, but it generated significantly worse assembly code.

It's worth noting the LLVM version Neil tried was 2.8, from Dec 2010. LLVM has come a long way since then and I'd be surprised to see if produce such horrible code. I'm hoping Neil will do an updated post using LLVM 3.4 released last week.

My understanding is that the main problem is translating from Haskell to LLVM IR is a lossy process, not the difference between LLVM 2.8 and LLVM 3.4. This blog post demonstrates one such issue:

http://blog.omega-prime.co.uk/?p=135

Quote: "In particular, LLVM conservatively assumes that GHC's stack and the heap may alias". LLVM has to assume that short of Haskell-specific analysis, so updating to LLVM 3.4 won't help with such issues.

not quite, I think the issue is that llvm doesn't understand ghc's stack, so which I guess is the same issue :)

> Yes, which is why I wonder why GHC went with it's own code generator instead of using LLVM?

LLVM didn't exist when GHC was started.

It's pretty amazing: The initial release of GHC was in 1989.

Neither did the NCG though, I believe. And the NCG only finally overtook the C backend late in the 6.x cycle (6.8? 6.10?)

GHC's -fllvm flag already makes it use LLVM, although the native code generator remains the default.

This backend (usually coupled with -O2) tends to slow down compile times tremendously, but can make some math-heavy programs much faster.