This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 05 Dec, 2016 1 commit
  2. 01 Dec, 2016 5 commits
  3. 30 Nov, 2016 2 commits
    • Mikhail Glushenkov's avatar
      Merge pull request #4131 from grayjay/goal-order · 2d26af4b
      Mikhail Glushenkov authored
      Solver: Avoid removing goal choices from the tree when applying heuristics.
      2d26af4b
    • kristenk's avatar
      Solver: Add missing call to 'simplifyVar'. · adc1fe96
      kristenk authored
      'simplifyVar' removes flag names from the 'Var' type, so that all flags within a
      package are treated as one during backjumping. A more complete fix would involve
      creating a 'SimpleVar' type.
      
      The bug caused the conflict counting heuristic to never prefer flag goals. Flag
      variables in the tree's goals had the flags' original names, and the flag
      variables in the conflict map did not have names, so they could never be equal.
      
      Since this fix changes the goal order, I wanted to test for an unexpected large
      negative impact on solver runtime. I ran the solver on all packages on Hackage
      individually with GHC 8.0.1 and looked for differences of more than 10% between
      master and the branch. There were twelve packages. I reran those packages three
      times and found ten with a significant difference in runtime. Here are the
      average runtimes. None of them hit the backjump limit.
      
      package                         master (seconds)   branch (seconds)   ratio
      clash-ghc                        2.60              3.99               1.54
      hack-middleware-clientsession    8.22              2.54               0.31
      hackage-server                   1.46              1.85               1.26
      hamusic                          5.47              4.55               0.83
      haskore-synthesizer             10.13              7.64               0.75
      language-gcl                     2.54              2.03               0.80
      ms                              36.98              8.02               0.22
      pipes-cereal-plus                1.51              1.66               1.10
      thorn                            8.28              3.08               0.37
      wai-handler-devel                1.72              1.91               1.11
      
      I looked at the diff in the -v3 log for several of them and saw that the solver
      was making some flag choices earlier, as expected.
      
      This isn't much of an improvement, but it at least looks like a safe change.
      adc1fe96
  4. 29 Nov, 2016 5 commits
    • Edward Z. Yang's avatar
      f664b764
    • Mikhail Glushenkov's avatar
      Merge pull request #4143 from juhp/master · 7613f78b
      Mikhail Glushenkov authored
      bootstrap.sh: do not use -j on ghc-7.8
      7613f78b
    • kristenk's avatar
      Only prefer goals with 0 or 1 active choices when --reorder-goals is specified. · 4b318f57
      kristenk authored
      --reorder-goals previously also preferred goals with two choices, but that had
      the effect of preferring all flags, which can have at most two choices.
      4b318f57
    • kristenk's avatar
      Solver: Avoid removing goal choices from the tree when applying heuristics. · 3b8cdbcb
      kristenk authored
      Previously, the solver applied goal-ordering heuristics by removing all
      non-preferred goal choices when there was at least one preferred choice. This
      left fewer goals for later steps, such as conflict counting, to work with.
      
      This commit changes the heuristics so that they only sort the goals. I didn't
      change the preferBaseGoalChoice heuristic, though, because it made the solver
      slower in some cases. I also think that it is safe to always choose the version
      of base first, because there is usually only one choice anyway.
      
      I reversed the order of the heuristics, because sorting gives the most weight to
      the last step, and pruning gives the most weight to the first step. The solver's
      behavior should be unchanged with --no-count-conflicts.
      
      Some notes on how I tested it:
      
      I expected this change to improve performance in many cases by giving the
      "conflict counting" heuristic more goals to choose from. However, I wasn't able
      to find any cases where the solver made different choices compared with master,
      except when I also used --reorder-goals. I spent a while looking, because it was
      hard to believe.
      
      I searched for examples first by comparing the verbose logs from this branch and
      master for a few packages with many dependencies. Then I compared runtimes with
      master when solving for each package on Hackage (with GHC 8.0.1), in order to
      find packages with very large differences in runtime. Surprisingly, I didn't see
      any where the change was over 50% in either direction. I reran ~10 with the
      biggest difference and found two where the difference was more than noise. I
      compared their logs, but they were also unchanged. Both were slower than master.
      I profiled solving for grapefruit-ui-gtk, which was the slowest (18% slower than
      master, with a runtime of ~20 seconds). I found that this branch spent about
      twice as much time in Explore.getBestGoal. That makes sense, because getBestGoal
      now has more goals to choose from. I didn't look into why the change had such a
      big impact on that particular package.
      
      I also tried running the solver on grapefruit-ui-gtk with --reorder-goals and no
      backjump limit. This branch finished in about 67 seconds, and I stopped master
      after ~8 minutes.
      
      Then I compared runtime for another long-running combination of packages to test
      the overhead of this change when the solver makes the same choices as master. I
      ran 'cabal install --dry-run yesod phooey --max-backjumps -1' with GHC 8.0.1 and
      took the average of 4 runs. master ran for 8.44 seconds, and this branch ran for
      8.50 seconds, which is a difference of less than 1%.
      
      Even though this change doesn't improve performance now, I think it's worthwhile
      for simplifying the interactions between goal-ordering heuristics, and working
      towards issue #3488 (Solver: Combine goal-ordering heuristics more effectively
      by assigning scores to goal choices).
      3b8cdbcb
    • Jens Petersen's avatar
      bootstrap.sh: do not use -j on ghc-7.8 · 40287a99
      Jens Petersen authored
      Cabal-1.18 in ghc-7.8 does not support -j
      40287a99
  5. 28 Nov, 2016 1 commit
  6. 27 Nov, 2016 26 commits