Additional arithmetic EVM opcode benchmarks #10916
Conversation
|
It looks like @vkomenda signed our Contributor License Agreement. 👍 Many thanks, Parity Technologies CLA Bot |
| }); | ||
| } | ||
|
|
||
| /// Compute mulmod(U256::MAX, U256::MAX, 1) 1000 times. |
There was a problem hiding this comment.
What's the point of having a loop in the bytecode with different number of iterations, just to make sure it scales linearly? IMHO we should be benchmarking a single operation and criterion can take care of running it in a loop. It would make sense to have a loop if we were using a JIT compiler, but we're not.
There was a problem hiding this comment.
Without a loop in the smart contract you get significant noise from loading the contract. You are right, different numbers of iterations are to check that scaling is linear.
ordian
added
A8-looksgood 🦄
There was a problem hiding this comment.
To avoid raw bytecode duplication it might be worth to use a macro instead to generate those cases.
And long term - it would be really awesome to produce the bytecode from some mnemonic based ASM (most likely a macro again) - the current code is really unchangeable.
* master: journaldb changes (#10929) Allow default block parameter to be blockHash (#10932) Enable sealing when engine is ready (#10938) Fix some warnings and typos. (#10941) Updated security@parity.io key (#10939) Change the return type of step_inner function. (#10940) get rid of hidden mutability of Spec (#10904) simplify BlockReward::reward implementation (#10906) Kaspersky AV whitelisting (#10919) additional arithmetic EVM opcode benchmarks (#10916) [Cargo.lock] cargo update -p crossbeam-epoch (#10921) Fixes incorrect comment. (#10913) Add file path to disk map write/read warnings (#10911)
These benchmarks apply to demanding arithmetic operations, in particular to
MULMOD. A helper functionrun_codewas added in order to keep the benchmark code succinct.