Pass mutable references to rust ?

[Markus43]

I'm trying to write performance-critical code that needs to pass large buffers from dart to rust, which should be modified in-place in rust then. The rust algorithm that I want to use modifies the data in-place, so avoiding the copy should really help performance here.

Something like:

#[flutter_rust_bridge::frb(sync)]
pub fn test_func(buffer: &mut [f64]) {
  ...
}

Codegen gives me the following for this code:

void testFunc({required F64 buffer}) =>
    RustLib.instance.api.crateApiRustFftTestFunc(buffer: buffer);
// Rust type: RustOpaqueMoi<flutter_rust_bridge::for_generated::RustAutoOpaqueInner<[f64]>>
abstract class F64 implements RustOpaqueInterface {}

So I can't create / access the buffer that I want to fill from the dart side, because I cannot access the generated F64's data from dart.

Is there a way to create a Float64List (typed_data for performance) from dart and pass it to rust in a way that it can be directly modified in rust?

Or maybe there is an even better approach?

[fzyzcjy]

Currently it is not supported yet, because Dart does not seem to provide an API to convert a e.g. List<int> or Uint8List into a raw pointer. Even if it is supported, we should be very careful about the mutability things that Rust requires.

One alternative may be, try to allocate it in Rust and only use it in Rust, and Dart only gets an opaque object to that.

Another alternative is the raw approach (may make it automatic and safe by integrating into frb in the future): Firstly, allocate a Rust Vec<f64> and convert it to raw pointers. Secondly, on the Dart side, you can use dart:ffi's utility to convert a raw C pointer into a Float64List, and read/write to it. Thirdly, you can still use that vec/pointer on the Rust side. All are done without copy. However, be very careful about the mutability requirement of Rust. For example, Rust never expect two mutable references to one object.

EDIT: Btw I see #2205, so maybe try to see whether the release version is already fast enough, s.t. no optimization is needed.

[Markus43]

Another alternative is the raw approach (may make it automatic and safe by integrating into frb in the future): Firstly, allocate a Rust Vec<f64> and convert it to raw pointers. Secondly, on the Dart side, you can use dart:ffi's utility to convert a raw C pointer into a Float64List, and read/write to it. Thirdly, you can still use that vec/pointer on the Rust side. All are done without copy. However, be very careful about the mutability requirement of Rust. For example, Rust never expect two mutable references to one object.

That sounds like a really interesting approach! Do you have an example of such a conversion somewhere? I'm not really sure how to get a rust pointer translated into an ffi-compatible C pointer via frb's codegen ..?

EDIT: Btw I see #2205, so maybe try to see whether the release version is already fast enough, s.t. no optimization is needed.
I'm only talking about release builds here, so unfortunately no, this doesn't solve it ...

[fzyzcjy]

Do you have an example of such a conversion somewhere? I'm not really sure how to get a rust pointer translated into an ffi-compatible C pointer via frb's codegen ..?

Try to create a empty frb project, set full_dep: true in flutter_rust_bridge.yaml, and write pub fn f(a: Vec<u8>) {}, and look at frb_generated.rs.

As for how to make it compatible with frb - currently frb does not understand raw pointers, but you can:

1. use directly "extern C" Rust functions, bypassing frb. (of course, you can use frb for all other things, but only bypass for these several functions)
2. alternatively, convert e.g. *mut u8 to a u64 and pass between Rust and Dart.

[Markus43]

Could you please explain to me what full_dep: true is for? I didn't find this in the docs, and it seems to improve performance a lot in my case ...

[fzyzcjy]

It requires you have LLVM installed, thus it can use ffigen, then it uses the CST codec as default (instead of SSE codec), which I guess is faster in your scenario because of less large buffer copies.