GHC: Policy on -O flags?

Hello ghc-devs and haskell users. I'm looking for opinions on when an optimization should be enabled by default. -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. Cheers, Andreas Klebinger

I think at first you just give it a -f flag, and let experience determine
whether it should be part of -O or -O2.
On Tue, Aug 27, 2019 at 12:10 PM Andreas Klebinger
Hello ghc-devs and haskell users.
I'm looking for opinions on when an optimization should be enabled by default.
-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.
Cheers, Andreas Klebinger
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- brandon s allbery kf8nh allbery.b@gmail.com

`-O2` is not a very rationally considered flag from what I understand.
It only enables `-fspec-constr` and `-fliberate-case`. The later also
triggers another simplification pass.
`-fspec-constr` is quite limited as it only works in the definition
module. I have never trusted it to optimise my code.
I have seen `-fliberate-case` achieve something but more often the
improvement comes from the extra simplification pass.
Therefore I wouldn't try to read the tea leaves too closely. There are
probably flags in `-O` which affect compile time more but have less
benefit.
Matt
On Tue, Aug 27, 2019 at 5:13 PM Brandon Allbery
I think at first you just give it a -f flag, and let experience determine whether it should be part of -O or -O2.
On Tue, Aug 27, 2019 at 12:10 PM Andreas Klebinger
wrote: Hello ghc-devs and haskell users.
I'm looking for opinions on when an optimization should be enabled by default.
-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.
Cheers, Andreas Klebinger
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Hi, I used to think that the policy for being eligible for -O1 is that C must be non-positive, e.g. that the compile times don't suffer at all. Everything beyond that (well, given that R is positive) should be -O2 only. There's precedent at least for Late Lambda Lifting (which is only run for -O2) here: https://phabricator.haskell.org/D5224#147959. Upon re-reading I see that Simon Marlow identified C=1 as the hard threshold. Maybe there are other cases as well? Personally, I like C=0 for the fact that it means the compiler will only get faster over time. And any reasonably tuned release executable will do -O2 anyway. Cheers, Sebastian Am Di., 27. Aug. 2019 um 17:11 Uhr schrieb Andreas Klebinger < klebinger.andreas@gmx.at>:
Hello ghc-devs and haskell users.
I'm looking for opinions on when an optimization should be enabled by default.
-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.
Cheers, Andreas Klebinger
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (4)
-
Andreas Klebinger
-
Brandon Allbery
-
Matthew Pickering
-
Sebastian Graf