search for: asplos13

...run (unless it is a global regression). > > There are situations where we see commit which make things slower then faster again, but so far those seem to be from experimental features being switched on then off. This is an interesting paper: http://people.cs.umass.edu/~emery/pubs/stabilizer-asplos13.pdf "However, caches and branch predictors make performance dependent on machine-specific parameters and the exact layout of code, stack frames, and heap objects. A single binary constitutes just one sample from the space of program layouts, regardless of the number of runs. Since compiler op...

This is probably another area where a bit of dynamic behavior could help. When we find a regressions, kick off some runs to bisect back to where it manifests. This is what we would be doing manually anyway. We could just search back with the set of regressing benchmarks, meaning the whole suite does not have to be run (unless it is a global regression). There are situations where we see commit

On 30 June 2013 10:14, Anton Korobeynikov <anton at korobeynikov.info> wrote: > 1. Increasing sample size to at least 5-10 > That's not feasible on slower systems. A single data point takes 1 hour on the fastest ARM board I can get (Chromebook). Getting 10 samples at different commits will give you similar accuracy if behaviour doesn't change, and you can rely on 10-point