Open wanderer opened 8 years ago
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:
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
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.