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

Optimize scc as hard as possible #929

Open
treeowl opened this issue Feb 2, 2023 · 3 comments
Open

Optimize scc as hard as possible #929

treeowl opened this issue Feb 2, 2023 · 3 comments

Comments

@treeowl
Copy link
Contributor

treeowl commented Feb 2, 2023

I don't know what can be done here, but GHC uses it, and that makes it a top Data.Graph priority.

@jwaldmann
Copy link
Contributor

The implementation is literally (?) from (e.g.,) Cormen, Leiserson, Rivest: Introduction to Algorithms, Section 23.5 (ninth edition), and O(vertices + edges) is optimal. So this is about the hidden constant factor?

Is there reason to believe that this is critical for GHC? (does scc show up in profiles?)

Does GHC really use Data.Graph? E.g., https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Data/Graph/Directed.hs seems like a copy/re-implementation. But, yes:

import qualified Data.Graph as G
...
scc :: IntGraph -> [SCC Vertex]
scc graph = map decode forest
  where
    forest = {-# SCC "Digraph.scc" #-} G.scc graph
    ...

So, let's look at these profiles...

@treeowl
Copy link
Contributor Author

treeowl commented Feb 2, 2023

Good point.

@meooow25
Copy link
Contributor

meooow25 commented Feb 4, 2023

Yes it would be good to know how much time GHC spends in scc.

If we want to improve it we could implement and see if Tarjan's or path-based algorithm (from Wikipedia: https://en.wikipedia.org/wiki/Strongly_connected_component#Algorithms) have a lower constant factor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants