-
Notifications
You must be signed in to change notification settings - Fork 131
Introduce RuntimeSeriesReward #762
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
base: development
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## development #762 +/- ##
================================================
- Coverage 89.28% 55.63% -33.65%
================================================
Files 130 131 +1
Lines 7912 7961 +49
================================================
- Hits 7064 4429 -2635
- Misses 848 3532 +2684
|
Note: needs #761 to land first |
Hi @lqwk, I'm very sorry for my delay in reviewing this. I've not forgotten about it, I just have a backlog of issues to fix on the CI so that I can run the tests against these changes. Cheers, |
Hi @lqwk, okay, I finally pushed through the backlog of issues and have a newly stable v0.2.5 release. Sorry again that it me so long to getting around to this. Are you still working on this? If so, could you please rebase this on top of the Cheers, |
Introduce RuntimeSeriesReward
Introduce a new implementation of comparing program runtimes that computes the reward as the difference of the medians between the current set of runtimes and the previous set of runtimes only if the runtime series are significantly different (determined by the Kruskal–Wallis test).
Source: https://htor.inf.ethz.ch/publications/img/hoefler-scientific-benchmarking.pdf
Testing
I ran a series of tests comparing the new implementation with the existing implementation using the LLVM autotuner on the
cbench-v1
benchmark. The rewards are shown below:The new implementation is on par with the existing implementation, and even beats the existing implementation on 12/17 of the benchmarks.
I am proposing to merge this upstream and we can maybe work on other optimizations such as early stopping.