ci: Build packages (and modules) in parallel #1360

langston-barrett · 2025-03-28T15:41:10Z

Consider the following snippet from the Crux-LLVM CI build:

crucible/.github/workflows/crux-llvm-build.yml

Lines 124 to 137 in 2744ee5

    
                 - shell: bash 
        
                   run: | 
        
                     .github/ci.sh build lib:crucible 
        
                     .github/ci.sh build lib:crucible-syntax 
        
                     .github/ci.sh build pkg:crucible-cli 
        
                     .github/ci.sh build exe:crucible-debug 
        
                     .github/ci.sh build lib:crucible-llvm 
        
                     .github/ci.sh build lib:crucible-llvm-syntax 
        
                     .github/ci.sh build pkg:crucible-llvm-cli 
        
                     .github/ci.sh build exe:crucible-llvm-debug 
        
                     .github/ci.sh build exe:crux-llvm 
        
                     .github/ci.sh build exe:crux-llvm-for-ide 
        
                     .github/ci.sh build exe:crux-llvm-svcomp 
        
                     .github/ci.sh build exe:uc-crux-llvm

This is suboptimal for two reasons:

We are manually maintaining some kind of topological sort of the dependency DAG of our packages. Cabal already knows which things depend on which other things, we should use that knowledge.
We are not taking full advantage of build parallelism.

We could fix both of these by invoking cabal build just once, with all of our packages on the command line.

On (2): We may be building modules in parallel (I'm not sure if Cabal does this by default), but we're certainly not building packages in parallel, as we're not passing --jobs to Cabal, and the default is --jobs=1. We could even use --semaphore so that Cabal and GHC coordinate their use of parallelism for maximally fast builds.

Of course, parallelism begets nondeterminism, but parallel compiler invocations are fairly standard practice and shouldn't be too problematic. The trade-off for build speed is likely worth it.

The text was updated successfully, but these errors were encountered:

RyanGlScott · 2025-03-28T16:10:36Z

We may be building modules in parallel (I'm not sure if Cabal does this by default)

We do not build modules in parallel. This is something that is only done if you enable --semaphore explicitly (only supported in GHC 9.8 or later).

but we're certainly not building packages in parallel, as we're not passing --jobs to Cabal, and the default is --jobs=1.

I don't think this is quite right, as searching through the CI logs reveals that we are building packages in parallel. (See, for instance, this log.) The explanation behind this is that while --jobs' default value is 1, in practice cabal will create a default ~/.config/cabal/config file that has the following line:

jobs: $ncpus

I suppose it couldn't hurt to explicitly pass -j to cabal configure to make this more explicit.

(See also haskell/cabal#5776.)

We could even use --semaphore so that Cabal and GHC coordinate their use of parallelism for maximally fast builds.

This sounds interesting, but with the caveat that we'd have to selectively enable this on GHC 9.8 or later.

langston-barrett · 2025-03-28T16:19:43Z

I don't think this is quite right

Thank you for the explanation! I find that Cabal behavior surprising, so perhaps it would be good to either add a comment or to explicitly add --jobs.

This sounds interesting, but with the caveat that we'd have to selectively enable this on GHC 9.8 or later.

Right, this would depend on the completion of #1308.

langston-barrett self-assigned this Mar 28, 2025

langston-barrett mentioned this issue Mar 28, 2025

ci: Make use of parallelism, and don't retry builds #1362

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ci: Build packages (and modules) in parallel #1360

ci: Build packages (and modules) in parallel #1360

ci: Build packages (and modules) in parallel #1360

ci: Build packages (and modules) in parallel #1360

Comments