8000 Improve `src/comp` build time · Issue #22 · B-Lang-org/bsc · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Improve src/comp build time #22

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.

Sign up for GitHub

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

Jump to bottom
Open
picnoir opened this issue Feb 6, 2020 · 4 comments
Open

Improve src/comp build time #22

picnoir opened this issue Feb 6, 2020 · 4 comments
Labels
build This is an issue with building the tools

Comments

@picnoir
Copy link
picnoir commented Feb 6, 2020

Building src/comp takes about 20 minutes on my beefy machine.

This long build time is mostly due to the fact GHC builds the whole 229 targets in a single core, hence not leveraging parallel nature of modern CPUs.

One way to improve this situation would be to divide this massive 229 targets package into several smaller independent libs, allowing a potential Haskell-specific build tool (cabal? stack?) to parallelize a bit more the overall build.

The solution to this will mostly depend on the build system you're (ie. ppl working full-time on this) envisioning.

Do you plan to keep this makefile + bare ghc custom build system or move to a Haskell-specific build tool for the Haskell bits?
@christiaanb
Copy link

ghc takes a -j flag for building modules on parallel threads, e.g. -j4 to build on 4 threads. No need for Haskell-specific build tools if you want to explore compile parallelism.

@picnoir
Copy link
Author
picnoir commented Feb 6, 2020 •
edited
Loading

@christiaanb The GHC build paralelization won't necessarily lead to a linear build time improvement, see https://gitlab.haskell.org/ghc/ghc/issues/9221

[edit] but you're right, that's another improvement lead, it does not seem to be used ATM.
[edit2] this lib split could also probably be done with the current MakeFile-based approach.

@bpfoley
Copy link
Collaborator
bpfoley commented Feb 6, 2020

@NinjaTrappeur, it's true that ghc --make -jN won't lead to linear speedups, but in practice it does make comp build substantially faster. I tried -j6 (because I've a 6 core machine) and at times it did sustain 600% CPU usage.

@flokli flokli mentioned this issue Feb 8, 2020
Closed
@bpfoley
Copy link
Collaborator
bpfoley commented Apr 2, 2020 •
edited
Loading

Another note on this: GHC 8.10.1 has some substantial compile-time performance improvements in pattern matching exhaustiveness checking, and this speeds up the compilation time of a few of our slowest compiler modules quite a bit, which should help reduce the "long tail" and improve overall parallelism.

@bpfoley bpfoley added the build This is an issue with building the tools label Apr 2, 2020
@quark17 quark17 mentioned this issue Jan 10, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
build This is an issue with building the tools
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@christiaanb @picnoir @bpfoley
0