Closed amedeedaboville closed 4 years ago
Thanks for the fix; not many people are using fixed-line experiments so this is helpful from a usability standpoint.
It would be great to have support for speedup ranges. For now I think it should choose randomly using the existing setup, but I see your issue (#146) related to this topic. I'll need to think it over before I can give a definite answer. It's important that speedup amounts include data for zero speedup even if its not in the specified range, since that establishes the baseline.
Hi, thanks for making coz!
I've been using it a bit on toy programs, with coz-rs.
This PR: I think the run should fail if we don't find the fixed line we're told to experiment on. Do you agree?
Also, I'd like to write+submit PRs for these, what do you think of these ergonomic improvements?
--fixed-line
is not found, show which line numbers in that source file are loaded in thememory_map
.I have this locally and it has helped me a lot because often with Rust (and maybe its closures or all the macro usage), not all lines end up showing up. Knowing which lines are accessible helps a lot.
--fixed-line
parametersFor example, one might want to compare several different locations in a program at once, instead of in separate runs.
A natural ergonomic follow-up:
--fixed-speedup 40-100
or--fixed-speedup 0-30
This might be useful because in many programs you don't really expect to speedup most functions by more than 40%, so it might speed up runs by needing to collect less data / instead collecting more data to get more accuracy on the range you care about.
An even further solution might even allow passing an extra step value (eg
--fixed-speedup 0-40:2
= 0 to 40 by steps of 2) if someone wants control over the granularity of the speedups.Let me know what you think and I'll get to submitting them! I might also drop a couple other small PRs for papercuts I've encountered so far.