switch vm stack to little endian representation #7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Naked-eye based optimization -- it feels suboptimal to allocate a `Vec` to fetch `[0; u32]`. Running a macro-benchmark in aurora shows that this is about a 1% win, so the compiler probably can't eliminate this vec entirely.
H256 is [u8; 32] U256 is [u64; 4] According to EVM spec, when H256 is interpreted as a number, the byte order is big endian. WASM, in contrast, uses little-endian representation (the same used by CPUs internally). Before this PR, evm stored operand stack as `Vec<H256>`, so any arithmetic op entailed indianness conversion. As WASM lacks equivalent to bswap instruction, this is a lot of work. After this PR, stack is using U256 (so, little-endian in memory). This is also reperesentation used by all of geth, evmone and odin. For the uniswap benchmark, the before-after WASM (not total) gas cost is 110436615921984 90540800264244
|
(pushed one more tiny improvement) |
olonho
pushed a commit
to olonho/sputnikvm
that referenced
this pull request
Feb 17, 2022
olonho
pushed a commit
to olonho/sputnikvm
that referenced
this pull request
Feb 17, 2022
birchmd
pushed a commit
that referenced
this pull request
Aug 5, 2022
birchmd
pushed a commit
that referenced
this pull request
Nov 3, 2022
birchmd
pushed a commit
that referenced
this pull request
Nov 25, 2022
vimpunk
pushed a commit
that referenced
this pull request
May 18, 2023
vimpunk
pushed a commit
that referenced
this pull request
May 22, 2023
mrLSD
approved these changes
Jun 9, 2024
aleksuss
added a commit
to aleksuss/sputnikvm
that referenced
this pull request
Jul 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
H256 is [u8; 32]
U256 is [u64; 4]
According to EVM spec, when H256 is interpreted as a number, the byte
order is big endian. WASM, in contrast, uses little-endian
representation (the same used by CPUs internally).
Before this PR, evm stored operand stack as
Vec<H256>, so anyarithmetic op entailed indianness conversion. As WASM lacks equivalent
to bswap instruction, this is a lot of work.
After this PR, stack is using U256 (so, little-endian in memory). This
is also reperesentation used by all of geth, evmone and odin.
For the uniswap benchmark, the before-after WASM (not total) gas cost is
110436615921984
90540800264244
Notes:
pop_u256->pop), such that we only use a suffix for non-standard operation. I didn't do this in the PR to minimize diff.H256andU256are different types makes me so much more confident in this change!