Allowing Matlab to Talk to Rust

Post by bbatha » Fri, Feb 05, 2016, 5:47 PM UTC

jblazevic wrote: post #7

Great stuff! One minor suggestion, completely beside the point so please forgive me: a safer and perhaps more idiomatic way to implement the multiply_safe function would be with a functional-style one-liner: fn multiply_safe(a : Vec , b : Vec ) -> Vec { if a.len() != b.len() { panic!("The two vectors differ in length!"); } return a.iter().zip(b.iter()).map(|(x, y)| x * y).collect() } Safer because you don't manipulat…

> Surprisingly, rustc optimizer makes sure that this performs as well as the index-wrangling implementation (according to some simple tests I just ran).

Frequently functional style optimizes better than the equivalent loop and index implementations because the iterator functional implementation cannot go out of bounds on the array, so the bounds checks that are implicit in indexing are elided.

Post by masklinn » Sat, Feb 06, 2016, 3:32 PM UTC

jblazevic wrote: post #7

Great stuff! One minor suggestion, completely beside the point so please forgive me: a safer and perhaps more idiomatic way to implement the multiply_safe function would be with a functional-style one-liner: fn multiply_safe(a : Vec , b : Vec ) -> Vec { if a.len() != b.len() { panic!("The two vectors differ in length!"); } return a.iter().zip(b.iter()).map(|(x, y)| x * y).collect() } Safer because you don't manipulat…

There are plenty of other things to improve/rustify.

* The function should take slices as inputs for instance, that way not only doesn't it take ownership of the inputs you don't need to copy the C arrays to vecs in the C-exposed function, you can just convert them to slice (which is essentially 0-cost, you just create a std::raw::Slice on the stack)

* The function also shouldn't panic it should return a Result (or an Option)

* Maybe less rustic but more efficient would be to take the output as an &mut [f64] (as the extern function does), that way the whole thing can be allocation-free

1 and 3 also simplify the glue code, instead of having to copy data from the input f64 to brand new vecs and from the output vec to the output f64, just convert the three input pointers with from_raw_parts and from_raw_parts_mut. That makes for much simpler and easier to review unsafe code as well:

    let a = unsafe { from_raw_parts(a_double, elements) };
    let b = unsafe { from_raw_parts(b_double, elements) };
    let c = unsafe { from_raw_parts_mut(c_double, elements) };

that's it, no mucking around with pointer offsets, and the rest if safe Rust.

Something like this: http://is.gd/uFhx2J

Re: Allowing Matlab to Talk to Rust

Re: Allowing Matlab to Talk to Rust