[LLVMdev] RFC:LNT Improvements

Tobias Grosser tobias at grosser.es
Wed Apr 30 02:50:32 PDT 2014


On 30/04/2014 11:37, Renato Golin wrote:
> On 30 April 2014 10:21, Tobias Grosser <tobias at grosser.es> wrote:
>> To my understanding, the first patches should just improve LNT to report how
>> reliable the results are it reports. So there is no way that this can effect
>> the test suite runs, which means I do not see why we would want to delay
>> such changes.
>>
>> In fact, if we have a good idea which kernels are reliable and which ones
>> are not, we can probably use this information to actually mark benchmarks
>> that are known to be noisy.
>
> Right, yes, that'd be a good first step. I just wanted to make sure
> that we don't just assume 10 runs is ok for everyone and consider it
> done.

Right.

>> Reporting numbers that are not 100% reliable makes the results useless as
>> well. As ARM boards are cheap, you could just put 5 boxes in place and we
>> get the samples we need. Even if this is not yet feasible, I would rather
>> run 5 samples of the benchmarks you really care, then running everything
>> once and getting unreliable number.
>
> That'd be another source of noise. You can't consider 5 boards'
> results to be the same as 5 results in 1 board.
>
> They're cheap (as in quality) and different boards (of the same brand
> and batch) have different manufacturing defects that are only exposed
> when we crush them to death with compiler tests and benchmarks. Nobody
> in the factory has ever tested for that, since they only expect you to
> run light stuff like media players, web servers, routers.

I see the point. There are ways around this e.g. by running different 
benchmarks on different boards, but what it boils down to is that we 
first need to reliably measure and report the quality of the results.
Only then we can judge the effects of changes that are aimed to increase 
the quality.

>> Let me rephrase. "Machines on which you would like to run benchmarks should
>> have a consistent and low enough level of noise"
>
> No 32-bit ARM machine I have tested so far fits that bill.
>
>
>> So do you think the benchmark.sh script proposed by Yi Kong is useful for
>> ARM?
>
> I'm also sceptical about that. I don't think that the noise on setup
> will be any better or worse than noise during tests.
>
> The only way to be sure is to run it every time and to understand the
> curve, find a cut and warn on every noise level above the cut. Mind
> you, this cut will be dynamic as the number of results grow, but once
> we have a few dozen runs, it should stabilise.
>
> But that is not a replacement for running the test multiple times or
> for longer times. We need statistical significance.

Agreed.

My proposal is to do this right ahead. As there is enough data from the 
public X86 -O3 runs (10 samples each run, with 3-5 commits between each 
run), the only missing piece seems to be the LNT changes to report on
the statistical significance. Yi Kong started to hack on this already
and might be able to adjust his changes. Let's wait for his opinion.

Cheers,
Tobias



More information about the llvm-dev mailing list