GHC: Policy on -O flags?
klebinger.andreas at gmx.at
Tue Aug 27 16:10:30 UTC 2019
Hello ghc-devs and haskell users.
I'm looking for opinions on when an optimization should be enabled by
-O is currently the base line for an optimized build.
-O2 adds around 10-20% compile time for a few % (around 2% if I remember
correctly) in performance for most things.
The question is now if I implement a new optimization, making code R%
faster but slowing
down the compiler down by C% at which point should an optimization be:
* Enabled by default (-O)
* Enabled only at -O2
* Disabled by default
Cheap always beneficial things make sense for -O
Expensive optimizations which add little make sense for -O2
But where exactly is the line here?
How much compile time is runtime worth?
If something slows down the compiler by 1%/2%/5%
and speeds up code by 0.5%/1%/2% which combinations make sense
for -O, -O2?
Can there even be a good policy with the -O/-O2 split?
Personally I generally want code to either:
* Typecheck/Run at all (-O0, -fno-code, repl)
* Not blow through all my RAM when adding a few Ints while developing: -O ?
* Make a reasonable tradeoff between runtime/compiletime: -O ?
* Give me all you got: -O2 (-O99999)
The use case for -O0 is rather clear, so is -O2.
But what do people consider the use case for -O
What trade offs seem acceptable to you as a user of GHC?
Is it ok for -O to become slower for faster runtimes? How much slower?
Should all new improvements which might slow down compilation
be pushed to -O2?
Or does an ideal solution add new flags?
Tell me what do you think.
More information about the ghc-devs