[move-stdlib] Add vector::move_range native function #14863

igor-aptos · 2024-10-03T22:03:42Z

Description

Memcopy (i.e. ptr::copy_nonoverlapping inside of Vec) is extremely efficient, and using Vec operations that use it directly is significantly faster (orders of magnitude on bigger vectors) than issuing operations in move.

Operations on vector that can be speed-up: insert, remove, append, split_off.

To keep amount of native functions short, instead of having native for each of those, providing one more general native function: vector::move_range, which is enough to support all 4 of the above, in addition to other uses.

Internally, we shortcircuit a few special cases, for faster speed.

How Has This Been Tested?

Full performance evaluation is in the follow-up PR: #14862

Key Areas to Review

Type of Change

Performance improvement

Which Components or Systems Does This Change Impact?

Move/Aptos Virtual Machine

Checklist

I have read and followed the CONTRIBUTING doc
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I identified and added all stakeholders and component owners affected by this change as reviewers
I tested both happy and unhappy path of the functionality
I have made corresponding changes to the documentation

trunk-io · 2024-10-03T22:03:46Z

⏱️ 2h 43m total CI duration on this PR

Slowest 15 Jobs	Cumulative Duration	Recent Runs
rust-move-unit-coverage	16m	🟩
rust-move-unit-coverage	16m	🟩
rust-move-unit-coverage	16m	🟩
rust-move-unit-coverage	14m	🟩
rust-move-unit-coverage	12m	🟩
rust-move-unit-coverage	11m	🟩
rust-move-tests	10m	🟩
rust-move-tests	10m	🟩
rust-move-unit-coverage	10m	⬜
rust-move-tests	10m	🟥
rust-move-tests	10m	🟩
rust-move-tests	9m	🟩
rust-cargo-deny	9m	🟩 🟩 🟩 🟩 🟩
check-dynamic-deps	4m	🟩 🟩 🟩 🟩 🟩
general-lints	2m	🟩 🟩 🟩 🟩 🟩

_{settings ⋅ feedback ⋅ docs ⋅ learn more about trunk.io}

codecov · 2024-10-03T22:20:43Z

Codecov Report

Attention: Patch coverage is 75.65217% with 28 lines in your changes missing coverage. Please review.

Project coverage is 60.1%. Comparing base (8b0d35b) to head (b36187b).

Files with missing lines	Patch %	Lines
...party/move/move-vm/types/src/values/values_impl.rs	61.7%	18 Missing ⚠️
...s-move/framework/move-stdlib/src/natives/vector.rs	84.3%	8 Missing ⚠️
...party/move/move-vm/runtime/src/native_functions.rs	88.2%	2 Missing ⚠️

Additional details and impacted files

@@                 Coverage Diff                  @@
##           igor/move_mem_swap   #14863    +/-   ##
====================================================
  Coverage                60.1%    60.1%            
====================================================
  Files                     857      858     +1     
  Lines                  211341   211455   +114     
====================================================
+ Hits                   127147   127233    +86     
- Misses                  84194    84222    +28

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

igor-aptos · 2024-10-21T16:05:43Z

third_party/move/move-vm/types/src/values/values_impl.rs

+        // potentially unnecessary as native call should've checked the types already
+        // (unlike other vector functions that are bytecodes)
+        check_elem_layout(type_param, from_c)?;
+        check_elem_layout(type_param, to_c)?;


one question - given no checks in mem::swap, should I have these checks here?

That's a good question. It has the same indirect guarantees as the from_self != to_self.

igor-aptos · 2024-10-21T16:19:39Z

third_party/move/move-vm/runtime/src/native_functions.rs

+            if module_name.as_str() == "string"
+                && vector_bytecode_instruction_methods.contains(func_name.as_str())
+            {
+                println!("ERROR: Tried to register as native a vector bytecode_instruction method {}, skipping.", func_name.as_str());
+                continue;


not sure if this check is even needed (this is mostly to make sure we don't create new native function with same name as bytecode instruction), or if it's better to remove it - or on the other hand panic here.

but this is basically to be a fixed replacement of the filter in aptos-move/aptos-vm/src/natives.rs

igor-aptos · 2024-10-21T16:20:25Z

third_party/move/move-vm/types/src/values/values_impl.rs

@@ -2307,6 +2307,25 @@ fn check_elem_layout(ty: &Type, v: &Container) -> PartialVMResult<()> {
 }

 impl VectorRef {
+    pub fn len_usize_raw(&self, type_param: &Type) -> PartialVMResult<usize> {


I've added this to not need to wrap / unwrap / cast for getting the length inside of native function.

ziaptos · 2024-10-21T16:30:53Z

aptos-move/framework/move-stdlib/sources/vector.move

+    /// Moves range of elements `[removal_position, removal_position + length)` from vector `from`,
+    /// to vector `to`, inserting them starting at the `insert_position`.
+    /// In the `from` vector, elements after the selected range are moved left to fill the hole
+    /// (i.e. range is removed, while the order of the rest of the elements is kept)
+    /// In the `to` vector, elements after the `insert_position` are moved the the right to make space for new elements
+    /// (i.e. range is inserted, while the order of the rest of the elements is kept)


Let's add that to the comment here.

ziaptos · 2024-10-21T16:32:38Z

aptos-move/framework/move-stdlib/sources/vector.move

+    /// (i.e. range is removed, while the order of the rest of the elements is kept)
+    /// In the `to` vector, elements after the `insert_position` are moved the the right to make space for new elements
+    /// (i.e. range is inserted, while the order of the rest of the elements is kept)
+    native public fun range_move<T>(from: &mut vector<T>, removal_position: u64, length: u64, to: &mut vector<T>, insert_position: u64);


Isn't move_range more intuitive and better descripting name?

now that you say it, makes more sense :D

ziaptos · 2024-10-21T16:36:01Z

aptos-move/framework/move-stdlib/src/natives/vector.rs

+// Copyright (c) The Move Contributors
+// SPDX-License-Identifier: Apache-2.0
+
+//! Implementation of native functions for utf8 strings.


Wrong leftover comment

ziaptos · 2024-10-21T16:39:16Z

aptos-move/framework/move-stdlib/src/natives/vector.rs

+
+use super::mem::get_feature_not_available_error;
+
+/// The generic type supplied to aggregator snapshots is not supported.


Probably some leftover comment from wherever a snipped was copied (aggregator_natives/aggregator_v2.rs?)

ziaptos · 2024-10-21T16:39:41Z

aptos-move/framework/move-stdlib/src/natives/vector.rs

+use super::mem::get_feature_not_available_error;
+
+/// The generic type supplied to aggregator snapshots is not supported.
+pub const EINDEX_OUT_OF_BOUNDS: u64 = 0x03_0001;


How are these constants picked?

there is this utility now - https://github.com/aptos-labs/aptos-core/blob/main/types/src/error.rs

I'll use that, but it might be worth revisiting where to put it, to not require importing whole aptos-types for that.

ziaptos · 2024-10-21T16:41:03Z

aptos-move/framework/move-stdlib/src/natives/vector.rs

+    let removal_position = usize::try_from(safely_pop_arg!(args, u64)).map_err(map_err)?;
+    let from = safely_pop_arg!(args, VectorRef);
+
+    // need to fetch sizes here to charge upfront, and later in move_range, not sure if possible to combine


I can't fully understand this comment without reading the code

ziaptos · 2024-10-21T17:38:28Z

third_party/move/move-vm/types/src/values/values_impl.rs

@@ -2307,6 +2307,25 @@ fn check_elem_layout(ty: &Type, v: &Container) -> PartialVMResult<()> {
 }

 impl VectorRef {
+    pub fn len_usize_raw(&self, type_param: &Type) -> PartialVMResult<usize> {


length_as_usize? Why raw?

sure , as usize sounds good.

raw was meant to mean not as a move value - i.e. not Value::usize (which doesn't exist), but just rust usize

ziaptos · 2024-10-21T17:39:10Z

third_party/move/move-vm/types/src/values/values_impl.rs

+        };
+        Ok(len)
+    }
+
    pub fn len(&self, type_param: &Type) -> PartialVMResult<Value> {
        let c: &Container = self.0.container();
        check_elem_layout(type_param, c)?;


Use the new function here:
Ok(Value::u64(length_as_usize(....))

ziaptos · 2024-10-21T17:54:28Z

third_party/move/move-vm/types/src/values/values_impl.rs

@@ -2452,6 +2471,67 @@ impl VectorRef {
        self.0.mark_dirty();
        Ok(())
    }
+
+    pub fn move_range(


I'd make it static (associated):
this: &Self instead of &self and use it with VectorRef::move_range(....

Also need to either document, or check that self != to_self

VM will guarantee there cannot be two &mut references to same self.

I can still defensively check, but it should never be possible to go there.

The pre-condition for this function is self != to_self (we can just document it, as a comment, and mention that it's enforced by the overall VM design).

ziaptos · 2024-10-21T18:00:15Z

third_party/move/move-vm/runtime/src/native_functions.rs

@@ -81,8 +81,26 @@ impl NativeFunctions {
    where
        I: IntoIterator<Item = (AccountAddress, Identifier, Identifier, NativeFunction)>,
    {
+        let vector_bytecode_instruction_methods = HashSet::from([
+            "empty",


Any reason for adding this check now (in this PR)?

Do we really want to prevent this? There's nothing wrong with having native functions that have the same functionality as instructions.

previous comment:

not sure if this check is even needed (this is mostly to make sure we don't create new native function with same name as bytecode instruction), or if it's better to remove it - or on the other hand panic here.

but this is basically to be a fixed replacement of the filter in aptos-move/aptos-vm/src/natives.rs

I don't think there's a general reason to disallow these in MoveVM. I'd rather keep the filter in AptosVM. Is there any other reason for wanting to remove it from AptosVM?

igor-aptos · 2024-10-21T23:28:36Z

updated PR with addressed comments

ziaptos

More like a question that I have before stamping this.

ziaptos · 2024-10-21T23:59:46Z

third_party/move/move-vm/types/src/values/values_impl.rs

+        // potentially unnecessary as native call should've checked the types already
+        // (unlike other vector functions that are bytecodes)
+        check_elem_layout(type_param, from_c)?;
+        check_elem_layout(type_param, to_c)?;


That's a good question. It has the same indirect guarantees as the from_self != to_self.

ziaptos · 2024-10-22T00:09:42Z

third_party/move/move-vm/runtime/src/native_functions.rs

@@ -81,8 +81,26 @@ impl NativeFunctions {
    where
        I: IntoIterator<Item = (AccountAddress, Identifier, Identifier, NativeFunction)>,
    {
+        let vector_bytecode_instruction_methods = HashSet::from([
+            "empty",


I don't think there's a general reason to disallow these in MoveVM. I'd rather keep the filter in AptosVM. Is there any other reason for wanting to remove it from AptosVM?

igor-aptos · 2024-11-08T23:22:52Z

addressed all comments. move the filtering back to AptosVM. added comment for redundant check

graphite-app · 2024-11-12T18:21:16Z

aptos-move/framework/move-stdlib/src/natives/vector.rs

+    {
+        return Err(SafeNativeError::Abort {
+            abort_code: EINDEX_OUT_OF_BOUNDS,
+        });


There appears to be a typo in the comment: moved the the right contains a duplicated word and should be moved to the right

Spotted by Graphite Reviewer

Is this helpful? React 👍 or 👎 to let us know.

igor-aptos requested review from lightmark, vgao1996 and gelash October 3, 2024 22:03

igor-aptos requested review from davidiw, movekevin, wrwg, zekun000 and georgemitenkov as code owners October 3, 2024 22:03

igor-aptos force-pushed the igor/vector_utilities branch from 2253183 to 0f08236 Compare October 4, 2024 16:59

igor-aptos force-pushed the igor/native_vector_move_range branch 2 times, most recently from d724063 to e4540db Compare October 8, 2024 19:00

igor-aptos requested review from a team, msmouse, grao1991, bchocho, sasha8, ibalajiarun, JoshLind, gregnazario, runtian-zhou, danielxiangzl, banool and 0xmaayan as code owners October 8, 2024 19:00

igor-aptos changed the base branch from igor/vector_utilities to igor/move_mem_swap October 8, 2024 19:01

igor-aptos removed request for a team, gregnazario, bchocho and ibalajiarun October 8, 2024 19:01

igor-aptos force-pushed the igor/native_vector_move_range branch from e4540db to ae8e817 Compare October 9, 2024 20:30

igor-aptos force-pushed the igor/move_mem_swap branch from 783b338 to 3d7877e Compare October 10, 2024 00:07

igor-aptos force-pushed the igor/native_vector_move_range branch 2 times, most recently from 48df5f1 to 1407c00 Compare October 10, 2024 18:09

igor-aptos force-pushed the igor/move_mem_swap branch from 7c0fbc1 to 02eedf5 Compare October 15, 2024 19:48

igor-aptos force-pushed the igor/native_vector_move_range branch from 1407c00 to 94d1b68 Compare October 15, 2024 19:48

igor-aptos force-pushed the igor/move_mem_swap branch from 02eedf5 to c5f381e Compare October 16, 2024 21:07

igor-aptos force-pushed the igor/native_vector_move_range branch from 94d1b68 to 51f1f1c Compare October 16, 2024 21:07

igor-aptos force-pushed the igor/move_mem_swap branch from c5f381e to 8b0d35b Compare October 16, 2024 21:17

igor-aptos force-pushed the igor/native_vector_move_range branch from 51f1f1c to b36187b Compare October 16, 2024 21:17

igor-aptos commented Oct 21, 2024

View reviewed changes

ziaptos requested changes Oct 21, 2024

View reviewed changes

igor-aptos force-pushed the igor/move_mem_swap branch from 8b0d35b to 170eca3 Compare October 21, 2024 23:10

igor-aptos force-pushed the igor/native_vector_move_range branch from b36187b to 5b9f388 Compare October 21, 2024 23:10

igor-aptos requested a review from ziaptos October 21, 2024 23:28

ziaptos requested changes Oct 22, 2024

View reviewed changes

igor-aptos force-pushed the igor/move_mem_swap branch from 170eca3 to a99eccd Compare November 8, 2024 23:21

igor-aptos force-pushed the igor/native_vector_move_range branch from 5b9f388 to fc3c349 Compare November 8, 2024 23:21

igor-aptos requested a review from ziaptos November 12, 2024 15:57

igor-aptos force-pushed the igor/native_vector_move_range branch from fc3c349 to 9e0fd82 Compare November 12, 2024 18:04

igor-aptos added 4 commits November 12, 2024 10:19

Add vector::move_range native function

8dfdaab

feature flag

88adea9

minor updates

6a02bea

addressing comments

db496b3

igor-aptos force-pushed the igor/move_mem_swap branch from 23c63a3 to c95646e Compare November 12, 2024 18:20

igor-aptos force-pushed the igor/native_vector_move_range branch from 9e0fd82 to db496b3 Compare November 12, 2024 18:20

graphite-app bot reviewed Nov 12, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[move-stdlib] Add vector::move_range native function #14863

[move-stdlib] Add vector::move_range native function #14863

igor-aptos commented Oct 3, 2024

trunk-io bot commented Oct 3, 2024 •

edited

Loading

codecov bot commented Oct 3, 2024 •

edited

Loading

igor-aptos Oct 21, 2024

ziaptos Oct 21, 2024

igor-aptos Oct 21, 2024

igor-aptos Oct 21, 2024

ziaptos Oct 21, 2024

ziaptos Oct 21, 2024

igor-aptos Oct 21, 2024

ziaptos Oct 21, 2024

ziaptos Oct 21, 2024

ziaptos Oct 21, 2024

igor-aptos Oct 21, 2024

ziaptos Oct 21, 2024

ziaptos Oct 21, 2024

igor-aptos Oct 21, 2024

igor-aptos Oct 21, 2024

ziaptos Oct 21, 2024

ziaptos Oct 21, 2024

ziaptos Oct 21, 2024

igor-aptos Oct 21, 2024

ziaptos Oct 21, 2024

ziaptos Oct 21, 2024

igor-aptos Oct 21, 2024

ziaptos Oct 22, 2024

igor-aptos commented Oct 21, 2024

ziaptos left a comment

ziaptos Oct 21, 2024

ziaptos Oct 22, 2024

igor-aptos commented Nov 8, 2024

graphite-app bot Nov 12, 2024


		use super::mem::get_feature_not_available_error;

		/// The generic type supplied to aggregator snapshots is not supported.

[move-stdlib] Add vector::move_range native function #14863

Are you sure you want to change the base?

[move-stdlib] Add vector::move_range native function #14863

Conversation

igor-aptos commented Oct 3, 2024

Description

How Has This Been Tested?

Key Areas to Review

Type of Change

Which Components or Systems Does This Change Impact?

Checklist

trunk-io bot commented Oct 3, 2024 • edited Loading

codecov bot commented Oct 3, 2024 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

igor-aptos commented Oct 21, 2024

ziaptos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

igor-aptos commented Nov 8, 2024

graphite-app bot Nov 12, 2024

Choose a reason for hiding this comment

trunk-io bot commented Oct 3, 2024 •

edited

Loading

codecov bot commented Oct 3, 2024 •

edited

Loading