Optimising Haskell for a tight inner loop | Hacker News Reader

Optimising Haskell for a tight inner loop

neilmitchell.blogspot.co.uk

78 pointsluu24 comments

Ironically, the C++ code he's attempting to match itself uses a higher-level language[1] to generate a soup of tables and gotos[2]. But I think that observation supports the point he'd likely make: Haskell allows both the higher-level expressions of problems that produce optimization opportunities while preserving the option of dropping down to low-level trickiness if that's what you really need.

[1] https://github.com/martine/ninja/blob/master/src/lexer.in.cc...

[2] https://github.com/martine/ninja/blob/master/src/lexer.cc#L1...

I may take this blog post and turn it into a bug report for the ghc optimizer. :-)

The moment you start trying to compete against hand written assembly, any high level lang gets a bit quirky. One nice thing about ghc Haskell is you can though! A lot of my own open source work is towards a vision of making that much easier than it is today :-)

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

> 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 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 :)

anyways, heres a link to the reddit thread: http://www.reddit.com/r/haskell/comments/1ukwu1/optimising_h...

its a very thoughtful, informative, thread. enjoy!

Note that since all of the characters in question are less than 64, you could also do a bit test between (1 << x) and a 64-bit mask, simplifying the control flow; I'm not sure whether this would actually be faster, assuming the post is correct that other characters that happen to be <= '$' are rare in practice, but you could then load several bytes at a time into some SSE registers and do the test in parallel, probably netting a substantial speedup at the cost of becoming architecture dependent.

By break0, it looks like we're just writing Haskell-ified C. (Lots of ugly, similar safety guarantees.)

Indeed. Many of the high-performance libraries like bytestring, aeson, etc. are written like this.

Haskell's performance is very good for nearly everything I write--and I don't write anything nearly that low level--but I can't deny that this is one of the uglier sides of the language.

On the other hand: In most other languages you'd just be dropping down to the C ABI (that's easy to do in Haskell, too, for that matter.) It is kind of impressive that you can write code that is as fast as C without writing C, even if it is ugly.

> It is kind of impressive that you can write code that is as fast as C without writing C, even if it is ugly.

Impressive, perhaps -- but from a maintainability perspective I think I might prefer to pay the cost of jumping the language barrier to be able to write natural, comprehensible C rather than staying within one language and dealing with an unreadable jumble, even if it performs as well.

The final Haskell code, while being low-level, is not unreadable jumble. Maybe you're talking about the generated Core or the C-- code.

I disagree wholeheartedly on the similar safety guarantees part, Haskell still provides you with a significant amount over C in this case. But it does "look" more like it, if that means anything.

The difference is that with Haskell you can wrap a nice, clean, type-safe interface around all that ugly optimization. With C, you're still dealing with casts, null pointer checks, array bounds checks and all sorts of other tedious bug sources that Haskell users don't have to deal with -- unless there's a library bug, of course.

I wonder how a table lookup compares? Something like

     mov edx, @table
     xor eax, eax
    loop:
     mov al, [ecx]
     inc ecx
     cmp byte [edx+eax], 0
     jnz loop

I really wish Intel would optimise lodsb, scasb, and the rest of the string instructions, since they're powerful and particularly suited for this sort of scanning.

I think it's more likely that they'll eventually re-purpose these opcodes (further ISA extensions), and string operations will be optimized through simple hardware matching of documented instruction sequences. Already today, Intel's optimization manual gives SSE-optimized string search routines, which consume 16 bytes at a time.

Removing and re-purposing instructions is not unprecedented; it has already been done at 32->64 jump. (Prefixes, decimal instructions, etc.)

I doubt those instructions (especially stos* and movs*, respectively matching memset and memcpy) are going anywhere. Intel has even changed their semantics in recent chips to work on 16-byte or larger chunks, and to have out-of-order memory accesses. Current MOVSB, for instance, should be nearly as fast as SSE/AVX optimized memory transfers.

I wouldn't say their semantics have changed but certainly their implementation. The fact that Intel used to recommend against using them but now advises the opposite, suggests that scas/cmps (memchr/memset) could be next. In any case, the thought of one machine instruction doing better than lots of carefully hand-written assembly is nice.

I know its not necessarily avoidable in practice due to legacy reasons, but my main takeaway from this is that Haskell is not for high performance code.

Reply on news.ycombinator.com