This will make it so that (on systems with timerfd) the runtime will no longer have to wait for the next runtime tick before exiting. This saves on average 5 ms per program run, and up to 10 ms for programs with a very short runtime. Not much for server programs with an expected lifetime of days/weeks, but potentially quite nice for CLI programs like hledger or for programs that invoke many other Haskell programs.
I accidentally discovered this when trying to optimize an Advent of Code problem and couldn't get it below 10 ms no matter what I tried. Eventually I discovered that "hello world" also took 10 ms so I assumed it was just runtime startup costs. Decided to look anyway and found out it was actually runtime shutdown costs, where the runtime would `join` the rts "ticker" thread. The ticker thread would only check for a shutdown flag once every loop, so 10 ms with the default settings. Now it can be shut down immediately, which makes small programs much faster.
Like you I had assumed this was simply runtime startup / teardown overhead.
lol, not even Haskell can escape YAML being YAML.
Version numbers are always strings with special comparison semantics.
Is GitHub sponsoring Haskell development? Or is this them providing some free services (e.g. more Runners) because it's a large and importans OSS project?
https://github.com/ghc/ghc https://gitlab.haskell.org/ghc/ghc
Don't forget that SPJ had been working for MS for quite some years.
I only see two directly related supporters? IOG and the stake pool?
If you want to be on the cutting edge of releases and ignore packages coordination delays and package maintainers taking some time to respond because they actually have a life, you can move to the nightly. Smaller package sets but closer to GHC releases. If you want someone else to solve dependency hell for you and take the time to upstream that fix, you need to give people some time to do it.
Nightly has more packages than LTS. Currently 3213 (nightly) vs. 3010 (LTS).
