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.
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.
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.
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.
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?
> 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.
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 :)
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.
19 comments
[ 4.5 ms ] story [ 42.9 ms ] threadWith 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.
That’s "Integer". "Int" is fixed-size.
Disclosure: I help out a teeny itsy bit with ghc on occasion.
Does GHC have a -Ofast?
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.
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 :)
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.