Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

optimize mload instruction to not allocate a temporary vector #4

Closed

Conversation

matklad
Copy link

@matklad matklad commented Feb 9, 2022

Naked-eye based optimization -- it feels suboptimal to allocate a Vec
to fetch [0; u32]. Running uniswap bench in aurora shows that this is
an 1% improvement in wasm cost, so the compiler probably can't eliminate
this vec entirely.

@matklad
Copy link
Author

matklad commented Feb 9, 2022

@birchmd not sure what's the right workflow here to land the changes.

@@ -96,6 +96,23 @@ impl Memory {
ret
}

/// Get `H256` from a specific offset in memory.
pub fn get_h265(&self, offset: usize) -> H256 {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

get_h256

pub fn get_h265(&self, offset: usize) -> H256 {
let mut ret = [0; 32];

#[allow(clippy::needless_range_loop)]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could better do smth like

pub fn get_h256(&self, offset: usize) -> H256 {
		if offset + 32 < self.data.len() {
			H256(self.data.as_slice()[offset..offset + 32] as [u8;32])
		} else {
			H256::from_slice(&self.get(index, 32));
		}
	}

@birchmd
Copy link
Member

birchmd commented Feb 9, 2022

what's the right workflow here to land the changes.

This looks like a pretty simple change, should be easy to get it reviewed and merged if we make a PR against the upstream https://github.com/rust-blockchain/evm
Once that is merged we can update our fork's master branch to be at parity with upstream again.

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.
@matklad
Copy link
Author

matklad commented Feb 10, 2022

submitted upstream rust-ethereum#97

@birchmd
Copy link
Member

birchmd commented Feb 11, 2022

@matklad can we close this since it is superseded by #7?

@matklad matklad closed this Feb 11, 2022
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants