Costing instructions leads to efficiency metrics, which makes it possible to incentivize efficiency.
BPF instructions could also each have an abstract relative cost with or without real value.
BPF in WASM (unfortunately without the kernel performance advantages or possible side channels) or the fwiu now-defunct eWASM might be an easier place to test the value of costed opcodes.
The [e]BPF verifier does not yet rewrite according to opcode costs of candidate programs.
Comments
So… eBPF is now BPF and old BPF is now cBPF or classic bpf.
And there's wasm-bpf: https://github.com/eunomia-bpf/wasm-bpf#how-it-works
But should (browser) WASM processes cross the kernel boundary for BPF performance?
FWIW EVM/eWASM opcodes have a cost in gas/particles.
Do you think that BPF opcodes should be costed, too? Why or why not?
Are you... asking yourself? What did you decide?
Costing instructions leads to efficiency metrics, which makes it possible to incentivize efficiency.
BPF instructions could also each have an abstract relative cost with or without real value.
BPF in WASM (unfortunately without the kernel performance advantages or possible side channels) or the fwiu now-defunct eWASM might be an easier place to test the value of costed opcodes.
The [e]BPF verifier does not yet rewrite according to opcode costs of candidate programs.
"A look inside the BPF verifier [lwn]" https://news.ycombinator.com/item?id=41135478