frame/benchmarking: baseline weights independent of complexity params

[ggwpez]

The baseline benchmarks addition, subtraction, multiplication and division all ignore their complexity parameter and have a constant weight.
The benchmarks should be fixed to either not accept a parameter or have a weight that depends on it.

[dharjeezy]

Hello @ggwpez I am interested in picking this issue up.
I understand when you say the benchmark should not accept a parameter, that means we should remove the i parameter since it's not being used yh?

But I don't understand what you mean by "should have a weight that depends on it"?

[ggwpez]

Hello @ggwpez I am interested in picking this issue up.

Wow nice @dharjeezy !

I understand when you say the benchmark should not accept a parameter, that means we should remove the i parameter since it's not being used yh?

Yes it could just be removed and run with a constant repetition, eg 1_000_000.

But I don't understand what you mean by "should have a weight that depends on it"?

That would just be an alternative approach; instead of removing it you could also fix it so that the weight output uses the i parameter. It currently looks like this:

fn addition(_i: u32, ) -> Weight {
	(284_000 as Weight)
}

but could look more like this:

fn addition(i: u32, ) -> Weight {
	(1_000 as Weight)
		.saturating_add((10_000 as Weight).saturating_mul(i as Weight))
}

IMHO it would be the best to just remove the parameter, makes it simpler to use and understand.
Thinking again: The second approach would guarantee that the compiler does not optimize out the operation. Would be difficult to otherwise verify this.
I talked about it with @shawntabrizi and I think he has no preference which approach to use.
So it would be up to you @dharjeezy which way to go.

[shawntabrizi]

The benchmarks should be fixed to either not accept a parameter or have a weight that depends on it.

I dont think it is clear that we can "force the benchmark" to use the i parameter. The i parameter not being used is a result of the benchmarking results undergoing linear regression, and the regression not finding any noticeable slope.

But yeah, in any case, it is not actually that important what precisely we are benchmarking, just that the benchmarks are universally consistent, as to tell when changes to the rust compiler or hardware are making an impact to the timing of the weights.

[ggwpez]

I dont think it is clear that we can "force the benchmark" to use the i parameter. The i parameter not being used is a result of the benchmarking results undergoing linear regression, and the regression not finding any noticeable slope.

We could execute batches of operations, eventually it should show up.
So (0..i * 1000) instead of (0..i).