4l0n50
commented
3 hours ago I'm getting the benchmarks using this branch. I'm running the trace_decoder tests and (in not-so-elegant way) collecting and printing the data.
Open 4l0n50 opened 3 hours ago
4l0n50
commented
3 hours ago I'm getting the benchmarks using this branch. I'm running the trace_decoder tests and (in not-so-elegant way) collecting and printing the data.
After running block
20240052batching 50 transactions, in the first segment of size 2^{22}, we observe that the memory table is by far the longest. It contains approximately 14M rows, followed by the CPU with ~4M and Keccak with ~0.5M, as shown in the table.90% of the memory usage comes from the
CodeandStacksegments, contributing ~50% and ~40% of the rows, respectively. Notably, ~4M of the memory in theCodesegment is due to the CPU reading the next opcode during execution. The remaining ~3M rows arise primarily from reading the code and RLP-encoded tries for hashing, as detailed in the following table, which disaggregates memory rows by(Segment, Operation)pairs.(showing 3855698 rows, which represents ~90% from a total of 4194304)
The
(0, Some(KeccakGeneral))operations represent memory reads for hashing the RLP-encoded tries, kernel code, and other hashes.Refactor proposal
The proposed idea is twofold:
Stackmemory operations.We will do so for different opcodes based on their frequencies, as shown in the table below:
PUSHThe primary purpose of a
PUSHoperation is to provide a value for a subsequent opcode. Typically, this corresponds to one of the "consuming" opcodes in the table, such asBinaryArithmetic(Add),Jumpi,MloadGeneral,Jump, etc. SincePUSHarguments are constants known at compile time, a straightforward optimization involves introducing new constant-specific opcodes, such asBinaryArithmetic(AddConst(const_addend)),JumpiConst(const_jumpdest), orMloadGeneralConst(const_addr). This approach would also reduce stack manipulation opcodes likeSWAPandDUPby handling constants directly.DUP(0), DUP(1), DUP(2)We could potentially eliminate many
DUPoperations by introducing "non-consuming" variants of consuming opcodes. The need forDUParises because most opcodes consume one or two topmost stack elements, and some values may need to be used multiple times.SWAP(0), SWAP(1), SWAP(2)andWithout
DUPoperations, the remaining "pure" stack manipulation opcodes would beSWAP(0), SWAP(1), SWAP(2). These don't directly interact with memory but modify stack element addresses. An optimization could involve introducing a new opcodeSWAP(i, j)_XXXfor small values ofi, j, whereXXXis a frequently used opcode following aSWAP. The idea is forSWAP(i, j)_XXXto executeXXXusing inputs offset byiandjfrom the stack top (e.g.,XXXwould becomeSWAP(0,1)_XXX).JumpandJumpiMost jump destinations are known at compile time. Frequently, we observe calls like
%jump(dest)with a constantdestorJUMPoperations where the return destination is a statically-known-value at the stack top. Additionally, all opcodes essentially incorporate aJUMPtopc+1. This could be generalized into opcodes of the formJUMP(b, dest)_XXX, where (b \in {0, 1}) and the jump destination is (b \cdot (pc + 1) + (1-b) \cdot \text{dest}). For example,XXXwould correspond toJUMP(1, 0)_XXX.Next steps
This note analyzes the performance of a few transactions in block
20240052. The next steps would involve extending this analysis to other blocks to validate or disprove the observations. Additionally, a preliminary optimization approach forPush,Dup,Swap, andJumpoperations is presented, which collectively account for ~80% of executed opcodes and ~60% ofStackmemory operations.If these optimizations lead to a ~50% reduction in CPU cycles and
Stackmemory operations, overall memory usage could decrease by approximately 50%. However, these ideas remain preliminary and may be either incorrect or suboptimal. Further exploration is needed to refine or identify better strategies.