design
design copied to clipboard
ewasm
Determine Gas Price for opcodes
At some point we need to update the fee schedule with accurate gas prices. One way to do this would be to do is to see how many cycle each equivalent opcode takes on physical hardware.
Appendix C of Architecture Optimization Manual (http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html) where cycles are called latency.
Per pp. C-2:
Latency — The number of clock cycles that are required for the execution core to complete the execution of all of the μops that form an instruction.
Throughput — The number of clock cycles required to wait before the issue ports are free to accept the same instruction again. For many instructions, the throughput of an instruction can be significantly less than its latency.
There is a draft available here: https://gist.github.com/axic/5bf506728005864461454dd4d37a7f37
For what it's worth, as wasm is designed as a portable language, some virtual wasm instructions might be available as a single instruction on some archs and as a sequence of instructions on different archs. The biggest example I can think about right now is: all the int64 instructions. On 64-bits platforms (like intel x64, aarch64), they almost all map to a single assembly instruction, although on 32-bits platforms (like x86/ARM) they map to sequence of equivalent instructions.
I don't know what are the targeted archs for the ewasm VM, but worth noting in case you'd have wanted to support x86 and all. Possible alternatives I can think of, instead of a static arch-independent pricing:
- arch-dependent pricing, but it sounds like metering should be hardware independent in general.
- determine arch-dependent pricing for each platform, and then take an average of them (really, using any average function) to determine an arch-independent pricing. This seems a bit unfair to platforms that are not benchmarked first, but this should at least give a rought idea of what the pricing should look like.
Thank you @bnjbvr. I am afraid we cannot introduce architecture dependent pricing at all.
Regarding state operations. Here is some is the Approximate timing for disk reads compared to instuctions. http://norvig.com/21-days.html#answers
See https://github.com/ewasm/design/blob/master/determining_wasm_gas_costs.md.
