Serialize Core #2813
Merged
Serialize Core #2813
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wz1000
force-pushed
the
wip/th-core-file-3
branch
from
2d01875
to
89faced
Compare
|
Some benchmarks here: https://well-typed.com/blog/2022/04/hls-performance/ (this is the |
wz1000
force-pushed
the
wip/th-core-file-3
branch
3 times, most recently
from
749c2f8
to
214971e
Compare
pepeiborra
requested changes
Apr 2, 2022
wz1000
force-pushed
the
wip/th-core-file-3
branch
from
212fefc
to
6fa9d7b
Compare
pepeiborra
approved these changes
Apr 6, 2022
wz1000
force-pushed
the
wip/th-core-file-3
branch
14 times, most recently
from
566b90c
to
2141259
Compare
|
I've added the on demand bytecode generation commit to this as well as its a major simplification of the patch, and deletes a bunch of code added by the first commit, along with fixing a few bugs. If required I can split it into multiple PRs but I think it is better to review all the changes at once. See the commit message for a description of the changes. |
wz1000
force-pushed
the
wip/th-core-file-3
branch
4 times, most recently
from
460f287
to
0e60634
Compare
Add a `.hi.core` file format to which we serialize out compiled core after generating it. This core is then read back in on subsequent runs and compiled to bytecode. This greatly speeds up startup times when we need compilation, as we can simply read bytecode off the disk instead of having to recompile a lot of modules This is based off Fat Interface files in GHC: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7502 - Also add --verify-core-file to do roundtrip testing of core-files - Use closed world assumption for core and .hie files
Adds a new rule `GetLinkable` which is called on demand by hscCompileCoreExprHook whenever a linkable is required for a splice. Adds a MonadUnliftIO instance for Action to faciliate the above We write Core Files whenever a linkable could potentially be required for a file (i.e it is in the transitive closure of a module that uses TH/compile time code execution) However, we only generate byte/object code when such a linkable is really required by a splice (i.e. the module is in the transitive closure of any symbol called from a splice). No linkables are stored in `HiFileResult`. If a linkable is required, then it must be obtained via a call to `GetLinkable`. Also use hashes to do fine grained recompilation checking for TH instead of mod times. This simplifies recompilation checking quite a bit.
wz1000
force-pushed
the
wip/th-core-file-3
branch
from
e4421cb
to
5c3b3d6
Compare
pepeiborra
reviewed
Jun 18, 2022
pepeiborra
approved these changes
Jun 19, 2022
| -- | Find the runtime dependencies by looking at the annotations | ||
| -- serialized in the iface | ||
| parseRuntimeDeps :: [ModIfaceAnnotation] -> ModuleEnv UTCTime | ||
| parseRuntimeDeps :: [ModIfaceAnnotation] -> ModuleEnv BS.ByteString |
There was a problem hiding this comment.
This now collects hashes instead of timestamps, right?
Maybe worth an extended comment.
There was a problem hiding this comment.
I've added a line here and also a bit in Note [Recompilation avoidance in the presence of TH]
No, but there could be perf regressions in projects that use TH and unboxed things on GHC <9.2 (which forces us to use object code), as now we have the overhead of serializing the core file in addition to writing out object code. I don't think this is worth any added complexity to fix. For non TH use cases, I don't think any of the new code paths introduced by this patch should be invoked. |
wz1000
force-pushed
the
wip/th-core-file-3
branch
from
eac0234
to
7f0ddcf
Compare
wz1000
force-pushed
the
wip/th-core-file-3
branch
from
7f0ddcf
to
1b88acd
Compare
wz1000
force-pushed
the
wip/th-core-file-3
branch
from
1b88acd
to
0db8920
Compare
|
lsp-types benchmarks from CI show a nice reduction in number of rebuilds: |
|
Is this ultimately going to get into GHC? Or are we going to be on the hook for maintaining this indefinitely? |
Fat interface files are likely to be in GHC 9.6 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Serialize core to core files
Add a
.hi.corefile format to which we serialize out compiled core after generating it.This core is then read back in on subsequent runs and compiled to bytecode.
This greatly speeds up startup times when we need compilation, as we can simply read bytecode
off the disk instead of having to recompile a lot of modules
This is based off Fat Interface files in GHC: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7502