Effect of using untyped variable in matlab function

Does anyone know if the use of untyped variables in Matlab Function Block affect the speed of the simulation?

[Paul]

What do you mean by "untyped variable"? The generated code for the block must have all of the variables typed. I think the code generator does some analysis to determine variable types for variables that don't have a specified type in the Matlab Function code.

[Lorenzo Rossi]

For "untyped variable" i mean a variable in a matlab function code that does not have the type specified.

I know that Matlab assign double as type to these kind of variables, but i don't know if this make the building process slower than if i have all variables typed in my matlab function code.

Hope i've explained well

[Paul]

I don't think Matlab automatically assigns double to variables that don't have types explicitly specified. Regardless, I'd be hard-pressed to think that there is anything the user can do that would make any noticeable difference in the time of the build process. Do you have some observations that lead you to think that might not be the case?

This link may be of interest.

[Lorenzo Rossi]

No, i don't. I'm asking just to know if there is anything i can do in that direction to speed up my simulation process.

Thank you for your help

[Paul]

Upon further reflection, I'd like to walk back my comment, at least a little bit. I don't work with Matlab Functions that are too large. If you have a function that has many, many source lines of code, then maybe it can be helpful to the code generator to preallocate variables with size and type. Even then, I'm not sure what happens in a situation like this:

z = zero(2,2,'double')  % at the top of the code

z = int32(eye(2));   % somewhere downstream

Maybe the doc has a "best practices" page for Matlab Function or code generation in general.

Answer 1

[Walter Roberson]

When acceleration is turned on, then each MATLAB Function Block has to have a copy of the code generated for each possible set of signal types. A lot of the time this is simple forward signal propagation of sizes and types, often double precision. Sometimes backwards propagation needs to be done to ensure that busses match sizes.

But every once in a while you get variant busses where there are different signal types or sizes on the path, and it can be necessary to do more work to identify all of the possibilities and to generate appropriate code for every combination that it cannot prove does not occur. In such a case if you know through external logic that your function should only ever be called with a particular combination of types, then it can make analysis faster and prevent extra code generation if you use the port manager to configure for particular signal types or sizes. This might end up pushing a type-check backwards in the dynamic path to generate a conflict if it manages to generate a different combination -- but that can be faster than generating code for everything that the analysis cannot disprove.

[Paul]

How does acceleration get into this discussion?. I thought code is generated and executed for Matlab Function blocks even when the simulation is run in Normal mode. Am I incorrect?

"each MATLAB Function Block has to have a copy of the code generated for each possible set of signal types"

Which signals are you refering to here in "each possbile set of signal types."?

[Walter Roberson]

code is not generated if acceleration is turned off. coder.extrinsic is not even required for this case: the block is completely interpreted by matlab when acceleration is completely off.

Because variant paths exist, the data type or size of a signal is sometimes not known until executed time, but the set of possible types should be determinable.

[Paul]

Is there source in the doc that says that Matlab Function is executed via interpreter when running in Normal mode? If not, how can that be verified experimentally?

I don't understand what you mean by "variant paths." Are you talking about paths that are inputs to and outputs from the Matlab Function block? Or you talking paths of the code inside the Matlab Function?

Is there a doc page or example model that illustrates "variant paths" or where the type or size of the signal is not know until execution time?

Simulink does support Variable Size signals, but even in this case the upper bounds on the size still need to be specified in the model so that everything can be statically typed at build time.

[Walter Roberson]

When you use if/else constructs, or switch constructs, or variant subsystems, then the different routes will not necessarily lead to the same type for the different versions of a signal.

[Paul]

It's my understanding that Simulink determines all signal types and sizes in the compile phase before the simulation actually enters the run loop. I believe a consequence of this is that at compile time the type and size of signals input to a Matlab Function block are all known and code is generated based on those types (assuming the input ports type and size are set to inherited).

AFAIK, Simulink is statically typed with all signal types and sizes determined in the compile phase. Variable size signals are not dynamically allocated duriin a run, as they could be in C++ using 'new' , for example.

As to the code generation question, I put a call to mvnrnd in a Matlab Function block w/o using coder.extrinsic. mvnrnd does not support code generation. Even with the model set to run in Normal mode, clicking Update still generated an error:

Function 'mvnrnd' not supported for code generation.

So it certainly looks like Simulink was trying to generate code, even in Normal mode.