Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Solver needs around 20000 backjumps to solve for servant-mock-0.8.3 #4976

Closed
phadej opened this issue Dec 26, 2017 · 3 comments
Closed

Solver needs around 20000 backjumps to solve for servant-mock-0.8.3 #4976

phadej opened this issue Dec 26, 2017 · 3 comments

Comments

@phadej
Copy link
Collaborator

phadej commented Dec 26, 2017

With GHC-7.8.4 or GHC-7.10.3 and

--index-state='2017-12-25T17:31:19Z'

This is probably due recently released ansi-terminal-0.8, which is quite early in the dependency-graph:

dependency-graph.pdf with ansi-terminal revdeps highlighted

cc @grayjay you might like to solve this puzzle!

phadej added a commit to haskell-servant/servant-mock that referenced this issue Dec 26, 2017
@grayjay
Copy link
Collaborator

grayjay commented Jan 5, 2018

Does this issue require --enable-tests? I was able to produce a failure by checking out version 0.8.3 of servant-mock and running this command:

cabal new-build --dry-run --index-state='2017-12-25T17:31:19Z' --enable-tests --max-backjumps=20000

I think that the conflict between ansi-wl-pprint and the new version of ansi-terminal is the problem. The solver chooses ansi-terminal first and then chooses ansi-wl-pprint after following a chain of dependencies (servant-server, wai-app-static, optparse-applicative, ansi-wl-pprint). Here is a common pattern from the log:

[181] trying: servant-server-0.12 (dependency of servant-mock)
[182] trying: servant-server:setup.base~>base-4.8.2.0/installed-0d6... (dependency of servant-server)
[183] trying: wai-app-static-3.1.6.1 (dependency of servant-server)
[184] trying: optparse-applicative-0.14.0.0 (dependency of wai-app-static)
[185] next goal: ansi-wl-pprint (dependency of optparse-applicative)
[185] rejecting: ansi-wl-pprint-0.6.8.1 (conflict: ansi-terminal==0.8, ansi-wl-pprint => ansi-terminal>=0.4.0 && <0.8)
[185] rejecting: ansi-wl-pprint-0.6.8, ansi-wl-pprint-0.6.7.3, ansi-wl-pprint-0.6.7.2, ansi-wl-pprint-0.6.7.1, ansi-wl-pprint-0.6.7, ansi-wl-pprint-0.6.6 (conflict: ansi-terminal==0.8, ansi-wl-pprint => ansi-terminal>=0.4.0 && <0.7)
[185] rejecting: ansi-wl-pprint-0.6.4, ansi-wl-pprint-0.6.3, ansi-wl-pprint-0.6.2, ansi-wl-pprint-0.6.1, ansi-wl-pprint-0.5.1, ansi-wl-pprint-0.5.0, ansi-wl-pprint-0.4.0, ansi-wl-pprint-0.3.1, ansi-wl-pprint-0.3.0, ansi-wl-pprint-0.2, ansi-wl-pprint-0.1 (conflict: optparse-applicative => ansi-wl-pprint>=0.6.6 && <0.7)
[185] fail (backjumping, conflict set: ansi-terminal, ansi-wl-pprint, optparse-applicative)

The solver tries many combinations of versions for the four packages but can't resolve the conflict until it backtracks to ansi-terminal.

I started working on #4805 to help with conflicts involving packages that are deep in the dependency graph, so I rebased it onto master and tried it with servant-mock. It finished in about 2.6 seconds, so I think that was the only problem. I'd like to fix the remaining issues with the branch and make a PR, though I'm not sure when I'll have time.

@grayjay grayjay self-assigned this Jan 5, 2018
@phadej
Copy link
Collaborator Author

phadej commented Jan 5, 2018

@grayjay great! yes, IIRC --enable-tests was needed

grayjay added a commit to grayjay/cabal that referenced this issue Feb 25, 2018
I tested this change by comparing performance with both
c01d92f (before any refactoring needed to
implement this change) and 4d28102 (the
previous commit), using hackage-benchmark.  Since the refactoring changed the
meaning of the backjump count, I only timed "install" commands that didn't reach
the backjump limit.  I chose several commands that ran for different amounts of
time, including the long running example from issue haskell#4976.

Comparing c01d92f (cabal1) and this commit (cabal2):

compiler: GHC 8.2.1
index state: 2018-02-16T02:47:32Z
extra hackage-benchmark flags:
--packages="aeson yesod wolf" --pvalue=0.01 --trials=50 --print-skipped-packages

package result1       result2             mean1       mean2     stddev1     stddev2     speedup
aeson   (not significant)
yesod   Solution      Solution           2.270s      2.258s      0.027s      0.031s      1.005
wolf    Solution      Solution           7.337s      7.234s      0.056s      0.047s      1.014

Comparing 4d28102 (cabal1) and this commit (cabal2) with the same environment
and flags as above:

package result1       result2             mean1       mean2     stddev1     stddev2     speedup
aeson   (not significant)
yesod   (not significant)
wolf    Solution      Solution           7.297s      7.245s      0.045s      0.048s      1.007

hackage-benchmark currently doesn't print the results when they aren't
significant, so I reran "cabal install --dry-run aeson", and it ran for about
1.6 seconds and found a solution.

Comparing c01d92f (cabal1) and this commit (cabal2) on issue haskell#4976:

compiler: GHC 7.10.3
extra hackage-benchmark flags:
--cabal1-flags="--index-state='2017-12-25T17:31:19Z' --enable-tests --max-backjumps=-1"
--cabal2-flags="--index-state='2017-12-25T17:31:19Z' --enable-tests --max-backjumps=-1"
--packages=servant-mock --pvalue=0.01 --trials=50 --print-skipped-packages --print-trials

trial/summary    package      result1       result2             mean1       mean2     stddev1     stddev2     speedup
...
summary          servant-mock Solution      Solution          39.693s     38.863s      0.181s      0.174s      1.021

Comparing 4d28102 (cabal1) and this commit (cabal2) on issue haskell#4976 with the
same environment and flags as above:

trial/summary    package      result1       result2             mean1       mean2     stddev1     stddev2     speedup
...
summary          servant-mock Solution      Solution          39.659s     38.960s      0.195s      0.162s      1.018

Overall, this seems like a very small performance improvement.
@grayjay
Copy link
Collaborator

grayjay commented Jan 19, 2020

This issue should be fixed by #5918.

@grayjay grayjay closed this as completed Jan 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants