Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Allowing Matlab to Talk to Rust

smitec.io

Post reply on HN
Print view View original

1–10 of 12 posts

Re: Allowing Matlab to Talk to Rust

#3

Post by smitec »

ampron wrote: post #2

Well explained! Here are some more examples using the calllib function to access the rust code, although I think the mex interface is probably the better way to go. https://github.com/ampron/rustlab

awesome! thanks. I hadn't seen calllib before. Nice to see someone else in the overlap of matlab users and rust users.

Re: Allowing Matlab to Talk to Rust

#5

Post by masklinn »

bluejekyll wrote: post #4

One thing that jumped out to me, and I haven't worked with Rust FFI enough to know this answer. Is the C library necessary? Since Rust is exporting the C interfaces directly, couldn't Matlab link directly against that?

It would also require generating the Matlab bindings for Rust, but more problematically it seems to use a special compiler/linker (`mex`). I don't know if that does genuine work of if it's just a wrapper/synchronizer around compilers and linkers which you could do without.

Re: Allowing Matlab to Talk to Rust

#6

Post by dsharlet »

masklinn wrote: post #5
bluejekyll wrote: post #4

One thing that jumped out to me, and I haven't worked with Rust FFI enough to know this answer. Is the C library necessary? Since Rust is exporting the C interfaces directly, couldn't Matlab link directly against that?

It would also require generating the Matlab bindings for Rust, but more problematically it seems to use a special compiler/linker (`mex`). I don't know if that does genuine work of if it's just a wrapper/synchronizer around compilers and linkers which you could do without.

The main thing mex does is let you link to the matlab API libraries that are otherwise hard to get. To work around this, I like to just grab the API directly from the calling process via dlsym/GetProcAddress. That way, you can build mex libraries with any toolchain you want, even without matlab installed.

Re: Allowing Matlab to Talk to Rust

#7

Post by jblazevic »

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 manipulate indices and lengths directly like you would in C, so there is no opportunity of an off-by-one bug or things like that. Surprisingly, rustc optimizer makes sure that this performs as well as the index-wrangling implementation (according to some simple tests I just ran).

Re: Allowing Matlab to Talk to Rust

#8

Post by marmaduke »

Interesting, though the C middleman isn't necessary if you can describe to Rust's FFI that mxArray is an opaque struct (I imagine the other regular functions in the MEX API are cakewalk for an FFI worth it's weight).

A while ago I wrote a mexFunction purely in Cython, and it was wondeful because Python was immediately available to work with (instead of C). The problem was that the numerical libraries on which NumPy builds often shared symbol names with MATLAB (such as svd, or hdf5) that differ in implementation resulting segfaults or corrupted data.

Re: Allowing Matlab to Talk to Rust

#9

Post by marmaduke »

marmaduke wrote: post #8

Interesting, though the C middleman isn't necessary if you can describe to Rust's FFI that mxArray is an opaque struct (I imagine the other regular functions in the MEX API are cakewalk for an FFI worth it's weight). A while ago I wrote a mexFunction purely in Cython, and it was wondeful because Python was immediately available to work with (instead of C). The problem was that the numerical libraries on which NumPy b…

For the non-MATLABers, a mex function is just a small shared library which exports a single function 'mexFunction'. It's dynamically loaded by MATLAB when called in the MATLAB language.

Re: Allowing Matlab to Talk to Rust

#10

Post by marmaduke »

dsharlet wrote: post #6
masklinn wrote: post #5

Earlier quoted context omitted.

It would also require generating the Matlab bindings for Rust, but more problematically it seems to use a special compiler/linker (`mex`). I don't know if that does genuine work of if it's just a wrapper/synchronizer around compilers and linkers which you could do without.

The main thing mex does is let you link to the matlab API libraries that are otherwise hard to get. To work around this, I like to just grab the API directly from the calling process via dlsym/GetProcAddress. That way, you can build mex libraries with any toolchain you want, even without matlab installed.

This can be non-portable because the mex header will expand certain function calls to specific implementations depending on the mex options you use. I seem to recall e.g. mxGetM expanded to mxGetM700 in one version.
Post reply on HN