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
Staged builtin rules #799
base: master
Are you sure you want to change the base?
Staged builtin rules #799
Conversation
I have further restricted the outer stage to be limited to The improvement in sigma-ide is around 20% for the edit benchmark |
I suggest just commenting out the docs test while playing around. It's not very interesting for correctness. It's an interesting idea, and I'll take a proper look tomorrow. |
I found the issue that was causing the ghcide benchmarks to hang: asyncrhonous exceptions. Raised basvandijk/concurrent-extra#20 and worked around it by defining |
The ghcide branch at https://github.com/pepeiborra/ide/tree/staged-shake-rules runs Shake rules in place when the dependencies have not changed and we have a previous result at hand.
|
The RLock implementation in concurrent-extra is broken basvandijk/concurrent-extra#20
It is possible to return Now for rules that do not have a second stage
66bd390
to
8fdbcfd
Compare
One problem with this change is that we run the stage 1 with |
I have pushed a more efficient reentrant lock - the previous version had significant contention overheads. |
This is an alternative solution to #751 implementing a no fork solution. Shake cannot possibly know whether a built-in rule is trivial or not, but the rule itself does!
This change exposes a richer type for
BuiltinRun
so that rule creators can decide whether to execute in-place or fork the work. The ability to run in place is only available when therunChanged
isChangedNothing
, but this is a bit arbitrary and can be changed.For example, in https://github.com/pepeiborra/ide/tree/staged-shake-rules we run Shake rules in place when the dependencies have not changed and we have a previous result at hand.
To make this work, I had to change the
Lock
implementation to allow for reentrancy.This is mostly a RFC in order to get your thoughts. Is this safe? Can
Action
computations deadlock when executed in-place?I will follow up with some numbers and tests soon