Changes between Initial Version and Version 43 of Ticket #9221


Ignore:
Timestamp:
Nov 1, 2015 12:59:37 PM (23 months ago)
Author:
bgamari
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #9221

    • Property Cc slyfox tibbe gidyn nh2 kolmodin erikd kazu-yamamoto scpmw added
    • Property Related Tickets changed from to #910, #8224
    • Property Milestone changed from to 8.0.1
  • Ticket #9221 – Description

    initial v43  
    1 im seeing slowdowns in parallel builds of a (simple!!) 6 module project when I build it on a 40 core server i'm using for work.  for any given  ghc invocation with -jn, once n>10, i start to see a super linear slow down  as a function of n
     1I'm seeing slowdowns in parallel builds of a (simple!!) 6 module project when I
     2build it on a 40 core server that I'm using for work. For any given ghc invocation
     3with `-jn`, once n>10, I start to see a super-linear slow down as a function of n,
    24
    3 heres some basic numbers
     5here are some basic numbers,
     6
     7||=    =||= compile time =||
     8|| -j1  || 0m2.693s   ||
     9|| -j4  || 0m2.507s   ||
     10|| -j10 || 0m2.763s   ||
     11|| -j25 || 0m12.634s  ||
     12|| -j30 || 0m39.154s  ||
     13|| -j40 || 0m57.511s  ||
     14|| -j60 || 2m21.821s  ||
     15
     16These timings are another 2-4x worse if ghc is invoked indirectly via cabal-install / `Setup.hs`
     17
     18According to the linux utility latencytop, 100% of ghc's cpu time was spent on user-space lock contention when I did the `-j40` invocation.
     19
     20The timing in the `-j40` case stayed the same even when ghc was also passed `-O0` (and `-fforce-recomp` to ensure it did the same )
    421
    522
    6 at -j1 0m2.693s
     23A bit of experimentation makes me believe that *any* cabalized project on a 40 core machine will exhibit this performance issue.
    724
    8 at -j4  0m2.507s
    9 
    10 at -j10  0m2.763s
    11 
    12 at -j25 0m12.634s
    13 
    14 at -j30 :   0m39.154s
    15 
    16 at -j40 : 0m57.511s
    17 
    18 at -j60 : 2m21.821s
    19 
    20 
    21 these timings are another 2-4x worse if ghc is invoked indirectly via cabal-install / setup.hs
    22 
    23 according to the linux utility latencytop, 100% of ghc's cpu time was spent on user-space lock contention when I did the -j40 invocation.
    24 
    25 the timing in the -j40 case stayed the same even when ghc was also passed -O0 (and -fforce-recomp to ensure it did the same )
    26 
    27 
    28 a bit of experimentation makes me believe that in *ANY* cabalized project on a 40 core machine will exhibit this perf issue.
    29 
    30 cabal clean ; cabal configure --ghc-options="-j" ; cabal build -j1
     25{{{
     26cabal clean
     27cabal configure --ghc-options="-j"
     28cabal build -j1
     29}}}
    3130
    3231should be enough to trigger the lock contention.