Greetings
Currently GHC supports two kinds of threads - pinned to a specific
capability (bound threads) and those it can migrate between any
capabilities (unbound threads). For purposes of achieving lower latency in
Haskell applications it would be nice to have something in between -
threads GHC
Ok, I filed a ticket for the inlining issue as well -
https://ghc.haskell.org/trac/ghc/ticket/14211. The reproduction test case
is in the same repo on the "inlining-issue" branch, here -
https://github.com/harendra-kumar/ghc-perf/tree/inlining-issue .
Performance with manually inlining a function
I could pinpoint one part of the problem. Please see the ticket:
https://ghc.haskell.org/trac/ghc/ticket/14208. Here is the description that
I wrote in the ticket:
In this particular case -O2 is 2x slower than -O0 and -O0 is 2x slower than
runghc. Please see the github repo:
The code is at: https://github.com/harendra-kumar/asyncly. The benchmark
code is in "benchmark/Main.hs". The relevant function is "asyncly_basic".
If you want to run it, you can use the following steps to reproduce the
behavior I reported below:
1) Run "stack build"
2) Run "stack runghc
Do you have the code?
On Sat, Sep 9, 2017 at 6:05 AM, Harendra Kumar wrote:
> While trying to come up with a minimal example I discovered one more
> puzzling thing. runghc is fastest, ghc is slower, ghc with optimization is
> slowest. This is completely reverse of the