Estimation functions for fundamental unit helper-costs

[jakmeier]

Inside runtime-params-estimator/src/cost.rs we have one Cost entry for each estimation. Some are for specific runtime parameters. Others do not have such a direct relation but we still want to estimate and track them. Let's call the first group parameter-costs and the second group helper-costs.

This issue is about these specific helper-costs:

• OneCPUInstruction (this is x86, not WasmInstruction)
• OneNanosecond
• IoReadByte and IoWriteByte (Not to be confused with StorageReadByte and friends. IO costs are bytes at physical disk level and storage bytes are at the Wasm runtime layer)

The idea is that they can be used to evaluate the currently used constants in runtime-params-estimator/src/estimator_params.rs on specific hardware. These fundamental constants are used in the gas formula for parameter-costs and helper-costs. Thus, it is crucial that we have accurate values here, or otherwise all estimations are inaccurate.

On a theoretical reference hardware, the new estimations should confirm those constants exactly. Any strong outliers (above or below) on real hardware means that our estimator is not well tuned for that hardware.

Implementation

As of now, I am not 100% sure how to implement these estimation functions. I think all of them will need to execute a larger amount of computation and then divide it to receive an average for the smallest unit. But beyond that, there are several open questions:

• What hardware to use for initial tuning? (Should represent a "typical" node)
• What workload is best used for each of these? (Ideally something stable across hardware architectures)
• Is it sensible to estimate one cost value with a single workload? Or should we even average over several benchmarks for each cost?

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[matklad]

I think we did this for CPU, but maybe not for IO yet.

[jakmeier]

We have a CPU benchmark but not one that measures a single x86 instruction. Potentially we could just divide the existing CPU benchmark by the number of instructions in that benchmark. But before doing that blindly, we need to check if the used instructions are good representatives.