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

avoid clones when making an Artifact from a Compilation #140

Merged
merged 2 commits into from
Sep 21, 2022

Conversation

Ekleog-NEAR
Copy link
Contributor

@Ekleog-NEAR Ekleog-NEAR commented Sep 21, 2022

Performance characteristics of uncached compilation (not including
preparation) for the wasm blob from near/nearcore-private-1#2:

       | Non-rayon |   Rayon
-------+-----------+-----------
Before | 28.5-29ms | 15-15.5ms
After  | 25-25.5ms |    12ms

Performance characteristics of uncached compilation for the wasm blob from
near/nearcore-private#2:

       | Non-rayon |   Rayon
-------+-----------+-----------
Before | 28.5-29ms | 15-15.5ms
After  | 25-25.5ms |    12ms
Copy link
Collaborator

@nagisa nagisa left a comment

Choose a reason for hiding this comment

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

Seems good to me. Making the fields pub seems okay too, since the Compilation struct doesn't appear to have any invariants per-se.

@Ekleog-NEAR
Copy link
Contributor Author

I’m under the same impression, especially as Compilation seems used at exactly one place right now, ie. where I removed the spurious clones. Landing, then :)

@Ekleog-NEAR Ekleog-NEAR merged commit 54438eb into near:near-main Sep 21, 2022
@matklad
Copy link
Contributor

matklad commented Sep 22, 2022

WDYT about making a release and pulling this work into nearcore, such that we don't accumulate unbatletested stuff in this repo?

@Ekleog-NEAR
Copy link
Contributor Author

I’d be ok with it, but maybe in 1-2 weeks after I complete the work on these things so we don’t spend too much energy making releases?

@matklad
Copy link
Contributor

matklad commented Sep 22, 2022

SGTM, though in the limit we hsould make release process rather lightweright ideally.

@akhi3030
Copy link

@Ekleog-NEAR : I am curious how you determined that this change would result in a performance improvement. Maybe we can discuss it a bit in our next 1-1.

@Ekleog-NEAR
Copy link
Contributor Author

Ekleog-NEAR commented Sep 23, 2022

Might as well write it down here so other people can read it too :)

The steps I followed to identify the opportunity for this PR are:

  1. Have a GCP VM with the setup we recommend validators have
  2. Run the test from nearcore-private-1#2 (with a small diff to only test wasmer2) in --release inside perf (I needed to add debug = true to profile.release)
  3. Load it inside profiler.firefox.com
  4. Look at the trace, identify what looked like bottlenecks (IIRC quite a lot of time was being spent in iterators that deep down ended up cloning stuff)
  5. Open the code, and see that we were indeed cloning lots of stuff that didn’t need to
  6. Make the PR

Then, to measure the exact performance benefits:

  1. On the same GCP VM,
  2. With the following diff on top of nearcore:
diff --git a/runtime/near-vm-runner/src/cache.rs b/runtime/near-vm-runner/src/cache.rs
index f7bd1a49b..6d1f7df5e 100644
--- a/runtime/near-vm-runner/src/cache.rs
+++ b/runtime/near-vm-runner/src/cache.rs
@@ -259,9 +259,14 @@ pub mod wasmer2_cache {
         config: &VMConfig,
     ) -> Result<wasmer_engine_universal::UniversalExecutable, CompilationError> {
         let _span = tracing::debug_span!(target: "vm", "compile_module_wasmer2").entered();
+        let time = std::time::SystemTime::now();
         let prepared_code =
             prepare::prepare_contract(code, config).map_err(CompilationError::PrepareError)?;
-        vm.compile_uncached(&prepared_code)
+        eprintln!("Preparation: {:?}", time.elapsed());
+        let time = std::time::SystemTime::now();
+        let r = vm.compile_uncached(&prepared_code);
+        eprintln!("Uncached compilation: {:?}", time.elapsed());
+        r
     }

     pub(crate) fn compile_and_serialize_wasmer2(
  1. Run a few times before and after the change
  2. Run again a few times before and after the change, but with this diff in addition to exclude rayon:
diff --git a/runtime/near-vm-runner/Cargo.toml b/runtime/near-vm-runner/Cargo.toml
index 44e03bfb2..cd8e653e6 100644
--- a/runtime/near-vm-runner/Cargo.toml
+++ b/runtime/near-vm-runner/Cargo.toml
@@ -54,7 +54,7 @@ wasmer-runtime-core = { version = "0.18.2", package = "wasmer-runtime-core-near"
 #wasmer-types = { package = "wasmer-types-near", version = "=2.4.0", optional = true }
 #wasmer-vm = { package = "wasmer-vm-near", version = "=2.4.0", optional = true }
 wasmer-compiler = { package = "wasmer-compiler-near", path = "../../../wasmer/lib/compiler", optional = true }
-wasmer-compiler-singlepass = { package = "wasmer-compiler-singlepass-near", path = "../../../wasmer/lib/compiler-singlepass", optional = true }
+wasmer-compiler-singlepass = { package = "wasmer-compiler-singlepass-near", path = "../../../wasmer/lib/compiler-singlepass", optional = true, default-features = false, features = ["std"] }
 wasmer-engine = { package = "wasmer-engine-near", path = "../../../wasmer/lib/engine", optional = true }
 wasmer-engine-universal = { package = "wasmer-engine-universal-near", path = "../../../wasmer/lib/engine-universal", features = ["compiler"], optional = true }
 wasmer-types = { package = "wasmer-types-near", path = "../../../wasmer/lib/types", optional = true }

bors bot added a commit to wasmerio/wasmer that referenced this pull request Nov 21, 2022
3290: Limit the use of clone when handling Compilation object r=ptitSeb a=ptitSeb

# Description
Small improvment to limit the number of clone when handling Compilation object.

Based on near/wasmer#140

For #3305 

Co-authored-by: ptitSeb <sebastien.chev@gmail.com>
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.

4 participants