Making GHC an order of magnitude faster with one neat trick | Hacker News Reader

Making GHC an order of magnitude faster with one neat trick

pixel-druid.com

59 pointsbollu18 comments

The title is “Making GHC an order of magnitude faster with one neat trick” but the post is a draft and the part with the neat trick (or anything to do with making GHC faster) doesn’t exist yet.

The graphs don't render for me, even with a fresh profile or a different browser. There's also a TODO left in the post.

Nor did they appear for me in Firefox 59. I've gotten into the habit of ignoring things that don't load since I assume they're blocked for a good reason by my browser.

Can confirm, Chrome stable / Firefox stable on Windows 10.

Irrespective of any other elements of this post, it’s factually incorrect in one important way: GHC does not have an O3 optimization level. On for any n>2 is treated as O2. Likewise not all O2 optimization’s are always a win vs O1 :)

Disclosure: I help out a teeny itsy bit with ghc on occasion.

> Disclosure

That's a "Source", not a "Disclosure". There's no conflict of interest in explaining the internals of an open-source project while being involved in an open-source project.

A disclaimer is only necessary when you have a hidden agenda.

i'm biased :), thats a disclosure. :)

How do you tell which optimization level is better for your program other than just running both? Shouldn't one expect that the higher optimization level would push more performance?

Does GHC have a -Ofast?

For arbitrary programs, the only way to determine performance is to measure measure measure. Anything else requires having a perfect model of the running system and the hardware and environment. Which is best replicated by measuring the actual performance.

Certain libraries , such as any doing fusion based optimization, do generally benefit from O2. But at the end of the day measure measure measure.

I’m not familiar with Ofast. I’ll look it up. Looked it up, nope ghc doesn’t have anything like that, and there’s a few parts I hope to help mature in ghc before it’s safe/sane to even consider the analogue of fast math flags and standards breaking optimization. Especially since changing the meaning of programs via optimization flags would be pretty dangerous for a language like Haskell.

There’s def room for other compilation/semantic models to do aggressive optimization in different ways. But not for Haskell today :)

> Shouldn't one expect that the higher optimization level would push more performance?

But we don't always understand how optimisations and code generation techniques will perform in practice, without running it. Ideally we'd have a more formal understanding of the performance of real processors, but we don't.

Your optimisation could generate fewer instructions, but change some cache behaviour, for example. Or use instructions that are faster, but use different registers that changes register pressure and slows things down elsewhere.

The same can be said for gcc - basically, optimization heuristics are sometimes incorrect.

Yeah, infact I remember seeing Cabal warn when O2 is put.

Isn't Haskell's "Int" an arbitrary-sized integer, while C's "int" is... like, whatever the compiler makes of it, typically a 32 or 64 bit int?

With the ackermann function, it's not obvious that the compiler can proof a lack of overflow, and optimize out the bigint-ness.

Since I can't see the graphs, I don't know what input ranges the author used, and thus can't tell if the C version even gave the correct answer.

> Isn't Haskell's "Int" an arbitrary-sized integer

That’s "Integer". "Int" is fixed-size.

No, Haskell's Int is a machine integer; if you want a bigint, you use Integer rather than Int.

At least so far, int in C compilers on 32/64 bit architectures has always been 32 bits. It’s not good practice, but I’ve seen plenty of code assuming int/unsigned are 32 bits.

C std says int has to be at least 16 bits. http://en.cppreference.com/w/cpp/language/types

Oh, absolutely. Like I said, it's bad practice, and that's because it's not guaranteed by the standard. I'm just saying it's done.

Reply on news.ycombinator.com