GHC Threads affinity

2017-09-09 Thread Michael Baikov
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

Re: Performance degradation when factoring out common code

2017-09-09 Thread Harendra Kumar
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

Re: Performance degradation when factoring out common code

2017-09-09 Thread Harendra Kumar
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: ​

Re: Performance degradation when factoring out common code

2017-09-09 Thread Harendra Kumar
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

Re: Performance degradation when factoring out common code

2017-09-09 Thread Matthew Pickering
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