Manual MEX vs MEX by codegen

Hi,

The instructions how to write a MEX file look easy: https://uk.mathworks.com/help/matlab/matlab_external/standalone-example.html

However, when I look what autogenerated MEX function does, it is very confusing and much more complicated. I see calls to emlrt library, which should just wrap the conversion of parameters between Matlab and C (no actual C source code is available), but there are references to a global object (emlrtContextGlobal)and also some calls specific to particular Matlab releases. So it looks a bit messy and I wonder why.

I see that for example that mxgetpr calls has been recommended not to be used: https://uk.mathworks.com/help/matlab/apiref/mxgetpr.html. (I tripped over the problem mentioned there before finding this link).

So the question are:

• Why the MEX generated code and the code a user is supposed to write manually are so different?
• How that manully written code is compatible with future Matlab releases?

Thanks

[Denis Gurchenkov]

• Why the MEX generated code and the code a user is supposed to write manually are so different?

Please do not look at the Codegen-generated mex C code - it is not designed to be human-readable and/or copyable and modifiable. Treat it similar to how you treat the output of a C compiler - if you look at the assembly code, by far not everything you see there would be similar to what a human would write.

As to why there are emlrt calls, the global parameter, etc - that's because Codegen-generated mex files support capabilities require those. Runtime error reporting with good stack traces, ability to execute code in multiple threads using OpenMP, ability to call back to MATLAB to support execution of functions that are not compatible with code genreration, etc. Unless you really need to support all these concepts, it is likely that your hand-written mex code is going to be much simpler, and for a good reason.

[Dusko Vujadinovic]

I think the main oppoistion to Codegen comes from the fact that the generated code can be made to be more readable than it is. With experience, you learn how to write Matlab code to have more readable generated code. But still there are areas where the generated code is difficult to read and people do not treat it as assembler, so people get very negative to it.

Answer 1

[James Tursa]

MATLAB does not publish the "rules" that Codegen uses to generate mex code. Because it is automated, I am not surprised that the result looks much more involved. I don't use Codegen myself, but would expect it to be pretty good at getting correct code that is reasonably fast compared to what an inexperienced mex programmer could write manually. I wouldn't necessarily expect Codegen to always be better than what an experienced mex programmer could come with manually. It just depends on how much the programming effort is worth it to you to possibly gain some performance.

Regarding version specific stuff, realize that all compiled mex code is only guaranteed to run in the version that it was compiled under. That is true for Codegen and manual. It really depends on what your mex routine is doing and what library code it calls in the background. Some of this you don't control, and if the library you depend on happens to change in the next release you are out of luck and will have to recompile in the new version.

For mxGetPr( ), yes it is depricated for the R2018a+ memory model. They give you mxGetDoubles( ) and friends instead. Frankly, if you want your code to be robust you might consider using (double *)mxGetData( ), which will work in both R2017b- and R2018a+ memory models. If you have complex data then you are forced to write different code for R2017b- and R2018a+ memory models if you want the best performance that doesn't involve deep data copies on inputs/outputs.

As long as you stick with the published API library calls, your source code will likely be portable to future releases (but not guaranteed). Your compiled mex code may or may not be, and that is just the way it is.

[Denis Gurchenkov]

mex files produced by MATLAB Coder (Codegen) are forward-compatible. That is, a mex file generated in R2022a is expected to be runnable in future releases (22b, 23... etc).