-
Notifications
You must be signed in to change notification settings - Fork 841
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
Benchmarks are run in parallel #3663
Labels
Milestone
Comments
mgsloan
added a commit
that referenced
this issue
Dec 17, 2017
Also generally cleans up code related to parallel execution of tasks. Instead of locking happening among "final tasks" (tests and benchmark running), it's now possible to mark some tasks as work that shouldn't be done in parallel with anything else. This is what makes sense for benchmark running - they shouldn't be run concurrently with either building or running tests. Previously benchmarks and tests shared the same final task. The mechanism to execute one task exclusively is part of Control.Concurrent.Execute. If they were kept in the same task, then if any benchmarks were enabled, then tests would be run without any concurrency. In order to have as much concurrency as possible, they are now split into two different "final" tasks.
mgsloan
added a commit
that referenced
this issue
Dec 17, 2017
Also generally cleans up code related to parallel execution of tasks. Instead of locking happening among "final tasks" (tests and benchmark running), it's now possible to mark some tasks as work that shouldn't be done in parallel with anything else. This is what makes sense for benchmark running - they shouldn't be run concurrently with either building or running tests. Previously benchmarks and tests shared the same final task. The mechanism to execute one task exclusively is part of Control.Concurrent.Execute. If they were kept in the same task, then if any benchmarks were enabled, then tests would be run without any concurrency. In order to have as much concurrency as possible, they are now split into two different "final" tasks.
2 tasks
mgsloan
added
awaiting pull request
need confirmation
type: bug
and removed
awaiting pull request
labels
Dec 17, 2017
mgsloan
added a commit
that referenced
this issue
Dec 18, 2017
Also generally cleans up code related to parallel execution of tasks. Instead of locking happening among "final tasks" (tests and benchmark running), it's now possible to mark some tasks as work that shouldn't be done in parallel with anything else. This is what makes sense for benchmark running - they shouldn't be run concurrently with either building or running tests. Previously benchmarks and tests shared the same final task. The mechanism to execute one task exclusively is part of Control.Concurrent.Execute. If they were kept in the same task, then if any benchmarks were enabled, then tests would be run without any concurrency. In order to have as much concurrency as possible, they are now split into two different "final" tasks.
mgsloan
added a commit
that referenced
this issue
Dec 23, 2017
Also generally cleans up code related to parallel execution of tasks. Instead of locking happening among "final tasks" (tests and benchmark running), it's now possible to mark some tasks as work that shouldn't be done in parallel with anything else. This is what makes sense for benchmark running - they shouldn't be run concurrently with either building or running tests. Previously benchmarks and tests shared the same final task. The mechanism to execute one task exclusively is part of Control.Concurrent.Execute. If they were kept in the same task, then if any benchmarks were enabled, then tests would be run without any concurrency. In order to have as much concurrency as possible, they are now split into two different "final" tasks.
mgsloan
added a commit
that referenced
this issue
Dec 23, 2017
Also generally cleans up code related to parallel execution of tasks. Instead of locking happening among "final tasks" (tests and benchmark running), it's now possible to mark some tasks as work that shouldn't be done in parallel with anything else. This is what makes sense for benchmark running - they shouldn't be run concurrently with either building or running tests. Previously benchmarks and tests shared the same final task. The mechanism to execute one task exclusively is part of Control.Concurrent.Execute. If they were kept in the same task, then if any benchmarks were enabled, then tests would be run without any concurrency. In order to have as much concurrency as possible, they are now split into two different "final" tasks.
mgsloan
added a commit
that referenced
this issue
Dec 24, 2017
…sks-3663 Never run benchmarks concurrently, always output to console #3663
Looks like this was resolved by #3666. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
General summary/comments (optional)
This seems to be a regression (#1913)
Steps to reproduce
Expected
That stack runs the benchmarks in sequence.
Actual
Stack runs the benchmarks in parallel.
Stack version
Method of installation
The text was updated successfully, but these errors were encountered: