Vary default RTS settings so that performance does not degrade with increasing number of capabilities
When the number of capabilities increases to 32 or more, which is common nowadays, performance of GHC-compiled applications, hence also of GHC itself, begins to degrade considerably with default RTS settings.
It should not be required to optimize RTS settings manually to get applications to be usable. By default, GHC should use at least sane RTS settings appropriate for the number of capabilities, even if not optimized.
See:
https://www.reddit.com/r/haskell/comments/83e6dq/need_advice_on_compile_and_runtime_options_for/
for some of the RTS settings you need to change to get things working.
Here is a sample use case - we needed to increase memory by a lot to work around #14928 (closed). We don't care about extra cores, but we get them automatically when we enlarge our EC2 instance to have enough memory. The compile is run by deployment engineers - non-Haskell-programmers - via build tools that normally do not give easy access to RTS options on the individual ghc commands that run during the build (yesod keter in this case). We just want the build to run no worse than if there were 4 cores, or even 1 core.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |