-
-
Notifications
You must be signed in to change notification settings - Fork 15k
Benchmark entirely unfair locks for parallel rustc #92596
Copy link
Copy link
Open
Labels
A-parallel-compilerArea: parallel compilerArea: parallel compilerC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.E-help-wantedCall for participation: Help is requested to fix this issue.Call for participation: Help is requested to fix this issue.I-compiletimeIssue: Problems and improvements with respect to compile times.Issue: Problems and improvements with respect to compile times.
Description
Metadata
Metadata
Assignees
Labels
A-parallel-compilerArea: parallel compilerArea: parallel compilerC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.E-help-wantedCall for participation: Help is requested to fix this issue.Call for participation: Help is requested to fix this issue.I-compiletimeIssue: Problems and improvements with respect to compile times.Issue: Problems and improvements with respect to compile times.
Type
Fields
Give feedbackNo fields configured for issues without a type.
My theory is that the accounting necessary for implementing eventually fair locks in parking lot causes an instruction count increase for parallel rusrc by a couple of percents without improving the wall time. Without this accounting taking a lock should be a matter of a cmpxchg and possibly a futex wait if it was already locked. I don't think it matters as much if a thread is starved for extended periods of time rather than splitting this starving between threads as eventually the thread responsible for the starving will finish it's task and no longer cause any other threads to starve, thus guaranteeing progress. Whether I am right or not will need to be shown using benchmarking. It would also be interesting to see how long a spinlock should happen before falling back to a futex wait, if it should happen at all given that some query locks are probably held for extended periods of time.