-
Notifications
You must be signed in to change notification settings - Fork 53
Keep states ordered by quality in CKF #929
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
Keep states ordered by quality in CKF #929
Conversation
To-do list:
Tagging @paradajzblond, @beomki-yeo, @niermann999, @asalzburger as interested parties. |
3dd7fe8
to
f5c1115
Compare
This is now ready for review. |
f5c1115
to
c83e7ab
Compare
Performance summaryHere is a summary of the performance effects of this PR: GraphicalTabular
Important All metrics in this report are given as reciprocal throughput, not as wallclock runtime. Note This is an automated message produced on the explicit request of a human being. |
Nice, we're back to SYCL crashing on our code:
|
c83e7ab
to
7c2d503
Compare
Okay, the problem has been resolved. 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
ae6c786
to
15e5731
Compare
Performance summaryHere is a summary of the performance effects of this PR: GraphicalTabular
Important All metrics in this report are given as reciprocal throughput, not as wallclock runtime. Warning At least one kernel incurred a significant performance regression. Note This is an automated message produced on the explicit request of a human being. |
Performance impact is expected due to the fact that we produce more high-quality tracks which require more fitting. Also the performance will improve when we reduce the branching factor. |
This commit allows the `find_tracks` kernel in the CKF to keep the best measurements instead of keeping random ones, which will hopefully allow us to significantly reduce the branching factor of the CKF. The logic here works by employing a series of mutexes, allowing threads to lock a critical section and insert their own measurement, overwriting the previous ones.
15e5731
to
c12cbc4
Compare
|
I'm very confused. I don't see any difference between the efficiency plots. |
This commit makes the track finding code more precisely respect the per-seed branching factor limit, which was accidentally loosened in pull request acts-project#929.
This commit makes the track finding code more precisely respect the per-seed branching factor limit, which was accidentally loosened in pull request acts-project#929.
Following acts-project#929, we can now reduce the branching factor without incurring a decrease in physics performance. This commit drops the branching dramatically from 10 to 2.
Following acts-project#929, we can now reduce the branching factor without incurring a decrease in physics performance. This commit drops the branching dramatically from 10 to 2.
This commit makes the track finding code more precisely respect the per-seed branching factor limit, which was accidentally loosened in pull request acts-project#929.
This commit makes the track finding code more precisely respect the per-seed branching factor limit, which was accidentally loosened in pull request acts-project#929.
This commit makes the track finding code more precisely respect the per-seed branching factor limit, which was accidentally loosened in pull request acts-project#929.
This commit makes the track finding code more precisely respect the per-seed branching factor limit, which was accidentally loosened in pull request acts-project#929.
This commit makes the track finding code more precisely respect the per-seed branching factor limit, which was accidentally loosened in pull request acts-project#929.
Following acts-project#929, we can now reduce the branching factor without incurring a decrease in physics performance. This commit drops the branching dramatically from 10 to 2.
Following acts-project#929, we can now reduce the branching factor without incurring a decrease in physics performance. This commit drops the branching dramatically from 10 to 2.
Following acts-project#929, we can now reduce the branching factor without incurring a decrease in physics performance. This commit drops the branching dramatically from 10 to 2.
Following acts-project#929, we can now reduce the branching factor without incurring a decrease in physics performance. This commit drops the branching dramatically from 10 to 2.
Following acts-project#929, we can now reduce the branching factor without incurring a decrease in physics performance. This commit drops the branching dramatically from 10 to 2.
Following acts-project#929, we can now reduce the branching factor without incurring a decrease in physics performance. This commit drops the branching dramatically from 10 to 2.
This commit allows the
find_tracks
kernel in the CKF to keep the best measurements instead of keeping random ones, which will hopefully allow us to significantly reduce the branching factor of the CKF. The logic here works by employing a series of mutexes, allowing threads to lock a critical section and insert their own measurement, overwriting the previous ones.