GRT target code runs slower than Rapid Accelerator mode

Hello,

I have a large Simulink model that is modeling multiple dynamic systems. In rapid accelerator mode, the model runs at about 1.5x real time. I have used the Real-Time Workshop to generate C code of the model and have built an executable using the grt_main.c wrapper function. The executable runs at about 6x real time. Is this typical? If not, does anyone know why this might be?

I have enabled most of the optimization options and parameter inlining. My model does not need to run in real-time, it just concerns me that it takes 4x longer to run the generated code than it dos to run in rapid accelerator mode.

At first glance the generated code appears to produce the same results as rapid acclerator mode, but I am in the process of formally verifying that.

Also, I have several enabled subsystems that run in multiple sample times. I haven't had a chance to correct these yet, so i disabled the error. I dont know if this is related to my speed issue, but you never know.

Thanks for any info,

Matt

[Guy Rouleau]

This is surprising. This can be influenced by many things in your model. For example do you have many custom s-functions? Do you load data using Form or From Workspace blocks?

One thing I would like to compare is the speed of the EXE generated using the Rapid Simulation (RSim) target, both with the RTW fixed-step solvers and the Simulink solver module (selected in model configuration).

If your license is under maintenance, this is the sort of thing technical support can help diagnosing.

[Matthew]

Guy,

Thanks for your response.

I do have one custom S-function. It is called at my fastest sample rate.

I don't use any From Workspace blocks, but I have a few From blocks here and there. All of my data is saved as workspace variables and entered as parameters in the blocks.

I will do some tests using different solvers and the RSim target next week and get back to you.

[MarkB]

It is worth noting that Rapid Accelerator/RSIM are somewhat "high overhead" simulations, that is, although individual simulations run faster, you need extra time to set up Rapid Accelerator/RSIM in the first place.

I would be interested to see if this difference in duration exists only for the first run of the simulation or across multiple runs.

There may also be differences in the amount of work being done by the solvers as well. The GRT code must be fixed-step, whereas Rapid Accelerator may be using a variable-step solver.

[Matthew]

Guy and Mark,

I did some speed tests with various solver/target combinations. I did 6 simulations of each combination and took the average of runs 2 through 6 to account for the build time (if applicable). The times listed below are listed as multipliers of real-time:

Rapid Accelerator (Variable Step):

2.58x, 1.82x, 1.82x, 1.82x, 1.83x, 1.83x

Average: 1.82x

Rapid Accelerator (Fixed Step):

1.81x, 1.09x, 1.1x, 1.09x, 1.08x, 1.09x

Average: 1.08x

RSim (Variable Step):

2.32x, 2.32x, 2.45x, 2.32x, 2.32x, 2.37x

Average: 2.36x

RSim (Fixed Step):

1.17x, 1.17x, 1.18x, 1.18x, 1.17x, 1.18x

Average: 1.18x

GRT (Fixed Step):

6.4x, 6.42x, 6.45x, 6.39x, 6.38x

Average: 6.42x

The RSim target takes a little bit longer compared to Rapid Accelerator for both variable and fixed step solvers. The GRT takes a lot longer.

I also tried getting rid of my non-inlined S-function and replaced it with an embedded MATLAB function. Under Rapid Accelerator, there is a small difference in speed between the S-function and Embedded MATLAB function. There was no change to the GRT simulation time.

Does this info give anyone any clues?

[Guy Rouleau]

This is very surprising. I can't guess anything else. I recommend contacting technical support because this is definitely unexpected. To investigate deeper, what I would do is to cut the model in pieces, trying to isolate the piece causing problems.

[Matthew]

I will try picking apart my model and testing each piece individually. I'll post back if I discover anything.

Answer 1

[Seth Popinchalk]

It is likely that some of the hooks to connect the Rapid Accelerator mode simulation with Simulink may add a measurable overhead to the simulation. The GRT Wrapper generated executable would not include those hooks, so it could conceivable be faster. (You might be able to verify this by building GRT with external mode support to see if it slows down the GRT based executable.)

Answer 2

[Seth Popinchalk]

The memory layout for a GRT executable and a Rapid Accelerator executable could be quite different. Depending on cache effects, and algorithm access patterns, the time to access global memory may have a significant impact on run time. The so-called pathological cache effects ( cache misses ) can result in significant run-time changes.

Answer 3

[Brad Carman]

Was there ever an answer to this question? I'm currently experiencing the same exact problem.