This folder allows measuring an accurate cost of high-level primitives in terms of basic operations (Field mul, add, inv, ...)
### For optimization
Metering allows choosing the best algorithm or representation when multiple are available, for example choosing elliptic curve coordinates between affine projective or jacobian? Also some might be faster for certain fields (Fp or Fp2) or certain curves.
It also allows to focus tuning operations that underlie the high-level building blocks. This is not a replacement for profiling but a complement.
Metering allows reasoning at the complexity and algorithmic level while profiling allows reasoning at the hardware and timing level.
### For blockchains
Important for blockchain to correctly price the VM opcodes. Pricing too low would allow denial-of-service attacks, too high will disincentivize their use.
Note: this only takes into account the number of operations
but does not take into account stack usage for temporaries.
## Measuring cost
The file m_pairings has a minimal example for the current state.
```Nim
var rng*: RngState
let seed = uint32(getTime().toUnix() and (1'i64 shl 32 - 1)) # unixTime mod 2^32
rng.seed(seed)
echo "bench xoshiro512** seed: ", seed
func random_point*(rng: var RngState, EC: typedesc): EC {.noInit.} =
const flags = if UseASM_X86_64 or UseASM_X86_32: "UseAssembly" else: "NoAssembly"
reportCli(Metrics, flags)
```
After compiling with
```
nim c -r --hints:off --warnings:off --verbosity:0 -d:danger -d:CttMeter --outdir:build metering/m_pairings.nim
```
We get
```
bench xoshiro512** seed: 1611954740
CPU: Intel(R) Core(TM) i9-9980XE CPU @ 3.00GHz
The CPU Cycle Count is indicative only. It cannot be used to compare across systems, works at your CPU nominal frequency and is sensitive to overclocking, throttling and frequency scaling (powersaving and Turbo Boost).
