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

CGC performance improvements #169

Open
shwestrick opened this issue Nov 5, 2022 · 0 comments
Open

CGC performance improvements #169

shwestrick opened this issue Nov 5, 2022 · 0 comments

Comments

@shwestrick
Copy link
Collaborator

I've noticed some performance issues with CGC that I need to write down, so we can investigate+fix later.


CGC scheduling. The current scheduling strategy for CGC is like this: (1) snapshot at fork, (2) do child work, (3) check to see if the CGC was stolen, and if not, then (4) push the continuation and switch to the CGC.

But, this is not great, because it unnecessarily delays the CGC. If we've already committed to the snapshot, it's best to make progress on the snapshot as soon as possible.

A better strategy would be to snapshot, immediately push the continuation, and then switch to the CGC.


CGC chaining. Handling CGC at joins is tricky. To maintain invariants on pointer directions, it's possible to have an uncollected heap in a CGC-chain. (This reason is subtle and difficult to quickly summarize. See case 2 of Fig 4.6 in my thesis for more info.)

However, this might be Very Bad™️, because the uncollected heap might be large (and in need of collection).

I think I've managed to trigger this with a stress test. In parallel-ml-bench, branch em, benchmark tangle sometimes experiences an explosion in memory size with the following command: bin/tangle.mpl-em.bin @mpl procs 72 -- -p-ent 0.99 -warmup 5 -repeat 20 -elem-size 1000000 -num-elems 200 -num-tangles 100. I have not seen the explosion when I use the restriction @mpl max-cc-depth 1 --, which prevents funky CGC joins. A little bit of investigation with @mpl log-level cc-collection:info -- seems to confirm: without the restriction, there are (very ineffective) CGCs happening at depth 3.

One possible fix would be to check the size of the uncollected heap, and trigger a collection on it (if necessary) when it is pushed into the chain at a join. The details might be hairy... need to check snapshot invariants.

@shwestrick shwestrick changed the title CGC improvements CGC performance improvements Nov 5, 2022
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

1 participant