
Making GHC an order of magnitude faster with one neat trick - bollu
https://pixel-druid.com/blog/making-ghc-an-order-of-magnitude-faster-with-one-neat-trick/
======
minitech
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.

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

~~~
Y_Y
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.

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

~~~
gravypod
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?

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

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

~~~
stochastic_monk
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.

~~~
flamedoge
C std says int has to be at least 16 bits.
[http://en.cppreference.com/w/cpp/language/types](http://en.cppreference.com/w/cpp/language/types)

~~~
stochastic_monk
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.

